Rails’ documented route to a VPS is Kamal: it builds the application’s production Docker image and deploys it to a Linux server. That gives you a repeatable starting point, but you still need to choose capacity, database placement, secrets, DNS, backups and monitoring for your particular app.
The Rails Guides’ example uses an Ubuntu LTS server with at least 1 GB RAM. Treat that as a documented starting example, not a promise that this size will suit your workload. The guide’s sequence is to configure the deployment, provide registry credentials, run bin/kamal setup for the first deployment, and use bin/kamal deploy for later releases.
Choose the deployment approach with Kamal
Kamal is the production deployment route taught by the current Rails Guides getting-started guide. It deploys the app in Docker containers, using the production Dockerfile in the Rails project to build the image. You can therefore follow a documented Rails path without treating a VPS as a blank machine on which every application component must be installed by hand.
For a first deployment, the basic flow is straightforward: provision a server and SSH access, create a container registry account and token, configure the service and server in config/deploy.yml, then run bin/kamal setup. Later releases normally use bin/kamal deploy. The first command sets up what the deployment needs on the remote host; it is not a substitute for checking what your application depends on or whether the resulting service is healthy.
A container-based route suits you if you are willing to use Docker images and want deployment settings that can be reviewed and repeated. The alternative is a manual host setup, often with Puma supervised by systemd. Puma’s systemd documentation describes systemd as a common Linux init system and gives a service-unit example. That is one piece of process management, not a complete Rails deployment recipe: you still own Ruby and application installation, secrets, proxy and TLS, assets, migrations, logs, backups and rollback.
If you already maintain a manual deployment reliably, switching is not automatically an improvement. Compare the host configuration you would otherwise maintain with the image-building and deployment workflow you are prepared to operate. Similarly, a VPS is not required just because Rails supports one. A managed platform can be a better fit if you want less server administration and are comfortable with its cost, conventions and limits.
Prepare the VPS and production environment
The Rails Guides’ Kamal example calls for an Ubuntu LTS server with at least 1 GB RAM and a container registry account. The guide uses Docker Hub as its registry example and names Hetzner and DigitalOcean as example VPS providers; it does not rank providers. Those example requirements are useful for understanding the documented path, but they do not establish what your app needs in production.
Size the VPS around the work it must do. Consider the Rails web process, database if it will share the host, background jobs, scheduled work, asset build and deployment activity. A new image may need to be built or pulled while the current release is still serving requests. If memory or disk is already close to its practical limit, that overlap can matter even when ordinary traffic is modest. Measure your own application under representative use rather than copying the guide’s example as a universal recommendation.
When comparing plans, look beyond the headline memory figure. Check the CPU allocation, storage type and capacity, included network transfer, backup or snapshot options, region, support and total cost on the provider’s current pages. A server near your audience may reduce network distance, but region choice also affects data location, service availability and the location of any managed database. There is no provider choice in the Rails guide that settles those questions for you.
Before first deployment, confirm that you can reach the server over SSH with the account and key you intend to use. Restrict access to that account and keep the key private. Decide how you will reach the application’s logs and how to investigate a failed release. A successful command is evidence that a deployment step ran; it does not establish that the app can process a real request, connect to its database, deliver email or run its background jobs.
The app’s production environment also includes dependencies that are easy to overlook when the site first appears. List uploaded files, outbound email, scheduled jobs, third-party APIs, and any separate worker processes. Decide which of those run on this VPS, which are external services, and who is responsible when one is unavailable. This inventory will influence the server size and the database and backup decisions that follow.
Configure secrets and deployment settings
Kamal’s deployment configuration belongs in config/deploy.yml. The Rails walkthrough uses it to identify the service and image, the target server address and the registry username. Keep ordinary configuration reviewable, but do not put passwords, tokens or private keys into a committed file. Before deployment, check the repository and its history for secrets that may have been added accidentally.
A private image registry needs a credential so the deployment can publish and retrieve the image. Kamal documents KAMAL_REGISTRY_PASSWORD for that purpose. Rails also needs its RAILS_MASTER_KEY when the application uses encrypted credentials. See the Kamal secrets documentation for the current mechanism and requirements; confirm the exact settings against the version you are using rather than copying an old example without checking it.
Use a protected environment or secrets mechanism to provide credentials at deployment time. Limit who can read or change them, and rotate a token if it is exposed. Do not paste production values into issue trackers, chat messages or shell commands that will be saved in history. If you need a Rails console on the remote app, Kamal documents bin/kamal console; treat that as privileged production access, not as an ordinary debugging shortcut.
Review config/deploy.yml before the first setup and whenever you change the host, image or proxy settings. Confirm that the server address is correct, that the registry account can use the intended repository, and that the deployed service name does not collide with another service. If your app uses a non-default registry, configure that deliberately. A configuration file can be syntactically valid while still pointing at the wrong host or image.
Decide where the database will run
The Rails deployment guide does not prescribe a database topology for every app. You can run a database on the same VPS, put it on a separate server, or use a managed database. The right choice depends on workload, operating capacity, network dependence, restore needs and cost; the fact that the app fits on one VPS does not by itself mean the database should share it.
| Placement | What you gain | What you take on |
|---|---|---|
| Same VPS as Rails | Fewer machines to administer and no separate network hop between app and database | Shared CPU, memory and storage; a host problem affects both; you must plan database backups and restores |
| Separate VPS | More control over resource separation and database configuration | More administration, network and access control, and a dependency on connectivity between machines |
| Managed database | The provider operates the database service and may offer its own maintenance and recovery features | Recurring cost, provider-specific limits, network dependency, and the need to understand and test its backup and restore arrangements |
For a small app with modest needs, one host may be a reasonable operational choice if you understand that a disk or host failure can affect both app and database. For an app where database recovery matters more, separating it can make failures easier to isolate, but only if you have a working network and a tested recovery plan. A managed service can remove some routine database administration; it does not remove your responsibility to select retention, access controls and a restore procedure.
Write down where persistent data lives before deploying. This includes database data and, if the application accepts uploads, the uploaded files themselves. A container image is not a backup of either. Check that deployment or replacement of the app does not discard data stored only inside a container or on an unprotected local path. Test a restore into a suitable environment before relying on backups for recovery.
Also plan for schema changes. Rails migrations may alter the database while a release is changing, and a failed deploy does not necessarily mean a database change can be reversed safely. Review migrations that remove or transform data, retain an appropriate backup before risky changes, and decide how you would roll back the application if the old code cannot work with the new schema.
Connect the domain and configure DNS
Choose the hostname visitors will use, then point its DNS record to the VPS address. The Rails deployment example uses the server IP in config/deploy.yml; its domain flow requires DNS to point to the server before certificate issuance. Check the DNS provider’s current interface and allow for records to update before concluding that the proxy or app is misconfigured.
Set the hostname in the Kamal proxy configuration and enable SSL as described by the Rails deployment guide. If you are using a subdomain, verify that the record is for that exact name, not only the parent domain. Check the site from outside your own network and confirm that the browser reaches the expected application rather than a default page or another service on the host.
The proxy can also be relevant when the VPS runs more than one app. Rails 8’s release announcement describes Kamal Proxy routing multiple applications and its certificate support. That is useful architectural context, not a reason to assume every version and configuration behaves identically. Check the live guide for the Kamal version and settings in your project.
Set up HTTPS and SSL
In the documented Kamal flow, once the hostname points to the server and the proxy is configured for that host with SSL enabled, Kamal uses Let’s Encrypt to obtain a certificate. That is a defined certificate flow, not proof that DNS, proxy configuration, renewal or application behaviour is correct in your deployment. Verify the live site over HTTPS and check that requests use the intended hostname.
If certificate issuance fails, inspect the hostname, DNS answer, proxy settings and reachability of the server before changing unrelated Rails settings. A test on the server itself may not reveal a public DNS issue. If you use a manually managed proxy or TLS arrangement instead of the guide’s proxy flow, you own its certificate provisioning and renewal process; follow the relevant software’s current documentation.
HTTPS protects connections between visitors and the site when configured correctly, but it does not secure every part of a production app. Review cookie settings, application secrets, database credentials and administrative access separately. Do not describe deployment as a guarantee of SSL correctness or production readiness: check the current official instructions and verify the service from a client’s perspective.
Plan backups, monitoring, and updates
Backups are a separate operational decision from deploying Rails. Identify every persistent item that would be costly or impossible to recreate: database records, uploaded media, and any configuration or files held only on the server. Choose where backups are stored, who can access them, how often they are made, and how long they are retained. The official deployment walkthrough does not set a universal retention period or a backup provider for your app.
A backup matters only if you can restore it. Practise restoring a database and files into a non-production environment, then check that the Rails app can use them. Keep a written recovery sequence that identifies credentials, DNS changes and any external services needed. Snapshots can help with recovery, but check what they include and how independently they are stored before treating them as the only copy.
Monitoring should tell you about failures that matter to users, not merely whether a process exists. Check that the site responds over its public hostname, that background jobs are progressing, and that the database and external services remain reachable. Review logs after a release and establish how you will be notified if the app stops responding or disk space becomes constrained. The appropriate checks depend on the services your application uses.
Make updates part of ordinary operations. Review Rails, Ruby, operating system and dependency updates, test changes in a suitable environment, and deploy through a repeatable release process. Before a release with a risky migration, consider the recovery path and whether the previous application version can work with the changed data. Keep a record of what changed so that a late-night problem can be connected to a release rather than diagnosed from memory.
If your main need is to keep a recorded video looping on YouTube rather than operate a web application, a VPS setup has different failure modes and responsibilities; our guide to running a YouTube loop with systemd and FFmpeg covers that separate use case. Likewise, keeping a VPS stream running after disconnecting with tmux is about a streaming process, not Rails deployment. These distinctions matter when deciding what you are actually trying to keep online.
A Rails app may itself support a live channel or other always-on service, but operating the application and operating a continuous stream are separate tasks. For a stream-specific VPS example, see checks for YouTube live stuttering on a VPS. If instead you are choosing infrastructure for an always-on rain stream, the trade-offs in alternatives to cloud services for rain streams can help frame that different decision.
Before committing to a server and workflow, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Is Kamal the only way to deploy Rails to a VPS?
No. Rails’ getting-started material documents Kamal, while a manual setup can run Puma under systemd and use a reverse proxy. Kamal gives you a documented container-based route; a manual route gives you more direct host control but leaves more setup and ongoing configuration to you.
Does the Rails example’s 1 GB VPS suit every production app?
No. The Rails Guides state at least 1 GB RAM for their example server, not as a universal production sizing rule. Account for the app, database, workers, storage, traffic and deployment activity, then assess the actual workload.
Does Kamal set up a domain and HTTPS automatically?
The Rails guide describes pointing DNS to the server, configuring the proxy hostname and enabling SSL so Kamal can use Let’s Encrypt. You still need to verify the DNS, certificate and public site for your own configuration, and follow current documentation if your versions or proxy setup differ.
Are backups and monitoring included in the deployment?
Do not assume so. Decide which data must be recoverable, where backups live, how they are retained and how restores will be tested; separately choose checks and alerts for the app and its dependencies. The deployment walkthrough does not determine those app-specific operating arrangements.