Keep the Ruby on Rails build you already use
Install from Gemfile.lock and run the asset preparation required by the project. Keep schema changes separate enough to review and recover deliberately.
Apps and APIs · plans from $10/month
Deploy Ruby on Rails.Make the Rails release reviewable.
Install locked gems, prepare assets, run Puma, verify application health, and connect database, Redis, secrets, logs, and domains to the release.
Keep the repositoryInspect build and logsCustom domains and TLS
Adios deploy
Candidate release
Ruby on Rails
SOURCE
Git
REGION
de
ROUTE
HTTPS
01Source received
02Build completed
03Runtime started
04Health check passed
Promoted route
production.adios.run
A production path for
RailsRubyPumaBundlerPostgreSQLRedis
The production path
A working Ruby on Rails project still needs a safe release.
The application or service is only one part of production. Build evidence, runtime state, health, secrets, logs, routes, and the promoted version should remain inspectable together.
Promote the version that reports healthy
Start Puma with production configuration, bind to the declared port, and use a health endpoint that shows whether the web process can safely receive traffic.
Trace production back to source
Build output, runtime logs, health state, secrets, domains, and the promoted release stay attached to the project instead of being split across unrelated tools.
From source to release
Three steps keep the deployment path reviewable.
Use the source and production behavior the project already has. The manifest records what the platform should build or provision and how the result becomes ready.
- 01
Start with source or a template
Bring the existing repository, or inspect and deploy one of the exact starter variants linked below.
$adios login - 02
Review the deployment contract
Keep commands, runtime or service version, health behavior, and secret references in adios.yaml.
$git diff -- adios.yaml - 03
Deploy and inspect the result
Follow build and runtime evidence, verify the candidate, and open the promoted route or service connection.
$adios up
adios.yaml
Your projectname: rails-app
build_cmd: bundle install && bundle exec rails assets:precompile
start_cmd: bundle exec puma -C config/puma.rb
runtime:
name: ruby@3.2
port: 8080
health_path: /upConfirm the Rails health route, asset strategy, Ruby version, and migration workflow for your application.
Deployable starting points
Start Ruby on Rails from a template when the repository is not ready.
Inspect the Rails starter's Gemfile, Puma command, source path, and Adios manifest before deploying or cloning it.
API starters
Ruby on Rails
Rails, Sinatra, Grape, Hanami, and Roda starters with Bundler and Adios config.
RubyBundler
- Template key
- ruby-rails
- Runtime
- ruby
- Repository
- templates
- Source path
- ruby/rails
git clone https://github.com/adiosdotdev/templates.git
cd templates/ruby/rails
adios upBefore production
Verify the workload.Then promote it.
The safest first release starts with a reproducible build or service configuration and a preview that exercises the dependencies production will actually use.
Ready when…
- Bundler installs from the committed lockfile.
- Assets compile with production environment settings.
- Puma binds to the configured port.
- Rails credentials and database URLs come from secrets.
Preview when…
- A migration changes a large or heavily used table.
- Active Storage needs persistent or object storage.
- Sidekiq or another worker depends on Redis.
Questions, answered
What to know before deploying Ruby on Rails.
Review the runtime or service boundary, template path, failure behavior, and production checks before creating the first release.
Can Adios deploy an existing Ruby on Rails project?
Yes. Run the Adios CLI from the project root, keep the repository and dependency files you already use, and add an adios.yaml file that describes the production build, start command, port, and health path.
Do I need Docker to deploy Ruby on Rails?
Not for a standard supported runtime. Use the project's normal production commands in adios.yaml. If the build needs unusual operating-system packages or native libraries, verify those dependencies in a preview before promotion.
Should Rails migrations run in the build command?
Production migrations deserve their own reviewed release step, especially when they can lock or rewrite data. Test them and define rollback or compatibility behavior before promotion.
Can Rails use PostgreSQL and Redis templates?
Yes. Deploy the required data services, store connection credentials as secrets, and verify connection recovery plus application health during service restarts.
What happens when the build or health check fails?
The candidate release keeps its build and runtime output for inspection. It must report healthy before it becomes the promoted version serving the application route.
Can I start from a template instead of an existing repo?
Yes. This page links to the closest official Adios Ruby on Rails starters. Inspect the exact source variant, deploy it in the console, or clone it locally and run adios up.
Related deployment paths
Connect the rest of the stack.
Deploy Ruby
Install the locked gems, start Puma or the process your framework expects, verify the health route, and keep runtime configuration out of source.
Deploy PostgreSQL
Choose a PostgreSQL version, keep database credentials out of Git, attach persistent storage, connect the application, and verify data after a restart.
Deploy Redis
Start Redis 7 for cache, session, pub/sub, or fast state workloads, then verify connectivity, persistence expectations, eviction, and dependency failure behavior.
Deploy Adios workflows
Deploy scheduled jobs, webhook processors, approval gates, maintenance tasks, and operational automation from a versioned workflow manifest.
The first release
Deploy Ruby on Rails with the source and evidence attached.
Start from the repository or a template, review the deployment contract, and inspect what becomes the promoted production version.