On Hobby, the 5 GB is per volume, not a total for the whole account. Each service can have one volume, so if PostgreSQL and your Go API each have their own volume, each can hold up to 5 GB, which is 10 GB across the two. Hobby allows up to 10 volumes per project. See Volumes and plan resources.

Staging and Production don't share one allocation. A service's volume in your Staging environment is a separate volume from its Production volume, with its own 5 GB limit, and volumes for the same service in another environment don't count toward the per-project volume limit. Volumes are billed for the storage you actually use, per GB per minute.

mt team asked following question on railway plan. can u help me on each question

team asked me:

Need to check the following options: Option 1: Deploy Staging on Railway Free plan and Production on Railway Hobby plan. Option 2: Deploy both Staging and Production using the Railway Hobby plan. Questions to clarify: What would be the total Railway cost if we deploy both Staging and Production? What are the pros and cons of each option? What is the database storage limit for both the Free and Hobby plans? What is the expected uptime/availability for each plan? If we deploy the backend on Railway and the frontend on Cloudflare, what would be the total expected cost?

to answer these question if u need any clarification of my project u can ask

Database storage depends on plan: on Free, each volume (for example your PostgreSQL volume) is capped at 0.5 GB. On Hobby, the cap is 5 GB per volume. Each environment gets its own volume. See volume size limits and plan resources.

On cost, Free is $0/month and includes $1 of free resources per month. Hobby is $5/month, and that fee counts toward your usage. If staging plus production use $5 or less in total, you pay $5. Above $5, you pay the difference. Usage is billed per minute: RAM at $10/GB/month, CPU at $20/vCPU/month, egress at $0.05/GB and volume storage at $0.15/GB/month. We can't give one fixed total because it depends on how much CPU, memory and storage your Go API, PostgreSQL and Redis actually use. See pricing.

The two options differ mainly in resource caps. Free services are limited to 0.5 GB RAM, 1 vCPU and 1 replica. Hobby services can use up to 48 GB RAM, 48 vCPU and 6 replicas.

Uptime SLAs are part of Enterprise plans only. Free and Hobby don't include an uptime guarantee.

If your frontend runs on Cloudflare, it isn't billed by us. Your Railway bill covers only the backend services under the model above.

RAM at $10/GB/month, CPU at $20/vCPU/month, egress at $0.05/GB and volume storage at $0.15/GB/month.

y u mentuoned $10, $20 , $0.05 . we already paid $5 for hobby.u can mentin allowed memory for each. but y u mention $?

The rates matter because the $5 Hobby fee isn't a flat price for unlimited resources. It includes $5 of resource usage per month, and the rates are how that usage is measured. Your services are billed for the RAM, CPU, egress and volume storage they actually use, per minute.

If your staging and production services together use $5 or less in a month, you pay just the $5. If they use $7, your bill is $7, which is the $5 fee plus $2 of extra usage. The included $5 resets every billing cycle and doesn't carry over.

The memory amounts are separate. They're the maximum each service is allowed to use, not what you pay for. On Hobby, each service can use up to 48 GB RAM, 48 vCPU and 5 GB of volume storage. You're only billed for what a service actually uses, not for that maximum. See plans and included usage.

On Hobby, each service can use up to 48 GB RAM, 48 vCPU and 5 GB of volume storage==> but f we have 3 services then it gives 3x5gb= 15gb of valumen storage right?

Yes, if each of your 3 services has its own volume, each one can hold up to 5 GB, so that's 15 GB across the three. Each service can have only one volume, and Hobby allows up to 10 volumes per project. Your Staging copies of those services get their own separate volumes with the same 5 GB each.

In practice your Go API usually doesn't need a volume at all. Only services that store data on disk, like PostgreSQL and possibly Redis, need one. You're billed only for the storage a volume actually uses, not the 5 GB maximum. See volume limits.

Each service can have only one volume, and Hobby allows up to 10 volumes per project

what is volume here? in my project what it has?

A volume is persistent disk storage attached to a service at a mount path, so files written there survive restarts and redeploys. Without a volume, anything a service writes to disk is lost when it redeploys. See Volumes.

We don't see any services deployed on your account yet, so your project has no volumes right now. In the setup you described, PostgreSQL would store its data on a volume, usually mounted at /var/lib/postgresql/data. Redis would use one mounted at /data if you want its data kept across restarts. Your Go API doesn't need one unless it saves files to disk. That would be 1 or 2 volumes per environment, well under the 10 Hobby allows per project.

i am already in hobby plan $5 / month but used only 2gb then what is billing? usully we pay $5 start of month and use the resource right?

The account you're writing from currently shows a Trial workspace with $5.00 of trial credit, not an active Hobby subscription.

On Hobby, yes, the $5 subscription is charged in advance for the month, and it includes $5 of resource usage. If your usage for the cycle is $5 or less, your bill is just the $5. If usage goes over $5, you pay the difference on top, billed after the cycle ends. Storing 2 GB on a volume costs about $0.30 a month at $0.15/GB, so on its own it fits well inside the included $5. The included usage resets each cycle and doesn't roll over.

See Understanding your bill for examples.

yes, the $5 subscription is charged in advance for the month, and it includes $5 of resource usage. If your usage for the cycle is $5 or less, your bill is just the $5. If usage goes over $5, you pay the difference on top, billed after the cycle ends.==> here u saID subscription is charged in advance for the month. after u said thus as well If usage goes over $5, you pay the difference on top, billed after the cycle ends

Both statements apply, because one invoice covers two different periods. The $5 subscription fee is charged at the start of each cycle for the month ahead, and it includes $5 of usage. Usage is measured as it happens, so any amount above that $5 can only be known once the cycle ends. It is added to the next invoice, together with the $5 fee for the new cycle.

For example, if you use $3 in a month, you pay only the $5 paid upfront. If you use $8, the next invoice has the $3 overage from the month that just ended plus the $5 fee for the new month. See Understanding your bill.

is al onfo below are correct?

dont blindly say yes

comparewith railway doc and let me know

Choosing Between Free and Hobby Plan

1. How Railway Architecture Works (Overview)

Before diving into the pricing options, it is important to understand how Railway hosts our codebase. Railway does not just give us a single server to put all our code and databases onto.

When we deploy a repository to Railway, it automatically builds and provisions isolated containers for every service we need. If we deploy both our Staging and Production environments to Railway, it creates completely separate, independent infrastructures for both.

For our project, Railway will spin up 6 completely separate containers:

• Production Environment: 1 isolated container for Go API, 1 for PostgreSQL, 1 for Redis.
• Staging Environment: 1 isolated container for Go API, 1 for PostgreSQL, 1 for Redis.

Why this isolation is crucial:

• Security & Stability: A crash or traffic spike in Staging will never affect Production. Staging data and Production data are physically separated.
• Independent Scaling: If the Go API needs more RAM, we do not have to upgrade the PostgreSQL database. Each container scales independently.
• Metered Billing: We are billed by the minute for exactly what each specific container consumes, rather than paying a large flat fee for a single server.

2. Maximum Allowed Limits (Per Service)

Based on official Railway documentation, here are the maximum hardware limits they allow a single container to scale to before it is blocked:

| Plan | Price | Max RAM | Max CPU | Max Volume Storage | Max Replicas |

| :--- | :--- | :--- | :--- | :--- | :--- |

| Free | $0/mo ($1 credit) | 0.5 GB | 1 vCPU | 0.5 GB | 1 |

| Hobby | $5/mo ($5 credit) | 48 GB | 48 vCPU | 5 GB | 6 |

3. Answers to Deployment Questions

Q1. What would be the total Railway cost if we deploy both Staging and Production?

We estimate the total cloud bill for all 6 containers combined to be between $10 and $20 per month initially.

The Exact Math (How Railway's "Hybrid" Billing Works):

Railway charges $10/GB RAM, $20/vCPU, and $0.15/GB Disk per month. Because Go and Redis are incredibly memory-efficient, our resource consumption across the 6 isolated containers is very low.

1. Pre-paid Subscription: We pay a $5 base fee upfront at the start of the month, which includes $5 of free usage credit.
2. Post-paid Usage: At the end of the month, Railway subtracts our $5 free credit, and charges us only for the overage.

Here is the exact calculation for our 6 services:

Staging Environment (Mostly Idle State):

| Service | Estimated Usage | Monthly Cost |

| :--- | :--- | :--- |

| Go API | 100 MB RAM + 0.02 vCPU | ~$1.40 |

| PostgreSQL | 200 MB RAM + 0.02 vCPU + 1GB Disk | ~$2.55 |

| Redis | 50 MB RAM + 0.01 vCPU | ~$0.70 |

| Staging Subtotal | | ~$4.65 / month |

Production Environment (Moderate Traffic State):

| Service | Estimated Usage | Monthly Cost |

| :--- | :--- | :--- |

| Go API | 250 MB RAM + 0.1 vCPU | ~$4.50 |

| PostgreSQL | 512 MB RAM + 0.1 vCPU + 2GB Disk | ~$7.42 |

| Redis | 100 MB RAM + 0.05 vCPU | ~$2.00 |

| Production Subtotal| | ~$13.92 / month |

Final Monthly Invoice Calculation:

• Total Measured Usage: ~$18.57
• Minus Included Free Credit: -$5.00
• Total Amount Charged to Card: ~$18.57 / month (Base fee + overage)

Note: Staging costs will stay flat forever, while Production costs will scale up linearly as we get more drivers. We will use Railway's built-in Usage Dashboard 7 days after deployment to monitor live consumption and verify these estimates.

Q2. What are the pros and cons of each option?

Option 1: Staging on Free plan, Production on Hobby plan

• Pros: None.
• Cons (Blocker): The Free plan strictly limits usage to $1 of credit per month. As shown in the math above, our 3 staging containers cost roughly $4.65/month even while mostly idle. Staging would burn through its $1 credit and shut down completely after ~6 days every single month.
• Verdict: ❌ Not technically viable.

Option 2: Deploy both Staging and Production on the Hobby plan

• Pros: Staging gets 100% uptime. Both environments live in the same account (allowing safe, 1-click promotions from Staging to Prod). Furthermore, every individual container is allowed up to a massive 48 GB of RAM and 8 vCPUs. This guarantees our production API will never crash due to sudden traffic spikes; it will simply auto-scale and charge us for the exact seconds of extra RAM used.
• Cons: We have to pay for the exact resources Staging consumes (adding roughly ~$5/month to our bill to keep it alive 24/7).
• Verdict: ✅ Recommended.

Most of it matches our docs. A few points need fixing.

Limits: the 48 GB RAM / 48 vCPU Hobby figures are per service and include replicas. A single container (replica) tops out at 8 GB RAM and 8 vCPU on Hobby, so "48 GB and 8 vCPUs per container" mixes the two figures. The volume and replica numbers are correct.

Billing: the rates and the per-minute model are right, but the invoice section contradicts itself. The included $5 is part of the $5 fee, not a credit subtracted on top. If usage totals $18.57, the bill is $18.57 ($5 fee plus $13.57 overage). Your service figures are only estimates, since real usage decides the total. Checking the Usage dashboard after you deploy is the right plan. See plans.

Availability: "100% uptime" and "will never crash" aren't correct. Free and Hobby have no uptime guarantee, because SLAs are Enterprise only. Hobby also doesn't add capacity when traffic spikes. A container can use resources up to its plan cap, and only what it uses is billed.

Option 1: Free and Hobby are separate plans, so staging on Free would have to sit in a different workspace from production. It couldn't be an environment in the same project. The ~6 days is an estimate based on your own figures.

Isolation: services and environments do run in their own containers, with their own volumes. "Physically separated" goes beyond what our docs state.

what changes u made from my doc?

We didn't edit your document. Our last reply only pointed out what to correct. Here are those changes, section by section.

Section 2 (limits table): the 48 GB RAM / 48 vCPU Hobby figures are per service and include replicas, not per container. A single replica tops out at 8 GB RAM and 8 vCPU on Hobby. In Option 2's pros, "48 GB of RAM and 8 vCPUs per container" should read 8 GB RAM and 8 vCPU per replica.

Q1 (invoice math): remove the "Minus Included Free Credit: -$5.00" line. The included $5 is part of the $5 fee, not a separate credit taken off the total. With $18.57 of usage, the bill is $18.57 ($5 fee plus $13.57 overage), so your final figure is right but the subtraction line isn't.

Option 2 pros: remove "100% uptime" and "will never crash." Free and Hobby have no uptime guarantee, since SLAs are part of Enterprise only. Also replace "it will simply auto-scale" with: a service can use resources up to its plan cap, and you're billed only for what it uses.

Option 1: add that Free and Hobby are separate plans, so staging on Free would have to be in a different workspace, not an environment in the same project as production.

Section 1 (isolation): change "physically separated" to "run in separate containers with their own volumes."

Everything else (rates, per-minute billing, volume and replica limits, the Free $1 monthly credit) matches our plans docs.

Section 2 (limits table): the 48 GB RAM / 48 vCPU Hobby figures are per service and include replicas, not per container. A single replica tops out at 8 GB RAM and 8 vCPU on Hobby. In Option 2's pros, "48 GB of RAM and 8 vCPUs per container" should read 8 GB RAM and 8 vCPU per replica.

what is the issue here.

what i have currently

what needs to changed?

The problem is that the 48 GB RAM / 48 vCPU figures are not what one container gets. They are the most a single service can use when you add up all its replicas. On Hobby, one replica (one running container) can use at most 8 GB RAM and 8 vCPU. A service can run up to 6 replicas, and 6 x 8 = 48, which is where the 48 comes from.

Right now your Section 2 heading says these are limits for "a single container", and the Hobby row shows 48 GB / 48 vCPU. Option 2's pros say "every individual container is allowed up to a massive 48 GB of RAM and 8 vCPUs", which mixes the two figures.

To fix it, change the Section 2 heading to "per service (all replicas combined)" and keep 48 GB / 48 vCPU / 6 replicas in the Hobby row, since those numbers are correct for a whole service. You could add a note that each replica is capped at 8 GB RAM and 8 vCPU. In Option 2, change the sentence to "each container (replica) can use up to 8 GB RAM and 8 vCPU, and a service can run up to 6 replicas (48 GB / 48 vCPU in total)." See plan resources and per-replica limits.

Q1 (invoice math): remove the "Minus Included Free Credit: -$5.00" line. The included $5 is part of the $5 fee, not a separate credit taken off the total. With $18.57 of usage, the bill is $18.57 ($5 fee plus $13.57 overage), so your final figure is right but the subtraction line isn't.

Option 2 pros: remove "100% uptime" and "will never crash." Free and Hobby have no uptime guarantee, since SLAs are part of Enterprise only. Also replace "it will simply auto-scale" with: a service can use resources up to its plan cap, and you're billed only for what it uses.

Option 1: add that Free and Hobby are separate plans, so staging on Free would have to be in a different workspace, not an environment in the same project as production.

Section 1 (isolation): change "physically separated" to "run in separate containers with their own volumes."

same way explain on all these whe we need chnages

Q1 (invoice math): your doc currently says "Minus Included Free Credit: -$5.00" and then "Total Amount Charged: ~$18.57". The issue is that those two lines contradict each other, because subtracting $5 from $18.57 would give $13.57. The $5 is not an extra credit on top of the fee. It is what the $5 fee already buys. Change it to: "Total usage ~$18.57. Bill = $5 fee + $13.57 overage = ~$18.57." Also change "$5 free usage credit" to "$5 of included usage".

Option 2 pros: your doc currently says "Staging gets 100% uptime" and "will never crash... it will simply auto-scale". The issue is that Free and Hobby have no uptime guarantee (SLAs are Enterprise only), and Hobby does not add capacity automatically during spikes. Change it to: "No uptime SLA on Hobby. Each service can use resources up to its plan cap, and we're billed only for what it actually uses."

Option 1: your doc currently doesn't mention where staging would live. The issue is that a plan applies to a whole workspace, so Free staging cannot be an environment in the same project as Hobby production. Add: "Staging on Free would need a separate workspace and project, so 1-click promotion between environments would not be available."

Section 1 (isolation): your doc currently says "Staging data and Production data are physically separated." The issue is that our docs don't make a physical-hardware claim. Change it to: "Staging and Production run in separate containers with their own volumes."

See plans.