Hey, I recommend you to read the documentation regarding serverless, as this should answer all the questions you have regarding serverless. The cost is purely based on the amount of resources used for a certain period of time, the exact cost of each resource, such as memory can be found at https://docs.railway.com/reference/pricing/plans#resource-usage-pricing.

@uxuz The documentation is unclear about how serverless affects costs.

What the docs say:

• Serverless can reduce service costs by running only when needed

• Trade-offs: cold boot delays and potential service deprioritization

My understanding of the pricing:

Regular:

• CPU × Usage

• Memory × Month

• Storage × Month

• Egress

Serverless:

• CPU × Usage (+ cold start overhead)

• Memory × Usage (Potentially less than ~30 days)

• Storage × Month

• Egress

Key difference: Serverless charges memory based on usage, rather than keeping the memory online for the entire month.

Hey, Railway is always usage based, please see the table below.

Serverless effectively means that your service will only run when needed, for example only run for an hour a day. You only pay for that one hour everyday, as opposed to 24/7 for the amount of resources used.

To clarify: Does a mostly idle 2x vCPU machine still cost the full $20/month?

If yes, this discourages creating new environments unless they’re serverless.

Example: I just deployed a Tailscale router that sits idle most of the time. I’ll switch it to serverless if I’m paying for unused compute.​​​​​​​​​​​​​​​​

You will be paying $40 if your service is using 2vCPU all the time for the entire month, even if they are idling. Serverless will reduce your usage significantly if this is the case.

Feedback: Even when provisioning replicas with fixed resources (e.g., 8 vCPU, 8 GB RAM) for an entire month, I'd like pricing to reflect actual resource usage through vertical scaling.

Currently, if users are billed for provisioned vCPUs regardless of usage, cost-conscious customers will likely under-provision their resources to save money, leading to performance issues.

That is the max. amount of resources your service's can scale up to, you only pay for what you use and not what the max limit is configured to.

These two statements are contradictory. If my vCPUs are idle, do I still pay for them?

That is the max. amount of resources your service's can scale up to, you only pay for what you use and not what the max limit is configured to.

You will be paying $40 if your service is using 2vCPU all the time for the entire month, even if they are idling. Serverless will reduce your usage significantly if this is the case.

The assumption is that you are constantly using 2vCPUs all the time.

My confusion is not settled.

To clarify:

• Allocated vCPUs: The resources reserved for your service (e.g., 2 vCPUs)

• Used vCPUs: The actual CPU cycles consumed (e.g., 0.2 vCPUs at 10% utilization)

If Railway charges for allocated vCPUs regardless of utilization, then an idle service with 2 vCPUs costs $40/month for the CPU even at 0% CPU usage.

If, on the other hand, Railway only charges for used vCPUs, then an idle service with 2 vCPUs costs $0 for the CPU at 0% CPU usage.

Railway only charges for used vCPUs, then an idle service with 2 vCPUs costs $0 for the CPU at 0% CPU usage.

While the UI may show you 0.0 vCPU, in reality, your application is likely using something like 0.03 vCPU, so there will still be a small amount of cost that shows up on the invoice.

But either way, we do indeed only charge for the resources that your application actually uses, regardless of what you set the maximums to.

@brody excellent. So switching from serverless to regular won't dramatically increase costs - just the overhead of keeping the container in memory plus minimal CPU cycles from idle processes.

Disabling serverless will definitely increase costs to some degree.

With serverless, your application can go to sleep, and when sleeping, there are no charges besides disk.

Otherwise, your service will always be online, and even though we only charge for the actual resources used, a service that is running is always going to cost more than a service that is not running (sleeping).