Railway vs Render: Pricing, Free Tiers & Cold Starts

Both platforms support backend services and workers. The useful distinction is how you pay for capacity and how you operate stateful services. List the API, worker, database, scheduled tasks and frontend separately before estimating a bill. A free web service is not a free production stack.

For intermittent traffic, check whether sleeping is acceptable. For continuous jobs, budget for a worker that remains available. For customer data, review the selected database plan, recovery process and network access before optimising a small hosting-price difference.

Railway supports automatic application builds and Dockerfiles; Render supports native runtimes and Docker deployments. Use the same application health check and start command when comparing them. There are no measured deployment-time or latency results in this comparison.

Render Free web services spin down after 15 minutes without inbound traffic. Their next request must wait for startup. Paid instances avoid this free-tier idle policy. Railway can keep a service running or use optional serverless sleeping. Database connections or background activity may affect whether an application becomes idle. Test your app after an idle period rather than assuming every request will behave the same.

Railway Free includes $1 monthly credit; its initial $5 trial is a separate, one-time allowance. Render grants 750 free web-service instance hours per workspace each month, shared across services. Render Free PostgreSQL expires 30 days after creation; it is not an ongoing free database.

These are planning estimates in USD per month, checked 9 September 2026, excluding taxes. They are not measured invoices or a performance benchmark. Model one API, one PostgreSQL database and one persistent worker, each running for a full billing month in one region. Assume average API use of 0.5 GB RAM and 0.1 vCPU; database use of 0.25 GB RAM and 0.05 vCPU; worker use of 0.25 GB RAM and 0.05 vCPU; a 1 GB database volume; and 5 GB total public egress. No replicas, backup storage, paid add-ons or extra environments are included. Capacity must be load-tested: equal application roles do not imply equal CPU performance, database management or availability.

Railway resource estimate: API (0.5 × $10 + 0.1 × $20) = $7; database (0.25 × $10 + 0.05 × $20) = $3.50; worker (0.25 × $10 + 0.05 × $20) = $3.50; volume 1 × $0.15 = $0.15; egress 5 × $0.05 = $0.25. Total resources = $14.40. Hobby costs max($5, $14.40) = $14.40; Pro costs max($20, $14.40) = $20. The included usage is applied once across the workspace, not separately to each service.

On Render, select a $7/month 512 MB web service, a $7/month 512 MB worker and a $6/month 256 MB PostgreSQL instance with its included 1 GB storage. The worker has more allocated memory than the example uses. At 5 GB monthly bandwidth and builds within the workspace allowance, compute totals $7 + $7 + $6 = $20. Hobby workspace adds $0, giving $20; Pro workspace adds $25, giving $45. The Pro workspace fee does not include the compute charge. Current pricing differs from legacy plans, so check your existing account before changing it.

For a higher-use variant with 25 GB public egress and unchanged compute: Railway resources become $14.40 + 20 × $0.05 = $15.40 (Hobby $15.40, Pro $20). Render Hobby adds 20 × $0.15 = $3, reaching $23; Render Pro remains $45 because 25 GB is included. These are billing illustrations, not equal-performance or equal-availability guarantees. Additional storage, builds, replicas and paid features change the totals.

Render offers managed PostgreSQL with recovery features tied to the selected plan. Railway database services run from templates and volumes; inspect their maintenance and backup responsibilities. Do not equate a deploy button with a tested restore process.

Keep application-to-database traffic on the provider private network where supported. Record the connection-pool limit, database size and growth rate. Test recovery to a separate environment and confirm the backup window you actually purchased. For a cache or queue, determine whether losing state is acceptable before choosing a free or non-persistent configuration.

Railway meters actual resource use; Render instance sizing reserves a defined service allocation. Raising limits is different from adding replicas. On Render, horizontal autoscaling is a Pro workspace feature in current pricing. Check your account plan, database connections and shared state before enabling additional instances.

Neither a low price nor a larger instance establishes reliability. Make requests retry-safe where possible, put job state in durable storage, and test a worker restart. A deployment should only receive traffic after the application health check succeeds. Budget for monitoring and a restore rehearsal, not just the running container.

Capture a service inventory in version control: runtime version, build and start commands, health path, scheduled tasks, resource limits and environment-variable names. Keep secret values out of that inventory. Test external integrations and callback URLs against the new preview hostname.

A PostgreSQL application may use the same client library on both hosts, but connection strings, TLS requirements, pooling and network reachability can differ. Treat those as explicit checks, not evidence that a production data move will be effortless.

Start with a non-production environment and retain the existing deployment. Changing hosting and changing database schema are separate actions. The following checklist describes the planning work; it does not instruct you to run an unreviewed database migration.

Read Railway vs Vercel for a frontend-plus-backend architecture, Render vs Vercel for another hosting comparison, and Upstash vs Redis Cloud before adding a cache or session store.