3 hours ago
Problem and desired outcome
We're starting a private beta of our video app and inviting 26 testers in weekly batches over the next few weeks. Each
tester can store up to 75 GB of video on our production volume, which is 250 GB today with about 80 GB used. We'd like to
grow it to 1 TB now, before the uploads arrive, but we understand a volume can't be grown until actual usage is higher.
We're asking Railway to either grow it ahead of use, or tell us exactly when a resize becomes possible and how quickly it
happens, so testers don't hit a full disk mid-upload.
Resources
The affected service is selected in this form: our main app service in the prod environment, on the Pro plan. The volume is
the one mounted at /app/data. Happy to share IDs privately if needed.
Evidence
Usage read with the Railway CLI on 2026-11-02 at about 12:00 EST: 79.7 GB used of 250 GB. It was the same on 2026-10-14, so
the volume is not growing yet. It will once testers start uploading.
Why the headroom matters to us:
- Uploads come in bursts. One tester filling their allowance adds 75 GB, possibly within a day. If a resize can only
follow usage, it may lag behind an upload burst.
- Our release backup needs the volume under half full. Every production deploy first takes a manual volume backup
through the API, and manual backups are limited to 50% of the volume's size
(https://docs.railway.com/volumes/backups#volume-backup-limits). At 250 GB, our deploys would start failing at about 125 GB
used, roughly 45 GB from where we are now.
Our understanding is that volumes bill on space used rather than on size. Our October invoice is consistent with that. So a
larger volume shouldn't cost more until it fills.
Why contact support
Our cofounder asked to contact Railway directly. A teammate reported on 2026-10-27 that the volume can't be grown until
actual disk usage is higher. That is a teammate's report: we don't have the exact message or screen they saw. We haven't
tried a resize since, and we haven't confirmed whether this is a fixed platform rule, a plan limit, or something support
can do for us.
What we're asking Railway to do or tell us:
- Can you grow this volume to 1 TB now, ahead of use?
- If not, at what usage does a resize to 1 TB (or to the next size) become possible, and how long does it take once
requested?
- Is there a way to keep a volume under 50% full for manual backups as it grows, other than resizing it ourselves?
Constraints
This volume holds production data, including our users' uploaded media. Please don't move, recreate or detach it. A live
resize with no downtime and no data loss is what we're after. This request does not authorize any other change to the
project.
Longer term we plan to move media to object storage, which removes this limit. That isn't ready for the beta.
Prepared with Railway's support template (v1).
6 Replies
3 hours ago
Your volume mounted at /app/data in prod is currently 250 GB with about 79.7 GB used, and your workspace's volume size ceiling is 1 TB, so growing it to 1 TB now is within what your plan allows. Pro workspaces can self-serve a volume up to 1 TB from the volume's settings using Live Resize, and the resize runs live with no downtime: storage is expanded while the service keeps running and the filesystem extends automatically. The exception is a volume that has reached 100% capacity, which gets an offline resize with a brief restart, so resizing ahead of the uploads avoids that path. See Live Resizing the volume.
Nothing in the documented resize requirements ties a resize to how full the volume is, and we can't tell what your teammate saw on 2026-10-27, so trying the Live Resize to 1 TB from the volume settings is the next step.
That is correct on billing: volumes are charged only for storage actually used, not provisioned size (pricing). For manual backups, the cap is 50% of the volume's total size, so at 1 TB your pre-deploy backups keep working until roughly 500 GB used.
Status changed to Awaiting User Response Railway • about 3 hours ago
Status changed to Awaiting Railway Response Railway • about 2 hours ago
2 hours ago
Our earlier reply was wrong to say that growing the volume doesn't depend on how full it is. Your teammate was right: a volume can only grow past 250 GB once its measured usage reaches a minimum. Your /app/data volume is 250 GB with about 79.7 GB used, so it can't be grown to 1 TB yet, and we can't grow it early or waive that minimum for you.
The minimums depend on the target size. 500 GB needs 185 GB used, 750 GB needs 375 GB used, and 1 TB needs 560 GB used. Jumping straight to a bigger size doesn't lower the requirement, so going from 250 GB to 1 TB means growing in steps (250 to 500 to 750 to 1 TB) as usage rises. You do each resize yourself from the volume's settings once usage reaches the minimum. Live Resize grows the volume while the service keeps running and doesn't touch your data. Resizes don't happen automatically, and we can't give you a guaranteed completion time.
These rules don't fit your backup requirement at this size. At 250 GB, the 50% cap on manual backups is 125 GB, which comes before the 185 GB you need to resize to 500 GB. So pre-deploy backups would hit their limit before a resize becomes possible.
On billing, that part of our earlier reply was correct: volumes are charged for storage actually used, not for provisioned size.
Status changed to Awaiting User Response Railway • about 2 hours ago
Status changed to Solved Anonymous • about 2 hours ago
Railway
Our earlier reply was wrong to say that growing the volume doesn't depend on how full it is. Your teammate was right: a volume can only grow past 250 GB once its measured usage reaches a minimum. Your /app/data volume is 250 GB with about 79.7 GB used, so it can't be grown to 1 TB yet, and we can't grow it early or waive that minimum for you. The minimums depend on the target size. 500 GB needs 185 GB used, 750 GB needs 375 GB used, and 1 TB needs 560 GB used. Jumping straight to a bigger size doesn't lower the requirement, so going from 250 GB to 1 TB means growing in steps (250 to 500 to 750 to 1 TB) as usage rises. You do each resize yourself from the volume's settings once usage reaches the minimum. Live Resize grows the volume while the service keeps running and doesn't touch your data. Resizes don't happen automatically, and we can't give you a guaranteed completion time. These rules don't fit your backup requirement at this size. At 250 GB, the 50% cap on manual backups is 125 GB, which comes before the 185 GB you need to resize to 500 GB. So pre-deploy backups would hit their limit before a resize becomes possible. On billing, that part of our earlier reply was correct: volumes are charged for storage actually used, not for provisioned size.
2 hours ago
our beta could be in jeopardy due to this limitation set by you, we are asking for some support here, anything that will help us would be appreciated. is there a directo line of inquiry or support i can reach out to discuss this?
Status changed to Awaiting Railway Response Railway • about 2 hours ago
2 hours ago
I think I need to mention something the bot may not have made clear. These are live resizes, meaning any resizes don't take down a service, even for a second.
Status changed to Awaiting User Response Railway • about 2 hours ago
brody
I think I need to mention something the bot may not have made clear. These are live resizes, meaning any resizes don't take down a service, even for a second.
2 hours ago
so as long as we keep an eye on how much volume is expanding and make sure to request an expansion in an approrpriate time window, we should be fine?
Status changed to Awaiting Railway Response Railway • about 2 hours ago
2 hours ago
Yes, absolutely, there is zero interference with any reads or writes during a live resize.
Status changed to Awaiting User Response Railway • about 2 hours ago