DEV Community: Leonid Svyatov

The complete guide to `rails new` in Rails 8.1

Leonid Svyatov — Tue, 03 Mar 2026 10:23:12 +0000

rails new --help prints 30+ options. Most tutorials stop at rails new myapp -d postgresql and move on. This post covers every Rails 8.1 option - what it does, when to use it, and what most people pick.

App Mode

--api - Strips views, cookies, sessions, asset pipeline, Hotwire, CSS, and JavaScript. Use for pure JSON or GraphQL backends.

--minimal - Generates the smallest possible app. Skips Action Mailer, Action Mailbox, Action Text, Active Job, Active Storage, Action Cable, Hotwire, Jbuilder, tests, system tests, Kamal, Thruster, Solid, and Bootsnap. A good starting point when you want to add only what you need.

Database (`--database=X`)

Adapter	Pros	Cons	Best for
sqlite3 (default)	Zero setup, no server, works with Solid stack. 37signals runs ONCE products on it in production.	Single-writer, no multi-server scaling.	Solo devs, prototypes, single-server apps
postgresql ⭐	Full-featured (JSONB, arrays, full-text search), every PaaS supports it, best managed DB options.	Requires a running server.	Most production apps
mysql	Widely deployed, mature.	No native arrays, JSON can't be indexed directly (unlike PostgreSQL's JSONB).	Existing MySQL infrastructure
trilogy	Modern MySQL client by GitHub, no C library dependency, simpler install. GitHub & Shopify use it in production.	Newer, smaller ecosystem.	New MySQL projects
mariadb-mysql	For MariaDB specifically with mysql2 adapter.	Same as mysql.	Existing MariaDB setups
mariadb-trilogy	For MariaDB specifically with Trilogy adapter.	Same as trilogy.	New MariaDB projects

PostgreSQL is the most common choice. When in doubt, pick it.

--skip-active-record / -O - Drops the ORM entirely. Cascading effect: also skips database, Action Mailbox, Action Text, and Active Storage.

Frontend Stack

JavaScript (`--javascript=X` / `-j`)

Approach	Pros	Cons	Best for
importmap (default) ⭐	No Node.js, no build step, browser-native ES modules, HTTP/2 parallel downloads.	No tree-shaking, no TypeScript/JSX transpilation.	Standard Rails + Hotwire apps
esbuild	Extremely fast (Go-based), handles TypeScript/JSX, mature.	Requires Node.js.	Apps needing a bundler
bun	~1.75x faster than esbuild, doubles as package manager + bundler.	Newer, smaller ecosystem than esbuild.	Speed-first, Bun ecosystem
webpack	Full-featured, huge plugin ecosystem.	Slow, complex config, legacy choice.	Not recommended for new projects
rollup	Good for libraries, ES module focused.	Niche in Rails context.	Not recommended for new projects

Importmap is the Rails default for a reason - it eliminates Node.js from your stack entirely. Reach for esbuild or bun only when you need TypeScript, JSX, or tree-shaking.

--skip-javascript / -J - No JS setup at all.

CSS (`--css=X` / `-c`)

Framework	Pros	Cons	Best for
(none) (default)	No dependencies, write plain CSS.	No utilities or components.	Minimal apps, custom design systems
tailwind ⭐	Rails-blessed (`tailwindcss-rails` gem), no Node.js required, v4 is 5x faster with CSS-first config.	Verbose HTML classes, learning curve.	Most new Rails apps
bootstrap	Pre-built components, familiar to most devs.	Requires Node.js (via `cssbundling-rails`), heavier.	Apps needing ready-made UI components
bulma	CSS-only (no JS), clean modern design.	Requires Node.js via `cssbundling-rails`, smaller community.	Lightweight component needs
postcss	Plugin-based CSS transforms, flexible.	Requires Node.js, config overhead.	Custom CSS toolchains
sass	Variables, nesting, mixins, mature.	Requires Node.js (Propshaft doesn't compile Sass).	Teams already using Sass

No CSS framework is included by default. Tailwind is the most popular choice for new Rails apps - the tailwindcss-rails gem runs standalone, no Node.js required.

Asset Pipeline (`--asset-pipeline=X`)

Pipeline	Pros	Cons
propshaft (default) ⭐	Modern, lightweight - just fingerprinting and serving. Precompiles in seconds vs minutes.	No built-in preprocessing (delegates to external tools).
sprockets	Built-in Sass/CoffeeScript/ERB compilation, `//= require` directives.	Slow, complex, legacy.

Propshaft does one thing well: fingerprint and serve assets. If you need Sass or CoffeeScript compilation, Sprockets handles it - but you probably don't in 2025.

--skip-asset-pipeline / -A - No asset pipeline at all.

Hotwire (`--skip-hotwire`)

Turbo + Stimulus - the default Rails frontend framework. Turbo 8 introduced morphing (DOM diffing via idiomorph) that makes full-page refreshes feel SPA-smooth. Skip only if you're using a JS SPA framework (React, Vue) or building an API-only app (auto-skipped with --api).

The Solid Stack & Deployment

These are Rails 8 additions that replace external services with database-backed alternatives.

`--skip-solid`

Solid Cache + Solid Queue + Solid Cable - replaces Redis for caching, background jobs, and WebSockets. All database-backed, works with SQLite, PostgreSQL, and MySQL. 37signals runs 20M jobs/day on Solid Queue for HEY.

Solid Cache - database-backed caching. Higher latency than Redis RAM, but terabytes of SSD capacity at a fraction of the cost.
Solid Queue - uses FOR UPDATE SKIP LOCKED for efficient polling. Replaces Sidekiq/Resque for most apps.
Solid Cable - database-backed Action Cable. Polls every 100ms. Fine for moderate real-time needs.

Skip if: you already run Redis and need Sidekiq's advanced features (batches, rate limiting) or sub-millisecond cache latency.

`--skip-kamal`

Kamal 2 deploys Docker containers to any VPS (Hetzner, DigitalOcean, AWS EC2). Uses kamal-proxy (replaces Traefik) with automatic Let's Encrypt SSL. Zero-downtime deploys, rolling restarts.

Skip if: you deploy to a PaaS (Heroku, Render, Fly.io) or use Kubernetes.

`--skip-thruster`

Thruster - HTTP/2 proxy (written in Go by 37signals) that sits in front of Puma. Provides HTTP/2, gzip compression, asset caching, X-Sendfile, and automatic SSL. Replaces Nginx/Caddy for simple deployments.

Skip if: you already have a reverse proxy (Nginx, ALB, Cloudflare) or deploy to a PaaS.

Frameworks You Can Skip

Email & Rich Content

--skip-action-mailer / -M - No email sending or receiving infrastructure. Skip if your app never sends email.

--skip-action-mailbox - No inbound email routing to controller-like mailboxes. Requires Active Record. Skip if you don't process incoming email.

--skip-action-text - No Trix rich text editor integration. Requires Active Record. Auto-skipped in API mode.

Background & Storage

--skip-active-job - No background job framework. Also disables Solid Queue integration. Skip only if you handle no async work at all.

--skip-active-storage - No file uploads to S3/GCS/Azure. Requires Active Record. Skip if your app handles no file uploads.

--skip-action-cable / -C - No WebSocket framework. Also disables Solid Cable. Skip if you don't need real-time features.

JSON

--skip-jbuilder - Removes the Jbuilder JSON template DSL. Most API apps prefer render json: with serializers instead.

Testing & Code Quality

--skip-test / -T - Removes Minitest setup. Most people skip this to add RSpec instead.

--skip-system-test - Skips Capybara browser tests. Auto-skipped in API mode or when tests are skipped.

--skip-brakeman - Brakeman is a static security scanner for Rails that catches SQL injection, XSS, and 33+ other vulnerability types. Runs in seconds. Keep it.

--skip-bundler-audit - New in Rails 8.1. bundler-audit scans your Gemfile.lock for gems with known CVEs. Complements Brakeman: code scanning + dependency scanning. Keep it.

--skip-rubocop - RuboCop, Ruby linter, included by default since Rails 8. Keep it or swap in Standard Ruby.

--skip-ci - Skips the generated GitHub Actions workflow. Rails 8.1 CI includes Brakeman and Bundler Audit steps by default.

Infrastructure & Housekeeping

--skip-docker - Skips Dockerfile, .dockerignore, and bin/docker-entrypoint. Skip if you're not containerizing.

--devcontainer - Opt-in (not included by default). Generates VS Code dev container config with Redis, database, and Ruby all preconfigured.

--skip-bootsnap - Bootsnap caches expensive computations to speed up boot time. Rarely worth skipping.

--skip-dev-gems - Skips web-console and similar development gems.

--skip-keeps - Skips .keep files in empty directories. Git doesn't track empty dirs, so .keep files exist to preserve the directory structure.

--skip-decrypted-diffs - Skips git config for showing decrypted diffs of encrypted credentials.

--skip-git / -G - Skips git init, .gitignore, and .gitattributes.

--skip-bundle / -B - Skips bundle install after generation. Useful in CI or Docker builds where you control dependency installation separately.

Putting It Together - Common Recipes

Full-stack SaaS:

rails new myapp -d postgresql -c tailwind -T \
  --skip-action-mailbox --skip-action-text --skip-jbuilder

The workhorse setup. PostgreSQL, Tailwind, Solid stack, Kamal - all defaults. Skips Minitest (most teams add RSpec), Action Mailbox (few apps process incoming email), Action Text (add it later if you need a rich text editor), and Jbuilder (you'll use render json: or a serializer).

API backend:

rails new myapi --api -d postgresql -T \
  --skip-action-mailbox --skip-jbuilder

--api strips views, assets, cookies, and Hotwire. Skips Minitest for RSpec. Action Mailbox and Jbuilder rarely belong in an API.

Single-server indie app (the "one person framework"):

rails new myapp -d sqlite3 -c tailwind -T \
  --skip-action-mailbox --skip-action-text --skip-jbuilder

SQLite + Solid stack = no Redis, no PostgreSQL, no external services. Kamal and Thruster handle deployment and SSL. One server, one process, one database file. Add PostgreSQL later if you outgrow it.

PaaS deploy (Heroku, Render, Fly.io):

rails new myapp -d postgresql -c tailwind -T \
  --skip-action-mailbox --skip-action-text --skip-jbuilder \
  --skip-kamal --skip-thruster

Same as the SaaS setup but skips Kamal and Thruster - the PaaS handles containers, routing, and SSL for you.

Lean prototype:

rails new proto --minimal -d sqlite3

Bare minimum: no mailer, no jobs, no cable, no Hotwire, no Kamal. Add frameworks back as you need them.

If you don't want to memorize any of this, I built a tool for that. create-rails-app is an interactive CLI wizard that walks you through each option, remembers your choices, and saves reusable presets.

gem install create-rails-app

I got tired of looking up `rails new` flags, so I built a wizard for it

Leonid Svyatov — Fri, 27 Feb 2026 19:47:14 +0000

Every time I start a new Rails project, the same thing happens. I open the terminal, type rails new, and then... pause. What was the flag for PostgreSQL? Is it --skip-test or --skip-tests? Do I want Propshaft or Sprockets? What about Solid Queue — is that a flag now?

So I open rails new --help, scroll through a wall of options, and piece together a command I'll forget by next week.

After doing this too many times, I built create-rails-app — an interactive CLI wizard that walks you through every rails new option one at a time.

What it does

Instead of memorizing flags, you answer simple questions:

[01/31] API only application? (no)  ›  Yes / No
[03/31] Database (postgresql)       ›  sqlite3 / postgresql / mysql / trilogy ...
[04/31] JavaScript approach (importmap) › importmap / bun / esbuild / webpack ...

Each question shows your last-used choice as the default, so repeat projects take seconds.

At the end, you see the full rails new command — review it, then run it or go back and tweak your choices.

A few things I find useful

It remembers your choices. Next time you run it, your previous selections are pre-filled. Change one or two things and go.

Presets. Save a named configuration and reuse it:

create-rails-app myapp --preset api

I have presets for "api", "fullstack", and "minimal" — covers 90% of my projects.

Smart skip rules. Disable Active Record? It won't ask about databases. Choose API mode? It skips CSS and JavaScript framework questions. The wizard stays short and relevant.

Back navigation. Changed your mind three questions in? Ctrl+B goes back. No need to start over.

Version-aware. It detects your installed Rails version (supports 7.2, 8.0, and 8.1) and only shows options that apply.

Install

gem install create-rails-app

That's it. Run create-rails-app and follow the prompts.

Why not just use a template?

Rails templates are great for adding code after project creation. But they don't help with the rails new flags themselves — the database, JS bundler, asset pipeline, which frameworks to skip. That's the part I kept forgetting, and that's what this tool handles.

If you start new Rails projects more than once a year and find yourself googling the same flags, give it a try. Feedback and contributions welcome on GitHub.

clsx for Rails views

Leonid Svyatov — Sun, 03 Mar 2024 19:25:38 +0000

Hey, fellow Rubyists!

Have you ever found yourself wrestling with conditional class strings in your Rails views? Juggling string interpolation, conditional logic, and array manipulation to apply a class or two conditionally? It's like trying to thread a needle in a hurricane. Well, fret no more! Say hello to clsx-rails, the newest member of the Ruby gems family, here to make your life a tad bit easier.

Inspired by the simplicity of the clsx npm package, clsx-rails is your Rails view's new best friend. It's a tiny helper with a mighty purpose: to streamline how you handle CSS classes, making your code cleaner, more readable, and, let's be honest, more elegant.

Why `clsx-rails`?

Because we've all been there:

<div class="<%= ['foo', 'bar', condition ? 'baz' : nil].compact.join(' ') %>">
  Hello, Rails world!
</div>

It gets the job done, but it's about as graceful as a giraffe on ice skates. With clsx-rails, you can turn that mess into a one-liner marvel:

<div class="<%= clsx(:foo, :bar, baz: condition) %>">
  Hello, Rails world!
</div>

Usage Examples

Whether it's a string, a hash, or an array, clsx-rails handles them all, even nesting them like Russian dolls if that's your jam. It even eliminates any duplicates while at it! And for those who like their code like their coffee—short and strong - there's the cn alias.

# Variadic strings
cn('this', true && 'is', 'awesome')
# => 'this is awesome'

# Hashes with truthy/falsy values
cn(foo: true, bar: false, baz: condition)
# => 'foo baz' (assuming the condition is true)

Although not advised, it can handle any level of "complexity":

clsx(
  [[[['a'], 'b']]],
  { a: 1, b: 2 },
  [1, 2, 3, 4],
  { [1, 2, { %w[foo bar] => true }] => true }
)
# => 'a b 1 2 3 4 foo bar'

You can find more details and usage examples in the repo.

Why It's Useful

Keeps your views DRY and readable.
Reduces the mental overhead of handling conditional classes.
It's like giving your views a neat little toolbelt for CSS class manipulation.

So, if you're tired of the conditional class string chaos and want to add some syntactic sugar to your Rails views, give clsx-rails a whirl. Your views will thank you, and who knows, you might find yourself with a bit more time for coffee breaks :)

Happy coding!

How to hide Ruby 2.7 deprecation warnings system-wide

Leonid Svyatov — Fri, 24 Apr 2020 23:36:24 +0000

Are you using rbenv? Want to hide Ruby 2.7 deprecation warnings system-wide and not to deal with it on a per-project basis? This small tutorial is for you!

All you have to do is create file ~/.rbenv/rbenv.d/exec/hide-deprecations-for-2.7.bash with the following content:

# ~/.rbenv/rbenv.d/exec/hide-deprecations-for-2.7.bash

if [[ ${RBENV_VERSION%.*} == '2.7' ]]; then
  export RUBYOPT="-W:no-deprecated -W:no-experimental"
else
  unset RUBYOPT
fi

Done.

How exactly does it work can be found here.

I've tested it in Zsh. It should work in Bash, but I can't guarantee it.

Keep your Javascript dependencies under control

Leonid Svyatov — Mon, 04 Mar 2019 15:48:27 +0000

With all the Javascript libraries and their dependencies these days it’s easy to get carried away and lost track of how heavy your frontend is.

Here is a great tool for Webpack backed applications: Webpack Bundle Analyzer. It shows the exact size (parsed and gzipped included) of each dependency you put inside your package.json file.

And here is an example of how to add it to your Rails project.

First, we need to add it to the package.json:

# Save the package to your `devDependencies`
yarn add -D webpack-bundle-analyzer

Second, add this to your config/webpack/environment.js file, right before module.exports = environment; line:

if (process.env.ANALYZE_BUNDLE) {
  const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
  environment.plugins.append('BundleAnalyzer', new BundleAnalyzerPlugin());
}

Third, make it available as yarn/npm run task:

// package.json
{
  // ...
  "scripts": {
    // ...
    "analyze": "ANALYZE_BUNDLE=true RAILS_ENV=production ./bin/webpack"
  },
  // ...
}

Done. You can run it like this now:

yarn run analyze

Happy keeping your Javascript dependencies under control! :)

Easier usage of Rails 5.2 credentials and app-specific configuration

Leonid Svyatov — Sun, 24 Feb 2019 14:21:39 +0000

As you all know by now, Rails 5.2 introduced a new feature called Credentials. DHH said the following in the PR:

This new file is a flat format, not divided by environments like secrets.yml has been. Most of the time, these credentials are only relevant in production, and if someone does need to have some keys duplicated for different environments, it can be done by hand.

And as you should know by now, Rails 6.0 fixes this obvious inconvenience.

Meantime, a commonly proposed solution for Rails 5.2 was just to add environments by hands, something like so:

development:
  facebook_app_id: '...'
  facebook_app_secret: '...'
  facebook_app_namespace: '...'
  stripe_publishable_key: '...'
  stripe_secret_key: '...'
  stripe_signing_secret: '...'

production:
  facebook_app_id: '...'
  facebook_app_secret: '...'
  facebook_app_namespace: '...'
  stripe_publishable_key: '...'
  stripe_secret_key: '...'
  stripe_signing_secret: '...'

And then use it like this:

Rails.application.credentials[Rails.env.to_sym][:facebook_app_secret]

Pretty long and not very readable, right? Yeah, you probably don’t use credentials in that many places in your app anyway, but still. This line has 47 characters about Rails and just 22 characters about what you need. Not the best ratio, in my opinion.

The solution I’d like to show you is quite obvious, but I’ve never seen it being suggested anywhere (maybe I didn’t search right enough, sorry if that’s the case).

Just open config/application.rb and add credentials method like so:

require_relative 'boot'

require 'rails/all'

# Require the gems listed in Gemfile, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(*Rails.groups)

module YourApp
  class Application < Rails::Application
    # Initialize configuration defaults for originally generated Rails version.
    config.load_defaults 5.2

    # Settings in config/environments/* take precedence over those specified here.
    # Application configuration can go into files in config/initializers
    # -- all .rb files in that directory are automatically loaded after loading
    # the framework and any gems in your application.
  end

  def self.credentials
    @credentials ||= Rails.application.credentials[Rails.env.to_sym]
  end
end

Let’s see what it changes:

# Before:
Rails.application.credentials[Rails.env.to_sym][:facebook_app_secret]

# After
YourApp.credentials[:facebook_app_secret]

This approach abstracts Rails-specific details away, makes it concise, expressive and about your application. As a bonus it gives you a lot of flexibility: you can replace Rails credentials with something else, you can merge credentials from different places, you can easily upgrade to Rails 6 credentials by removing [Rails.env.to_sym] part, and so on.

OK, that’s great, but post’s title was also saying something about “app-specific configuration,” right? Correct! I want to show you one more thing that can make your life with Rails a little easier.

As your Rails application grows sooner or later, you will need a place to store various environment-specific details for your app: things that aren’t secrets or credentials, just some custom configuration. Rails documentation even has a section with this exact name: Custom configuration.

According to the documentation Rails offers us two pretty powerful options:

config.x namespace
config_for method

Neat! How about we use our credentials approach described above and combine with these two options?

Step 1: create config/app.yml

shared: &shared
  facebook_url: 'https://www.facebook.com/mysite'
  twitter_url: 'https://twitter.com/mysite'

development:
  <<: *shared
  domain: 'localhost:3000'
  devise_mailer_sender: 'no-reply@localhost'
  orders_mailer_sender: 'no-reply@localhost'

production:
  <<: *shared
  domain: 'mysite.com'
  devise_mailer_sender: 'no-reply@mysite.com'
  orders_mailer_sender: 'orders@mysite.com'

Step 2: fill in config.x from app.yml in the config/application.rb

# App specific configuration
config.x = config_for(:app).with_indifferent_access

Step 3: add config method to the config/application.rb file

  def self.config
    @config ||= Rails.configuration.x
  end

So your config/application.rb file now looks like this:

require_relative 'boot'

require 'rails/all'

# Require the gems listed in Gemfile, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(*Rails.groups)

module YourApp
  class Application < Rails::Application
    # Initialize configuration defaults for originally generated Rails version.
    config.load_defaults 5.2

    # Settings in config/environments/* take precedence over those specified here.
    # Application configuration can go into files in config/initializers
    # -- all .rb files in that directory are automatically loaded after loading
    # the framework and any gems in your application.

    # App-specific configuration
    config.x = config_for(:app).with_indifferent_access
  end

  def self.config
    @config ||= Rails.configuration.x
  end

  def self.credentials
    @credentials ||= Rails.application.credentials[Rails.env.to_sym]
  end
end

And we can use our custom configuration like so:

YourApp.config[:devise_mailer_sender]

How cool is that? :)

How to send Rails deprecation warnings to Airbrake

Leonid Svyatov — Mon, 18 Feb 2019 21:04:20 +0000

We’re upgrading our Ruby on Rails version from 4.2 to 5.2 this week. A long-awaited change for us. Of course, there are a lot of deprecation warnings that was thrown at us during this process. Rubocop and tests caught the vast majority of those, but we don’t have 100% code coverage, so some of these warnings got into production.

In development Rails send these warnings to the log file:

# Print deprecation notices to the Rails logger.
config.active_support.deprecation = :log

A reasonable default, but I changed it to :raise. It's way faster to find and deal with the warnings this way in development.

For production environment Rails uses ActiveSupport::Notifications:

# Send deprecation notices to registered listeners.
config.active_support.deprecation = :notify

The problem is that nobody listens for it in production. Fortunately, that was easy to fix with Airbrake. I tried to “google” the solution at first but didn’t find anything useful, so I’m sharing my solution for other seeking souls like me :)

# config/initializers/deprecations_notifier.rb

ActiveSupport::Notifications.subscribe('deprecation.rails') do |_name, _start, _finish, _id, payload|
  error = ActiveSupport::DeprecationException.new(payload[:message])
  error.set_backtrace(payload[:callstack].map(&:to_s))

  params = {
    gem_name: payload[:gem_name],
    deprecation_horizon: payload[:deprecation_horizon]
  }

  Airbrake.notify(error, params) do |notice|
    notice[:context][:severity] = 'warning'
  end
end

If you’re using CurrentAttributes and storing request.uuid there it would be a good idea to add current request UUID to the params as well.