Choose Ruby on Rails hosting by tracing the web process, static assets, persistent data and background jobs as separate responsibilities. A working homepage does not demonstrate that queued work runs or that a release can recover. Use a request-to-job acceptance exercise to compare the proposed environment with the application’s actual needs.
Start with the application’s release manifest and dependency list. Ask the developer to identify the Ruby and Rails versions, the web process, the asset-delivery route and the selected job backend. Keep those answers specific to the application. This guide uses Rails Active Job and Kamal proxy documentation to make the operational questions concrete; neither tool is imposed as a requirement for every Rails host.
Why is the background worker a separate hosting responsibility?
Active Job declares background jobs for execution on a queue backend. perform_later enqueues work, while perform_now executes without queueing. These Rails behaviours distinguish a request that schedules work from the later execution of that work. A hosting demonstration should show both when the application’s business task depends on them.
Action Mailer can send asynchronously through deliver_later. The Active Job guide therefore gives a familiar example of work that can sit outside the immediate web response. Ask which of your application’s messages use that route and who checks whether the corresponding jobs actually complete. A confirmation page and a completed background task deserve separate evidence.
Solid Queue is database-backed and the default Active Job backend from Rails 8.0 onwards. Job priority behaviour depends on the queue adapter. Keep those version and backend conditions with the proposal. Do not assume that a host mentioning Rails uses your intended backend or that a priority setting has the same effect across different adapters.
Ask the implementer to name the queues the application needs and the process responsible for each. Keep job persistence, monitoring and recovery in the scope discussion. Those operational arrangements should be demonstrated for the chosen backend rather than inferred from the existence of a Rails application directory.
What should the runtime, assets and proxy record contain?
Create a runtime entry with the required versions, build method, release identity and startup owner. Add a separate asset entry describing where the release’s stylesheets, scripts and images are served. These are proposed handover fields, not claims about a particular asset pipeline. Request a browser check of the actual rendered pages and referenced assets in the test release.
Kamal proxy settings are application-specific rather than shared by all applications on the proxy. Kamal can configure the application container port through app_port. The proxy reference provides specific values to inspect when Kamal is the selected deployment method. Compare the configured route with the port the intended application actually uses.
Kamal automatic HTTPS requires a single server, a configured host pointing to that server and reachable port 443. Kamal redirects HTTP to HTTPS by default when SSL is enabled. These documented conditions belong in the hostname and TLS portion of a Kamal proposal. Other deployment arrangements need their own applicable evidence; do not treat this example as a universal Rails requirement.
The Kamal proxy stops polling the deployment healthcheck after the app is up. That documented lifecycle makes a useful distinction: a deployment healthcheck is not evidence of continuous application monitoring. Ask separately who notices a later failure and how a meaningful user task is checked after recovery.
Original request-to-job acceptance trail
Consider a hypothetical Rails reporting app. A user requests a summary, a background job prepares it and the interface later offers the result. The following original worksheet tests that journey in an isolated environment with fictional data. It does not report a running application or promise a completion time.
| Step | Observation to retain | Responsible role | What remains unproved by this step alone |
|---|---|---|---|
| Open the test release | Page, release identity and asset requests | Web deployment owner | Background processing works |
| Request a summary | Approved request record and acknowledgement | Application owner | The queued job has run |
| Inspect the queue | Intended job associated with the test request | Queue operator | The business result is correct |
| Observe execution | Job outcome and relevant diagnostic evidence | Worker operator | The user can retrieve the result |
| Retrieve the summary | Result corresponds to the fictional inputs | Product tester | Recovery from interruption works |
| Rehearse recovery | Agreed test interruption and resumed workflow | Recovery owner | Every production failure is covered |
Begin by checking the page and assets from the same release. Record missing files or incorrect references as specific observations. Do not accept a familiar-looking page as proof that the intended release is serving all its required assets. Ask the application owner to explain how the deployment keeps that relationship coherent.
Next, create a single identifiable test request and trace it through the queue and worker. Retain enough context to connect the observations without exposing sensitive payloads. If the acknowledgement appears but the job is not observed, investigate that handover. If the job completes but the result is unavailable to the user, preserve both observations rather than relabelling the whole journey as successful.
For the result check, compare the fictional inputs with the expected output defined before the test. A completed job status is useful operational evidence, but it is not a substitute for validating the task’s meaning. Record who can decide that the output is acceptable and which discrepancies require a code or configuration change.
How do you test interruption and recovery safely?
Agree the interruption scenario and recovery method with the implementer before running the exercise. Use a separate test deployment and approved data. Ask what happens to the chosen job if its worker stops, and how the operator recognises the state afterwards. The answer must be tied to the configured backend and application behaviour.
Review duplicate work as well as missing work. For the fictional summary, define how the application should handle a repeated request or repeated execution before testing it. Do not assume that replaying a job is harmless for every business task. A later application involving external actions needs an explicit design for those effects.
Keep code recovery and stored-state recovery separate in the runbook. Reverting a release should not casually overwrite the data needed by pending work. Record compatibility questions, previous-release assumptions and the observations required before a later production change is approved. A saved container image or backup file does not establish a working restored workflow.
What should the hosting handover resolve?
The final handover should identify runtime versions, asset responsibility, web and worker processes, queue backend, persistent state, hostname routing and recovery ownership. Attach the request-to-job trail and unresolved questions. Compare hosting proposals against that evidence rather than against a generic claim to support Rails.
Use hosting, web development and business systems for the broader scope. To discuss a deployment, get started with the dependency list and the completed test trail. That gives the conversation a real application workflow to assess and makes background processing visible in the hosting decision.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.