Answers
Getting a Rails app onto a server you control, and what breaks on the way.
Yes, for one server. Rails 8 ships SQLite configured for production use, and One Shot runs on it: the database is a file on a mounted volume, backups are a file copy, and there is no second service to operate. The limit is real though. Two application servers cannot write to the same SQLite file, so horizontal scaling is where it stops.
Run sqlite3 storage/production.sqlite3 ".backup /tmp/out.sqlite3" inside the container, then copy the result off the host. The .backup command takes a consistent snapshot while writes continue; a plain cp of a live database gives you a file that looks fine and fails on restore. Store it somewhere the server cannot reach.
Use Kamal, which ships with Rails 8. You give it a server over SSH and a container registry in config/deploy.yml, run kamal setup once, and kamal deploy after that. It builds an image, pushes it, and swaps containers with no downtime. A $5 VPS replaces the PaaS.
Run kamal deploy as a workflow step. Kamal needs three things in the runner: an SSH key that can reach the server, registry credentials, and RAILS_MASTER_KEY. All three go in as repository secrets and are read by .kamal/secrets. Gate the deploy job behind the test job so a red build never ships.
Old container images are the cause, not your app. Every deploy pushes a new image and the server keeps the old ones. Run docker image prune -a -f to reclaim the space, then check with df -h. On a 25GB VPS this usually returns several gigabytes, and it is worth doing before you are locked out rather than after.
Run kamal app exec --interactive --reuse 'bin/rails console'. That attaches to the running container rather than booting a new one, so you see live data. One Shot ships no admin UI on purpose, so the console is the supported way to inspect and fix records, and everything you touch must go through an Account.
Create an A record for the apex pointing at the server's public IPv4 address, and a CNAME for www pointing at the apex. Set the same hostname in the proxy section of config/deploy.yml and redeploy. Kamal's proxy requests a certificate on the first request to that host, so HTTPS starts working within a minute of DNS resolving.
Run kamal rollback to boot the previous image, which is still on the server. It takes seconds because nothing is rebuilt or pulled. Your code goes back; your database does not. A deploy that ran a destructive migration cannot be undone this way, which is why additive migrations matter more than the rollback command.
Give the second app its own service name and its own host in config/deploy.yml. Kamal's proxy routes by hostname, so two apps share port 443 without conflict. What collides is anything pinned to a fixed host port, and the database volume path, which must differ or the two apps will share one SQLite file.
Run kamal app logs --follow to stream, or kamal app logs --lines 200 --grep Error to search what already happened. Rails 8 logs one line per request in production, so the useful move is filtering by request id and following that one request through the job and mailer lines it produced.
Four things: a Linux server you can SSH into, somewhere to push a container image, a domain pointed at the server, and RAILS_MASTER_KEY. That last one is the only secret production will not boot without. Billing, email and bot checking all fall back to in-process fakes, so you can ship before you have those keys.
The encrypted credentials are gone. RAILS_MASTER_KEY is the only thing that decrypts config/credentials.yml.enc, and there is no recovery path by design. Delete both files, regenerate them, and re-enter every secret from its source. Production will not boot until the key reaching the server matches the file in the repo.
A mailer runs in a background job with no incoming request, so it cannot infer your domain. It reads APP_HOST instead, and without that set it falls back to the development default. Set APP_HOST to your domain, redeploy, and every mailer link, canonical tag and sitemap URL becomes absolute and correct.
The server cannot log in to the registry that holds your image. Kamal pushes from your machine, where you are already authenticated, then asks the server to pull, where it is not. Check the registry block in config/deploy.yml names the right username, and that KAMAL_REGISTRY_PASSWORD is actually set in .kamal/secrets.
The new container started and exited before Rails could answer /up. Kamal waits, then rolls back and leaves the old container serving. Run kamal app logs to see the real error. On a first deploy it is almost always a missing or wrong RAILS_MASTER_KEY, which raises before any route exists to answer the check.