# How to deploy a Rails 8 app to a VPS Source: https://tenkai.cloud/help/deploy-rails > Use the Dockerfile Rails 8 generates without Kamal, keep its cache, queue and cable tables in one PostgreSQL database and migrate before traffic. This guide deploys a Rails 8 app to your own server with the Dockerfile Rails generates, and without Kamal. The changes that matter are few, a port for Thruster, one database for Solid Cache, Solid Queue and Solid Cable, and migrations that run once before the new version takes traffic, and the last sections deploy it with Tenkai and PostgreSQL. We tested it on 2 November 2026 with a new app from `rails new --database=postgresql`, on Rails 8.1.4, Ruby 4.0.9 and PostgreSQL 18, so adapt the configuration to your own app. ## Prerequisites You need a Rails 8 app that uses PostgreSQL, in a Git repository with a CI such as GitHub Actions. Docker is useful to test the image on your machine, and the Tenkai part needs a [project on a ready cluster](https://tenkai.cloud/help/projects-and-clusters). `rails new` writes a production `Dockerfile`, a `.dockerignore` and `bin/docker-entrypoint`, and this guide changes them only a little. Keep `config/master.key` out of Git, which the generated `.gitignore` already does, because it decrypts your credentials. ## Make Thruster listen on 8080 The image starts Thruster, which serves your assets and passes the other requests to Puma. Thruster listens on `HTTP_PORT`, 80 by default, so set it in the `ENV` line of the `base` stage and change the `EXPOSE` line to match. ```dockerfile ENV RAILS_ENV="production" \ BUNDLE_DEPLOYMENT="1" \ BUNDLE_PATH="/usr/local/bundle" \ BUNDLE_WITHOUT="development" \ LD_PRELOAD="/usr/local/lib/libjemalloc.so" \ HTTP_PORT="8080" ``` ```dockerfile EXPOSE 8080 ``` Puma keeps port 3000 inside the container, behind Thruster, even when Tenkai sets `PORT`. ## Keep everything in one database A new Rails 8 app expects four production databases, one for your data and one each for Solid Cache, Solid Queue and Solid Cable. A managed database usually gives you one, and its user cannot create others, so point them all at it. Replace the `production` section of `config/database.yml`. ```yaml production: <<: *default url: <%= ENV["DATABASE_URL"] %> ``` Then remove what sends each Solid gem to its own database. - In `config/cache.yml`, delete the `database: cache` line under `production`. - In `config/cable.yml`, delete the `connects_to` block under `production`. - In `config/environments/production.rb`, delete the line `config.solid_queue.connects_to = { database: { writing: :queue } }`. The tables of the three gems are described in `db/cache_schema.rb`, `db/queue_schema.rb` and `db/cable_schema.rb`, which only their own databases load. Create them in your database with a migration, such as `db/migrate/20261102000000_create_solid_tables.rb`. ```ruby class CreateSolidTables < ActiveRecord::Migration[8.1] def up %w[cache queue cable].each { |name| load Rails.root.join("db/#{name}_schema.rb") } end def down raise ActiveRecord::IrreversibleMigration end end ``` ## Run the migrations once, before traffic `bin/docker-entrypoint` runs `./bin/rails db:prepare` each time a container starts the server, so each replica migrates as it starts. Delete the `if` block of `bin/docker-entrypoint`, which leaves it as follows. ```sh #!/bin/bash -e exec "${@}" ``` You will run `./bin/rails db:prepare` once for each deployment instead, which creates the schema on the first run and applies the pending migrations on the next ones. The previous version still serves while it runs, so add columns in one deployment and remove the old ones in a later one. ## Health check and HTTPS Rails answers `/up` with `200` once the app has booted, which makes it your health check. Tenkai's proxy terminates HTTPS, so uncomment `config.assume_ssl = true` and `config.force_ssl = true` in `config/environments/production.rb`, which `rails new` leaves commented unless you pass `--skip-kamal`. `config.assume_ssl` treats every request as HTTPS, so `config.force_ssl` never redirects the health check, and cookies stay secure. If you set `config.hosts` in `config/environments/production.rb`, also uncomment the `config.host_authorization` line that excludes `/up`, because a health check that calls the container directly sends its own name as the host. ## Test the image locally Try the image with a PostgreSQL container. ```sh docker build -t hello-rails . docker network create hello-rails docker run -d --name hello-rails-db --network hello-rails \ -e POSTGRES_PASSWORD=secret -e POSTGRES_DB=app postgres:18 cat > .env.docker <