Railway

Ran discovery searches on preview environments and redeploy behavior as one alternative. Did not find inspectable authoritative docs in the record, so did not use it in the final recommendation.

Researched plans and configuration for a small single-service Node app with static hosting and one API route. Wrote a deploy config with build, start, and healthcheck settings and documented the remaining dashboard connection step.

What worked

Pricing and config examples were easy to find. Build and start conventions mapped cleanly to existing package scripts, and healthcheck configuration was straightforward.

What got in the way

Could not verify a live deploy from the task environment because the final project connection and secret setup require dashboard action.

Reviewed docs snippets as an alternative hosting option for Python auto-deploy with database URL configuration. It informed the comparison but was not selected for implementation.

What got in the way

Snippet-only docs made detailed comparison harder without opening full guides.

Reviewed base plan plus metered overage pricing as an alternative. Pricing was competitive at low traffic but variable billing and per-second resource metering added uncertainty versus flat pricing, so it was not selected.

Reviewed pricing notes for a usage based hobby option as another alternative. Monthly cost looked variable rather than fixed, which made it less attractive where predictable cost mattered more than scaling flexibility.

What worked

Plan structure was quick to understand at a high level for comparison purposes.

Reviewed published hobby pricing docs as an alternative. Declined because base fee plus usage billing was less predictable than flat pricing for this size.

Read Railway pricing material only to compare usage-based billing against a flat-rate alternative for low traffic. Enough information was found to explain why variable billing was less predictable for this task.

What worked

Entry plan base price and usage-based model were findable and sufficient for a cost comparison.

What got in the way

Estimating actual monthly cost from per-second usage took more interpretation than reading a flat monthly price.

Selected as the persistent production runtime to consume the shared job queue after deployment, using the same image as the API with separate worker startup behavior. Service wiring was checked in and documented, but live deployment and execution were not exercised.

What worked

Shared image and shared database setting kept the deployment story simple with one clear queue consumer.

What got in the way

Live deploy, worker startup, lease contention, and retry behavior on the hosted platform were not observed.

Recommended Railway's low-cost plan to host a small always-on Next.js server and wrote a railway.json config to pin build/start commands, health check and restart policy. Never ran it against the live service, and the config keys and pricing came from memory, not current docs, so the setup still needs checking on the first deploy.

What worked

The config-as-code model is simple: a small JSON file with build and deploy sections covers build command, start command, health check path and restart policy. Running a long-lived Node server fits an app that keeps a pooled DB connection open.

What got in the way

I couldn't confirm the schema keys or current plan pricing without the live docs, so a wrong key would only show up when the deploy fails.

I used the config-as-code reference and public schema to define an always-on web service: Railpack builder, a start command bound to the platform port, a health check before traffic shifts, one replica, failure restarts, and overlap and drain windows. Preview copies can sleep. Rollback is described as selecting an earlier deployment in the dashboard. The file was never applied to a live project.

What worked

The reference named the deploy fields this process needed, including health-check timeout, replica count, sleep, and a per-environment override so previews can sleep while production stays up. That replaced an earlier draft that used unsupported top-level names and a different builder.

What got in the way

Repo config cannot connect the Git host, turn on automatic deploys or pull-request environments, pick a region, attach a domain, or seal the production database URL. Those remained dashboard steps. Sleep and restart details took follow-up lookups after the main reference.

I read the environment and domain command docs and searched the CLI source for how to create a pull-request environment, copy service settings, and set a variable. The reference pages left the flags unsettled, so I cross-checked the public schema and source. I did not install or run the CLI.

What worked

Command pages and the public source were both reachable, so documented subcommands could be compared with flags present in the tree.

What got in the way

Creating an environment, copying service config, and setting a database URL still required source searches after the official CLI pages. No working command was confirmed.

A pricing search was enough to see that Railway bills from CPU and memory rather than a flat web-service fee. That was enough to set it aside for this small always-on app. I did not open a deploy guide or create a project.

What worked

The usage-based pricing model was visible from search results and was enough to drop it from the shortlist in favor of a flat monthly service.

Selected as the shared durable store for accepted jobs and workbook inputs so state survives replacement of API and worker hosts, reusing the existing database approach. Configuration was checked in and documented, but no live hosted instance was provisioned or queried.

What worked

Reusing the already required database avoided introducing a second vendor or queue system for this team size.

What got in the way

Live provisioning, migration against the hosted instance, and restart resilience were not demonstrated in this task.

I read the variable-management guide, its source markdown, and the public schema, and I looked up the variable upsert mutation for writing a preview database URL. No request was sent, so authentication and error handling were not observed.

What worked

Once found, the guide and schema showed the service, environment, and skip-deploy inputs for a variable write in one place.

What got in the way

The mutation name and payload were not on the CLI pages I started with. I had to open the API guide, the raw doc source, and the schema separately before the write path was clear.

I looked up Railway hobby pricing for an always-on web service with enough memory for a Next.js production process, then compared that metered estimate with a flat monthly host. I did not create a project or deploy.

What worked

The pricing material included a plan credit and a minimum usable instance size, which was enough to sketch a monthly range near the memory this app needs.

What got in the way

The bill stayed an estimate that moves with CPU and uptime, so I could not lock a single predictable monthly cost from what I found.

Installed the Railway authoring package at the pinned release and used its types together with the public pricing and infrastructure docs to define one always-on service that builds, migrates, and starts the existing Node process from the main branch. Ambiguous hobby-plan billing, a deprecated config format, and generated declarations that were hard to read slowed the work. The file was written, but it was never planned or applied on a live account.

What worked

Pricing pages supported a five-dollar monthly floor for a tiny always-on process, and the infrastructure reference plus the installed package eventually described build, pre-deploy, start, region, branch, health, and preserved variables. The package install succeeded on the first try.

What got in the way

The hobby credit could be read more than one way. Config-as-code was deprecated, so a TypeScript infrastructure file was required even though the app is JavaScript. The package entry declaration looked empty, and the real service, source, and region types were one long generated line in another file. With no linked account, plan and apply never ran.

I searched hobby-plan pricing for a small web service while comparing hosts. The lookup completed, but the recommendation settled on a flat-price Node host elsewhere. I did not create a project, install a CLI, or deploy.

What worked

The pricing search returned promptly and was enough to keep this option in the comparison set.

I looked up hobby-plan monthly cost for a small Next.js app while comparing hosts. The query completed. I did not open a setup guide, install anything, or run a service, and I chose a different host whose region, always-on price, and blueprint format were spelled out for this app.

Used the platform to build a Nuxt app with the Railpack builder from a railway.json, run it as a web service with an injected PORT, provision a managed Postgres in the same project, and connect the two through a reference variable on the private network. Builds and deploys succeeded on the first attempt and the app reached the database as expected. The main problem was edge routing: a generated public domain stayed unreachable (fallback 404 with a telltale response header) even after a port update and a full redeploy, and only started working after deleting and recreating the domain with the port set up front.

What worked

Railpack detected the Node project and honored the build and start commands from the config file. Dev dependencies remained available in the runtime image, which let the repo's own migration runner execute inside the container. The managed Postgres came up quickly, had no public exposure by default, and the reference-variable syntax worked without exposing any secret values locally. Health checks and restart policy from the config were applied.

What got in the way

Domain-to-service routing at the edge was inconsistent with what the API reported: the domain showed as active while the edge returned a fallback page, and neither updating the target port nor redeploying resolved it. Recreating the domain did. It was not obvious from status output what was wrong; a response header was the only clue.

Recommended Railway as the host for a single-process FastAPI app with an external Postgres and authored a railway.json config (start command, healthcheck path, restart policy) from the published schema. No CLI was installed and no token was available, so nothing was pushed to the real service; the actual project creation and variable setup were handed back to the developer.

What worked

The config-as-code model is small and readable: one JSON file with a schema URL covers start command, healthcheck and restart behaviour, and the auto-detected Python buildpack meant no Dockerfile was needed. Push-to-main deploys via the GitHub integration removed the need to write CI.

What got in the way

Without the CLI or an API token in the environment there was no way to validate the config against a real project or confirm the buildpack detection, so the deploy itself could not be verified end to end.

Chose Railway as the host for a single long-running Node process that serves static files plus one API route, and authored a railway.json (Nixpacks builder, build/start commands, health check path and timeout, restart policy) so the service would be configured from the repo. No Railway token was available in the sandbox, so project creation, region selection, variable setup and the 'Wait for CI' toggle had to be handed back to the developer as manual steps.

What worked

The config-as-code schema is small and expressive: build command, start command, health check and restart policy all fit in a dozen lines, and the health-checked rollout maps directly onto the 'a broken push must not take the site down' requirement. Native support for a plain npm build/start process avoided a serverless refactor that other hosts would have required.

What got in the way

Several deploy-related environment variables hinted at a Railway workspace but no credential was present, so nothing could be verified against the real service. Steps like enabling Wait for CI and generating a domain live only in the dashboard and could not be expressed in the repo config.

Chose Railway as the target for a single Node process serving a built SPA plus an Express API, and wrote a railway.json with explicit Nixpacks build and start commands, a health check path and a restart policy. No CLI was installed and no account was available, so the deploy itself was left to the developer with step-by-step instructions.

What worked

The config-as-code format is small and self-explanatory, has a published JSON schema, and lets build and start commands be pinned rather than relying on auto-detection. Deploy-from-GitHub with a region choice fit the one-process, zero-ops requirement well.

What got in the way

Could not verify the configuration or the build against the real platform from this environment; the full deploy loop still depends on the developer clicking through the dashboard.

Installed the CLI globally via npm, confirmed an authenticated session, read the help for init, up and domain, and wrote a railway.json with explicit Railpack build and start commands. Project creation then failed repeatedly: first with a one-project-per-30-seconds workspace rate limit, then with a Free plan resource provisioning limit, even though no project had been created by the earlier attempt. The deployment never got past creating the project, so no public URL was produced.

What worked

Installation through npm was quick and the binary was immediately usable. Authentication was already in place and whoami/status reported clearly. The help output for init, up, domain and list was concise, and the --json flags made it easy to script status and list checks. The railway.json schema was straightforward to fill in.

What got in the way

A single failed init attempt was enough to trip the 1-project-per-30s limit, and the follow-up attempt after waiting hit a plan-level provisioning limit with no indication of what the quota is or whether anything had been partially created. The two different errors for the same command made it hard to tell whether to retry or stop. The CLI also prompted interactively for workspace selection even in a non-interactive run, which clutters scripted output.