Rails hosting bundle, precompile, live.
Push to GitHub. We read your Gemfile, pick your Ruby version, install your gems, precompile your assets and start Rails in production. Your migrations can run before visitors see the new version.
- Ruby3.3 → 4.0
- FrameworksRails, Rack, Sinatra
- Installs withBundler
- Priced byWhat it uses
We read your code, so you don't write a build script.
Every build shows what we found and each command we ran, line by line. Anything we found, you can change in the app's settings.
| File | What we do with it |
|---|---|
Gemfile | Ruby, and Rails when it lists the rails gem. We run bundle install without your development and test gems. |
.ruby-version | The Ruby version you use. Without it, the ruby line of your Gemfile, or the newest we offer. |
app/assets/ | Your assets: we run rails assets:precompile during the build, so the first visitor gets them ready. |
config.ru | A Rack app, like Sinatra: started with Puma when your Gemfile lists it, or rackup. |
tanzahost.json | Optional: the version, system packages, and the install, build and start commands. |
Rails in production, from the first deploy.
RAILS_ENV and RACK_ENV are production. Rails starts with rails server on the port in PORT, which is 8080.
Your secret key
Add SECRET_KEY_BASE, or RAILS_MASTER_KEY for your credentials file, to your variables. They're encrypted, and never in a log.
Exactly your Gemfile.lock
Gems install into vendor/bundle in deployment mode, so production runs the versions you tested, and a changed lock file is caught at build time.
Assets built once
Precompiling needs no real secret: the build uses a stand-in key, so your own never reaches the build.
Migrations run before visitors arrive.
Set bin/rails db:migrate as the “before going live” command. It runs once per deploy, in its own sandbox, after the build and before the switch.
If it fails, nothing changes
The deploy stops, and the version before it keeps serving your visitors.
Watched for five minutes
If the new version stops by itself within five minutes, visitors go back to the previous one, and we tell you.
Roll back in one click
The version before, deployed again without downtime.
Sidekiq and tasks beside your web app.
Run Sidekiq, Solid Queue or any long command as a worker, and rake tasks on a schedule, with your app's code and variables.
- Up to 5 workers per app, each with its own command, and limits of its own if you like.
- Up to 10 scheduled tasks, as often as every minute, in UTC, each stopped after an hour.
- PostgreSQL with connection pooling, MySQL or Valkey for Sidekiq in the same project, with DATABASE_URL and REDIS_URL added to your variables.
Ruby 3.3, 3.4 and 4.0.
We use the newest version that meets what your code asks for, or the one you pick in the app's settings. The next build uses it.
- Ruby 4.0Supported
- Ruby 3.4Recommended
- Ruby 3.3Supported
Ruby 3.3 gets security fixes until 31 March 2027. A version past its end of life shows a warning and the date it's removed.
A Rails app, priced in the open.
Say a Rails app holds 0.35 GB of memory and uses 3% of a processor, awake all month. You pay for that use, hour by hour, from your wallet. The limits you set cost nothing by themselves.
reading today's prices