Suspenders: a Rails template that ships a date as its version number

It is the Rails template mechanism with a gem in front of it

The project describes itself as intended to create new Rails applications with a set of features, and the interesting architectural fact is that it does not reimplement anything. It installs as a gem, and creating an application delegates to the framework's own application template support, passing a database selection, a set of skips, and the path to the template script. So Suspenders is a wrapper around a documented Rails feature, which means it inherits that mechanism's behaviour and its constraints, including the fact that the template is Ruby that runs at generation time rather than a manifest of settings. The three commands a new user runs are correspondingly ordinary:

gem install suspenders

gem update rails

suspenders new <app_name>

That is the whole interface, and it is a deliberate one-line pitch for people who want the defaults without an afternoon of setup.

Three skips encode the opinionated part

The generation command shows what the template actually changes. The database is set to PostgreSQL rather than whatever the framework would choose, which the project links to their own dotfiles as the reason. The default test framework is skipped in favour of RSpec. And the entire Solid ecosystem is skipped. That last one has a stated reason with a linked issue behind it: the maintainers prefer a separate background job library, and because the Solid queue has performance problems on the host they target. So each skip is a decision with an argument attached rather than a preference left implicit, which is the difference between a template and a set of personal taste. The flip side is that the template is tuned for one deployment target, and the page says so: it is optimized for deployment on the recommended host, since that is where they build.

The master key requirement breaks CI until you configure it

There is one operational trap in the flow, and it is called out as important rather than left to be discovered. The generated application enables a setting that makes the master key mandatory at boot, and because that key lives in a file the generated project does not commit, any continuous integration run will fail to start until the key is registered as a secret with the provider. The documented fix is a single command that reads the key from the local configuration file and sets it in the repository's secrets for the CI system, which is a sensible default since the value already exists locally. The general shape of the problem is worth naming: a template that generates an application with stricter secret handling than you are used to will break your pipeline on the first run, and the fix is one line of tooling rather than a code change. Anything else that the generated application expects from CI, such as the database and cache services, comes from the host configuration rather than from the template.

The deployment ends by scaling a worker, which is easy to miss

The initial deployment is a fixed sequence: create the application, pin the buildpack to the Ruby one explicitly, create a Postgres add-on on a named plan and a Redis add-on on a named plan, then set two required environment variables, one for the application host and one for the master key. The sequence ends with a step that reads as housekeeping and is not: scaling the worker process type up to one instance. A template that ships a background job library produces an application with two process types, the web process and the worker, and on the target host the worker does not start by itself. So an application that looks correctly deployed and serves requests while silently dropping every background job is the failure this line prevents. The two add-on plan names are also pinned in the documentation, which tells you the sizing is a starting point to review rather than a recommendation, since a larger database plan is a different add-on name.

Versions are calendar dates, so ordering is not semantic versioning

The three most recent releases are named with a date and a zero: one for March 25 2026, one for February 13 2026, and one for January 5 2026. So the version number encodes when it was cut rather than how much changed, which has two consequences. First, there is no semantic compatibility contract to reason about: nothing in the number tells you whether a change is breaking, so upgrading means reading the news file the project commits. Second, any tooling that compares versions numerically will order these correctly by accident, since the numbers grow with time, but tooling that expects a semantic version prefix, or a lockfile constraint expressed as a version range, has to be told about the scheme explicitly. The repository does include a release process document and a news file, which is where a project with calendar versioning has to put the information the version number is not carrying.

The feature list is a separate document, and the readme says why

The readme is short, and the reason is visible in its first section: the features are a link to another file rather than a list. That is a deliberate choice, and it has a real effect on anyone evaluating the template. You cannot learn from this page what you will get; you have to open the features document and read it, which means the decision of whether Suspenders suits you takes one extra step and cannot be made from a search result. The framing sentence is the closest thing to a pitch and it is worth quoting for its honesty about the trade: use it if you are in a rush to build something, do not use it if you like missing deadlines. That is a template that takes opinions on your behalf, and the page says so. The repository structure backs the same picture, with a goals file beside the features file and a set of tests for the generator itself rather than for a generated application.

The readme ends in a generated block, which dates the tooling

The last section of the readme is wrapped in comment markers that name a template file, which tells you the repository is maintained with shared templates rather than by hand for every project. That block is the standard project footer: the company name and logos are trademarks, there is a link to their open source community, and there is a link to hiring them. It is worth noting because it is the kind of detail that dates a repository's tooling, and it sits next to the other structural signals. There is a style configuration file, which selects a particular Ruby linter and formatter, and there is a Ruby version file, so the version a contributor develops against is pinned rather than floating. Type signatures are present in their own directory, so the gem is described to an editor even though the thing it generates is an application. And the lockfile is committed, which for a gem is unusual and is the place where the exact dependency graph a maintainer tested against becomes reviewable.

Editorial conclusion

Take Suspenders if you are starting a Rails application and want thoughtbot's defaults rather than choosing them yourself, and if you are deploying to the host it targets. Check three things before you generate anything. The feature list is not on this page, it is a separate document, so read that before assuming the template contains what you need. The generated application enables a master key requirement, so continuous integration will fail until you register that key as a secret with your provider. And the background worker is not optional, since the documented deployment ends with scaling a worker process up, so a host without a separate worker process type will need that configured before the app runs.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. thoughtbot/suspenders on GitHub