Deploy Ruby on Rails with AZIN

Heroku was Rails' home for 15 years. The push-to-deploy workflow, the Procfile, the heroku run rails console — all shaped how the Rails community thinks about deployment. AZIN brings that same developer experience to your own GCP account. Rails hosting that you own: your cloud, your data, your infrastructure bill — with none of the DevOps overhead.

#How AZIN detects Rails

AZIN uses Railpack to auto-detect your project. When it finds a Gemfile containing the rails gem, it identifies a Ruby on Rails application and configures the build automatically. No Dockerfile required. No Procfile required for standard setups.

What Railpack sets up for you:

• Ruby version from .ruby-version file (defaults to 3.4.6 if not specified)
• Dependency installation via bundle install with frozen lockfile
• Asset pipeline — runs bundle exec rails assets:precompile during the build phase
• bootsnap precompilation — speeds up boot time by caching code loading
• jemalloc — a memory allocator that reduces Rails memory fragmentation in production
• Puma as the web server, configured with appropriate thread/worker counts

The default start command Railpack generates for a Rails app:

bundle exec rails server -b 0.0.0.0 -p $PORT

If you have a Procfile, Railpack respects it. The standard Rails Procfile for a multi-process setup:

web: bundle exec rails server -b 0.0.0.0 -p $PORT
worker: bundle exec sidekiq -C config/sidekiq.yml

#Deployment config

Connect your GitHub repository to AZIN and it deploys on every push. For a full Rails production setup with PostgreSQL and Redis:

name: my-rails-app
cloud: gcp
region: us-central1
services:
  web:
    build:
      type: railpack
    env:
      RAILS_ENV: production
      RAILS_LOG_TO_STDOUT: "true"
      RAILS_SERVE_STATIC_FILES: "true"
    scaling:
      min: 1
      max: 10
      target_cpu: 70
  worker:
    build:
      type: railpack
    start: bundle exec sidekiq -C config/sidekiq.yml
    env:
      RAILS_ENV: production
  db:
    type: postgres
    plan: production
  cache:
    type: redis

DATABASE_URL and REDIS_URL are injected automatically into all services. No manual connection string wiring.

#Rails credentials and environment variables

Set secrets through the AZIN console. A CLI is on our roadmap — the commands below show the planned interface:

azin env set SECRET_KEY_BASE "$(bundle exec rails secret)"
azin env set RAILS_MASTER_KEY "your-master-key-value"

Configure config/database.yml to read from the environment:

production:
  url: <%= ENV['DATABASE_URL'] %>
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

DATABASE_URL and REDIS_URL are injected automatically when you declare db and cache services. For SECRET_KEY_BASE, generate one and set it in the console — Rails 7.2+ recommends env var over credentials files for containerized deployments.

RAILS_SERVE_STATIC_FILES tells Rails to serve assets from /public/assets directly (no Nginx needed). Combined with RAILS_LOG_TO_STDOUT, logs appear in the AZIN console log viewer in real time.

#Background jobs with Sidekiq

Add a separate worker service in azin.yaml — it shares the same codebase, DATABASE_URL, and REDIS_URL as the web process:

services:
  worker:
    build:
      type: railpack
    start: bundle exec sidekiq -C config/sidekiq.yml
    env:
      RAILS_ENV: production

A minimal config/sidekiq.yml:

:concurrency: 5
:queues:
  - [critical, 3]
  - [default, 2]
  - [low, 1]

For Action Cable (WebSockets), set the Redis adapter in config/cable.yml:

production:
  adapter: redis
  url: <%= ENV.fetch("REDIS_URL") { "redis://localhost:6379/1" } %>
  channel_prefix: my_app_production

Both Sidekiq and Action Cable use the same Memorystore instance provisioned by AZIN. Worker pods scale independently from web pods.

#Why AZIN for Rails hosting

Your cloud, not a platform's. Your Rails application and PostgreSQL database run in your GCP account. You own the infrastructure, the data residency, and the cloud billing relationship. GCP deploys today via GKE Autopilot — first cluster free, pay only for pods. AWS and Azure are on our roadmap.

No dyno sleeping. Heroku's Basic dynos ($7/mo, as of February 2026) sleep after 30 minutes of inactivity. AZIN's minimum replica count is 1 — your app is always warm. On lttle.cloud (in early access), staging environments scale to zero so you only pay for what you use during development.

Managed PostgreSQL and Redis in your account. AZIN provisions Cloud SQL (PostgreSQL) and Memorystore (Redis) in your own GCP project. Automated backups, encryption at rest, and connection strings injected automatically. No separate database bill from a third-party provider.

Rails 8.0 ready. Rails 8.0 (released November 2024) ships with Thruster for HTTP/2 and asset serving, Solid Cache and Solid Queue for zero-Redis background jobs, and Kamal 2 for self-hosted deployments. Railpack supports the full Rails 8 stack. If you'd rather have managed infrastructure than Kamal's self-hosted model, AZIN handles the layer Kamal would otherwise require you to manage.

#Related guides

• Deploy Docker containers with AZIN — For custom Dockerfile deployments
• Host PostgreSQL on AZIN — Managed Postgres in your own cloud
• AZIN vs Heroku — Rails' historical home, compared directly
• AZIN vs Railway — Popular Rails deployment platform
• Best Heroku alternatives in 2026 — Full guide if you're migrating

#Frequently asked questions