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 our default. |
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, and SECRET_KEY_BASE is made for you. Rails starts with Puma on the port in PORT, which is 8080, and db:prepare runs before each version goes live.
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 our default when it meets everything your code asks for, otherwise the newest version that does, 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, counted every minute and paid by your saved card. The limits you set cost nothing by themselves.
Memory is $5.99 per GB a month and a processor $11.97 a month, counted by the minute. Builds are $0.004 a minute, and storage $0.15 per GB a month.
Ruby on Rails
A month of this use
- Memory: 0.35 GB, all month
- $2.10
- Processor: 3% of one, all month
- $0.36
A month
$2.45