Deployment.sh

Rails hosting with Puma, Sidekiq and zero downtime releases

Deployment gives Ruby on Rails apps a home on servers you own: the Ruby version from your .ruby-version, Bundler with a cached gem path, Puma behind nginx or Caddy, Sidekiq as a managed daemon, and releases that precompile assets and run migrations before a single request reaches the new code. Push to your branch and the release goes live once it passes its health check.

Two developers pairing on a sofa with one laptop in a small agency studio

What Deployment detects in a Rails application

A Gemfile with rails and a config.ru mark the app. .ruby-version or the ruby line in the Gemfile picks the Ruby version. puma is the web server, sidekiq adds a worker, solid_queue or good_job adds the matching job process, and whenever or sidekiq-cron tells Deployment how scheduled jobs are defined. The database adapter in config/database.yml and the pg or mysql2 gem pick PostgreSQL or MySQL, and jsbundling-rails, cssbundling-rails or importmap-rails decides whether Node is needed for the asset build.

  • Ruby version installed per site, so apps on different versions share a server
  • Node LTS only when your asset pipeline needs it
  • Puma web process plus Sidekiq, Solid Queue or GoodJob workers
  • PostgreSQL or MySQL from your adapter

What Deployment installs for Rails hosting

After the standard hardening (firewall, key-only SSH, unattended security updates, swap), each server gets the Ruby versions your sites need through a version manager, the system libraries native gems expect (libpq, libvips or ImageMagick for Active Storage variants, libyaml), nginx or Caddy, Redis for Sidekiq and Action Cable, and your database engine. Each site runs as its own user. RAILS_MASTER_KEY is stored as an encrypted environment variable, never in the repository.

Two developers in a small agency office reviewing a deploy log on a laptop, one pointing at the screen with a pen

A Rails deploy script with assets precompile

Bundler installs into a shared path, so a deploy without Gemfile changes takes seconds. log, tmp/pids, storage and public/uploads are shared folders linked into every release. Edit any line in the panel, for example to add bin/rails db:seed on staging only.

bash 
cd "$RELEASE_PATH"
bundle config set --local deployment true
bundle config set --local without 'development test'
bundle install --jobs 4
RAILS_ENV=production bin/rails assets:precompile
RAILS_ENV=production bin/rails db:migrate

Puma, Sidekiq and scheduled jobs

Puma runs under systemd with socket activation or a private port behind the proxy, with workers and threads set from the server size. Sidekiq runs as its own daemon. On deploy Deployment sends Sidekiq TSTP to stop fetching new jobs, then TERM, and Sidekiq waits for running jobs up to its timeout before the new process starts on the new release. Jobs left in Redis are picked up by the new worker. Scheduled tasks run as cron jobs (bin/rails runner, rake tasks) with each run's output in the cron log, or through sidekiq-cron if you keep schedules in the app.

Zero downtime Rails deploys and rollback

The new release is built beside the current one. When bundle, assets and migrations succeed and the new Puma answers the health route (Rails ships /up for this), the current symlink moves and Puma performs a phased restart: workers are replaced one at a time, so requests never hit a cold server. If anything fails, the current release keeps serving. Rollback picks a previous release folder, with its own precompiled assets, and switches back in seconds. The general mechanics are on zero downtime deployment, and branch setup on deploy from git.

  • Use strong_migrations or the same discipline by hand: add, backfill, then remove in a later release
  • Keep old asset digests available for a while so cached pages still load their CSS

PostgreSQL, MySQL and Redis for Rails

Create databases, users and grants from the panel, on the app server or a dedicated database server with remote access limited to your app servers. Redis covers Sidekiq, Action Cable and the cache store. Scheduled backups of the database and the storage folder go to your own S3-compatible bucket with retention and one-click restore.

Which plan fits your Rails hosting

PlanMonthlyYearly, per monthServersDeploy history
Starter49 USD24 USD314 days
Team199 USD99 USD1590 days
Agency499 USD249 USD601 year
Enterprise1 499 USD749 USD2502 years

A Rails app with Sidekiq and a staging server fits Starter. A team with several apps, separate database servers and teammates who should deploy but not delete servers fits Team. Compare all plans on PaaS pricing.

Rails hosting questions

Does Deployment support Solid Queue and GoodJob?

Yes. When the Gemfile includes them, Deployment runs the job process as a managed daemon and restarts it gracefully on every deploy, just like Sidekiq.

Can I run Action Cable?

Yes. The proxy forwards WebSocket upgrades to Puma, and Redis is available as the Action Cable adapter.

How are credentials handled?

RAILS_MASTER_KEY and any other secrets are stored as encrypted environment variables per environment, and the panel shows a diff before each deploy.

Can I try Deployment before I pay?

Yes. The home page has a free one-time demo: paste a public repository URL and see the detected stack, the server plan and the first lines of the deploy script. Plans start at 49 USD a month, or 24 USD a month billed yearly.

Give your Rails app a server you control

Connect a VPS or a cloud account and ship the next release.

Try the demo