A Repeatable Rails Development Environment with Docker

Give the application one predictable environment

A Rails development stack often includes PostgreSQL, Redis, a web process, and workers. Compose can describe their dependencies and keep service addresses consistent across machines. Inside a container, localhost refers to that container; use the database service's network alias for DATABASE_URL.

docker compose up --build -d
docker compose logs -f app
docker compose exec app bin/rails db:prepare
docker compose exec app bin/rails test

These commands assume a Compose service named app and the application's Rails scripts. Database preparation creates or migrates the configured database. For an existing development database, run db:seed explicitly when you want changed demo data applied; preparation is not a promise to rerun seeds on every boot.

Separate source files and persistent data

Bind-mount application code for quick edits. Use named volumes for database data so recreating a container does not erase it. Avoid deleting volumes as a routine troubleshooting step. Inspect connection settings and logs first.

Make startup dependencies real

A container starting does not mean its service accepts requests. Add health checks and wait for required services before startup maintenance. Keep a full search reindex out of the normal startup path; a large rebuild can prevent the web server from becoming ready.

Keep development behavior explicit

Demo accounts and fixed passwords belong to development and test data. Production startup should run migrations with real secrets and should never reset accounts from demo seeds. Document the commands a new teammate needs, then verify them against a fresh development database.