rails-start: a Rails environment you bring up with one make command

The product is the Makefile, not the Rails app

rails-start is a starter kit for Ruby on Rails applications, designed to help developers quickly set up a new project with essential features and best practices. The README is explicit that the single command you need is make rails-start, and the repository's primary language is listed as Makefile, which is the most honest description of the project.

The root Makefile is a dispatcher. It includes five files from the Makefiles/ directory: 100_Project.mk, 200_Rails.mk, 300_Rails-Production.mk, 400_env.mk and 500_nginx.mk. The numbering is a convention that carries meaning, because the order of the includes is the order in which the pieces of the system become available to each other.

The built-in help target shows the shape of the whole thing. There is a quick start section with make env-setup to set up the environment files first, make start to start all containers, make rails-start to start the Rails development server and make rails-production-start for the production server. Below that, the help is split by category, with env-help, project-help, rails-help and rails-production-help, so each included Makefile owns its own documentation.

The audiences the README names are worth reading as a positioning statement: enterprises looking to standardise their Rails application setup, freelancers and agencies kicking off client projects, online education platforms teaching Ruby on Rails, and individual developers who want a solid foundation.

The repository layout backs this up, with a __RailsApp__ directory for the application itself, an ENV directory, a docker directory, a docs directory, a .devcontainer directory and the Makefiles directory.

Three commands between you and a running application

The installation path is short, and the requirements are the ordinary ones for a containerised Rails project: Docker and Docker Compose installed, git installed, and the make utility installed, the last two usually coming pre-installed on macOS and Linux. Windows users are pointed at WSL2 with a Linux distribution such as Ubuntu.

The Windows setup is spelled out in a collapsible section, and it is worth reading before you start. WSL2 and Ubuntu are installed from cmd or PowerShell:

wsl --install
wsl --set-default-version 2
wsl --install -d Ubuntu

Then, inside WSL, the make utility is installed with a single apt command:

wsl
sudo apt-get install -y make

After that, the actual installation is three steps. Clone the repository, move into the directory, and run the one command:

git clone https://github.com/the-teacher/rails-start.git

cd rails-start

make rails-start

The result is an application on http://localhost:3000, and the README shows a welcome page to confirm it. The order matters slightly, because the help target lists env-setup first: the environment files are a prerequisite for the containers coming up, which is why that target is described as the setup to run first.

The stack that arrives with the kit

The topics attached to the repository are a compact inventory of the services the kit stands up: docker, docker-compose, elasticsearch, pgsql, rails, redis, ruby, sidekiq, sphinx, whenever, and the sanitizer family for handling untrusted HTML.

Read as a list, that is a fairly opinionated Rails stack. Postgres for the database, Redis for caching and queues, Elasticsearch for search, Sphinx for documentation, Sidekiq for background jobs and Whenever for scheduling. That is a real application stack rather than a hello world, and it is the reason the kit exists: the work of getting these services talking to each other in a development environment is the tedious part that every Rails project otherwise repeats.

The Docker images come in three layers, and they are published in two registries under the iamteacher account on Docker Hub and under rails-start in the GitHub Container Registry. The Base image carries the initial software, the Main image adds Ruby with NodeJS and Rails, and the Media image carries media processing tools. The corresponding Dockerfiles are in the repository under docker/IMAGES/, which matters, because an image you can read and edit is an image you can adjust when a version moves on.

A DevContainer configuration is included as well, and the README lists it among the three ideas behind the project, alongside Docker and Docker Compose for environment setup and Makefiles to simplify commands and automate tasks. The point of the devcontainer is that the development environment stops being whatever happens to be installed on a laptop.

Environment files, production mode and nginx

Three parts of the kit are worth separating because they answer different questions.

The first is the environment workflow. There is an ENV/ directory in the repository, and the Makefile exposes environment management commands behind make env-help, with env-setup being the one the quick start tells you to run first. The design point is that the environment configuration is a set of files that the containers read, kept in the repository and in version control, rather than ad hoc exports that every developer has to reconstruct.

The second is the production path. 300_Rails-Production.mk and 500_nginx.mk are separate includes from the development ones, and the help has a matching make rails-production-start target and a rails-production-help category. The release history makes the intent explicit, with version 2.0 titled Rails 7. Start Kit for Windows, Linux and macOS, and version 2.1 titled Rails 7. Start Kit Loves Nginx.

That version 2.1 title is the clearest statement of the project's direction. A development container and a production container that are different things, with nginx terminating traffic in front of the Rails application, is a two environment setup, and it is the part of a Rails project that most hand rolled Makefiles get wrong.

The third is the project layer, 100_Project.mk, which owns the commands that create and manage the Rails project itself, behind make project-help.

Where rails-start is the wrong choice

Three limits are worth naming before you clone anything.

The first is that the stack is fixed. You get Postgres, Redis, Elasticsearch, Sphinx, Sidekiq and Whenever whether or not your application needs them, and a project that only needs a database and a job queue now runs six services in development. The cost of that is not only container startup time, it is the number of things that can be wrong when a developer cannot start the stack, and the number of things a new joiner has to learn before they can change a line of code.

The second is the version gap. The tagged releases are v1.9 in May 2023, v2.0 in September 2023 and v2.1 in September 2023, all of them described as Rails 7, while the repository itself has been pushed to on 2026-10-19. So the code is moving and the release series is not, and the Rails version you get depends on whether you clone the tip or take a tag. The docker/IMAGES Dockerfiles are in the repository precisely so that you can pin what you need, but you have to do that deliberately.

The third is that it is a template rather than a dependency. You copy it, you edit it, and you own the result, which is the right shape for a starting kit and the wrong shape for a library you would upgrade with npm. The Makefiles are yours once you clone, and there is no upgrade path.

The alternative, for a team that already has infrastructure, is a rails new application plus your own compose file with the services you actually use. The difference in approach is that rails-start front-loads decisions about the stack and the production topology so that a developer can be productive on the first day, while the manual route front-loads nothing and takes a day to get to the same place.

Licence, authorship and the shape of the repository

rails-start is MIT licensed, with the copyright line reading 2023-2025 and the name Ilya N. Zykin, who is also the author named in the root Makefile header. That is a permissive licence with nothing to negotiate for a template you are going to edit anyway.

The repository is a study in opinionated layout. There is a .devcontainer/ directory, a .github/ directory for the workflows, a .gitignore, the ENV/ directory for the environment files, the LICENSE.md, the root Makefile, the Makefiles/ directory with the five included files, the __RailsApp__/ directory holding the application, a docker/ directory with the IMAGES subdirectory holding the three Dockerfiles, and a docs/ directory with images and further material.

The project description on the repository is Start Rails in one command, which is the whole pitch and also the whole risk. A kit that promises one command has made a lot of decisions for you, and the value of that depends entirely on whether those decisions match the ones your team would have made.

The name of the project is worth a moment too. There is a long history of Rails start kits in the community, and most of them are large sets of files that a team then spends a week deleting. The test for rails-start is narrow and practical: clone it, run make rails-start, and see whether the resulting environment is the one your project actually needs.

Editorial conclusion

Adopt rails-start if you are starting a Rails project and want the common services already wired in Docker Compose, with an environment file workflow and a devcontainer, rather than assembling that yourself. Do not adopt it if your team already has an infrastructure standard, because the stack it brings, Postgres with Redis and Elasticsearch and Sphinx and Sidekiq, is opinionated and you will be editing its Dockerfiles. Verify first that the make targets you need exist in the included Makefiles, that the images on Docker Hub and the GitHub Container Registry match the versions your application needs, and that the Rails version the kit targets matches the one you intend to run, since the last tagged releases are from 2023 while the repository itself has seen commits since.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. the-teacher/rails-start on GitHub