Railway's pricing page clearly explains how resource usage billing works.

Your Hobby plan subscription includes $5 of usage per month. If your total usage at the end of your billing period is $5 or less, you will not be charged for usage. If your total usage exceeds $5 in any given billing period, you will be charged the delta.

To limit the amount you're paying, you can set hard limits in your workspace settings > usage, but note that this will shut down all deployments once that hard limit is hit.

Also, allocation is not the same as usage. Even if Railway allocated 1 GB to your instance, if your app used 185 MB, you will be billed for 185 MB. 1 GB is just the max your app can use at any given time.

Hello,
Thank you for your previous response.
However, I've reviewed my detailed invoice and found a discrepancy.
Your statement: "If your app used 185 MB, you will be billed for 185 MB."
My actual invoice: - Memory charged: 43,417,735 MB/min - Average memory billed: 1,005 MB (43,417,735 ÷ 43,200 min) - Cost: $10.05
My app's actual usage (from logs): - RSS: 185 MB - Heap: 72 MB
Code used :
// Memory logger intégré

setInterval(() => {

  const usage = process.memoryUsage()

  console.log(' REAL Memory Usage:', {

    'RSS (Total)': ${(usage.rss / 1024 / 1024).toFixed(2)} MB,

    'Heap Used (Node.js)': ${(usage.heapUsed / 1024 / 1024).toFixed(2)} MB,

    'Heap Total (Allocated)': ${(usage.heapTotal / 1024 / 1024).toFixed(2)} MB,

    'External (C++)': ${(usage.external / 1024 / 1024).toFixed(2)} MB,

  })

}, 30000)

The problem: it seems you're billing for 1 GB of container allocation, not my app's 185 MB actual usage.
This is 5.4x more than I could be expected to be charged related to your answer.
Conclusions :
1. Why are we charged for container overhead that we don't control (820 MB in my case)?
2. How can I reduce the container allocation to match my 185 MB usage?
I would expect to get billed for actual RSS instead of container allocation, the reason i initially choosed Railway?
The difference is significant: 185 MB should cost ~$2/month, but 1 GB costs $10/month.
A clarification of the billing model would be greatly appreciated

from what i understand from the offer : "Your Hobby plan subscription includes $5 of usage per month. If your total usage at the end of your billing period is $5 or less, you will not be charged for usage." => means for usage inferior to 5$ there is a fixed cost of 5$.

I should rephrase. If your service used 185 MB, then you will be billed for 185 MB. My statement above was an example to explain the billing model (allocation vs usage).

Also, process.memoryUsage only reports the memory usage for the node process itself. It does not account for other services or other container processes.

You can also try enabling serverless to reduce memory usage when your application has no visitors.

I'd suggest you to limit your resources, instead of setting 1gb as limit put 256mb, and in case add new replica if necessary....if you give memory to node it will use it even if not necessary....

I think the minimum is 512 MB (0.5 GB)... But yes, try decreasing max memory per instance.

Thanks for feeback

2 months ago i did put in variable :
NODE_OPTIONS : --max-old-space-size=256
This succeeds briefly before seeing weeks after the blog go back to 1gb memory used ( without any changes through deployment)
I tried to redeploy to see if it can re-init but deployment was failing until i removed the NODE_OPTIONS variable.

Now i have tried again following your answers :
Railway → Settings → Resources → Memory Limi
NODE_OPTIONS : --max-old-space-size=256
=> the memory went back to 200 mb after several deployment.
I will wait a couple of days to see.

My logs confirm this :

Conteneur: 202.82 MB

Node.js: 187.96 MB

Différence: 14.86 MB

Using code :
setInterval(() => {

  try {

    const cgroupMem = execSync(

      'cat /sys/fs/cgroup/memory/memory.usage_in_bytes 2>/dev/null || cat /sys/fs/cgroup/memory.current 2>/dev/null || echo "0"',

    )

      .toString()

      .trim()

    const containerMB = parseInt(cgroupMem) / 1024 / 1024

    const nodeMB = process.memoryUsage().rss / 1024 / 1024

    console.log Conteneur: ${containerMB.toFixed(2)} MB)

    console.log Node.js: ${nodeMB.toFixed(2)} MB)

    console.log Différence: ${(containerMB - nodeMB).toFixed(2)} MB)

  } catch (error) {

    console.error('Erreur:', error.message)

  }

}, 30000)

P.S : your clarifications on these 2 statements would be greatly appreciated
- To limit the amount you're paying, you can set hard limits in your workspace settings > usage, but note that this will shut down all deployments once that hard limit is hit ??
- add new replica if necessary ??

To limit the amount you're paying, you can set hard limits in your workspace settings > usage, but note that this will shut down all deployments once that hard limit is hit

You can set the hard limits by accessing your Workspace settings, then clicking the following (as labeled in the image below).

By doing this, you're setting the max amount of money you can spend a month in Railway. However, if you do meet that limit, all of your services will be shut down. You will not be able to access any of your deployments.

Your services will not be removed, but your deployments will be removed.

add new replica if necessary

If your memory usage is still high, I would not do this, as this will double your resource usage costs.

This essentially adds another instance running your application.

Ok thanks for explanation.
For a payload blog reduced to 10 pages with database connected to supabase, all above didnt solve my memory which grows from 200mb to a stable 1 gb within 2 days

In case this is due to Payload, i will give it a last try running regularly garbage collection and auto-restart every day in case this comes from Payload blog keeping session, Next keeping cache or PostgreSQL connection being open.

Otherwise it will mean that Railway seems not adapted to be used for Payload blog as causing increasing costs.

Also for reference using Railway variable environment

NODE_OPTIONS : --max-old-space-size=256 causes then deployment afterward to fail with FatalProcessOutOfMemory
Seems the build lacks memory so instead i have put it in start in package.json:
start": "cross-env NODE_OPTIONS='--max-old-space-size=300 --expose-gc --no-deprecation' node server.js".