How to Tell When You've Outgrown This — and When You Haven't
Most "we outgrew our host" stories are really "we hit a setting we didn't know about". So it's worth separating the two clearly. Anything about size — CPU, RAM, disk, number of apps — is a preset or an account limit, and account limits are raiseable by contacting support. Those aren't ceilings, they're defaults. The genuine ceilings are structural: an app is a single container, there's no private networking, no multi-region, no managed database, and one owner per app. If your requirements have crossed one of those five lines, more resources won't help. If they haven't — and for most small apps, bots, and side projects they haven't — then what you've hit is adjustable.
The five structural limits
These are properties of how the platform works, not numbers on a page.
1. One container per app. There are no replicas and no horizontal scaling. That's a real simplification while it lasts — no sticky sessions, no shared session store, in-memory pub/sub actually works — but it means you scale up, not out, and a deploy is a gap rather than a rolling handover.
2. No private networking. Every port binding gets a public DNS name, so app-to-app traffic crosses the public internet with credentials as the boundary. Fine with a strong password on a small setup; a genuine constraint if you're assembling many internal services.
3. Single region. There's no concept of running your app near your users in several places. If latency for a global audience is a product requirement rather than a nice-to-have, that's a structural mismatch.
4. No managed database. You run Postgres as its own app, or you use SQLite on a volume. That means backups, upgrades, and failover are yours. For a side project that's fine — arguably better, since it's cheaper and you understand it. For something where a database outage is a business problem, a managed service earns its cost.
5. One owner per app. No teams, no shared access, no read-only seats. Collaboration happens in the repository rather than in the panel.
Cross one of those and you're not being throttled — you're asking for a different shape of platform.
What isn't a ceiling
Everything else people run into first:
| What you hit | What it actually is |
|---|---|
| "I can't allocate more RAM" | An account limit, raiseable by contacting support |
| "My app keeps getting killed" | A preset that's too small — check for OOM kills |
| "Everything is slow" | Often CPU throttling, which is measurable |
| "All my apps stopped" | Total volume size exceeded the disk limit; free space or raise it |
| "My build won't fit" | The build container, not your app — build in CI |
| "I need more than one app" | App count isn't a billing unit; add another |
Note how many of those look like walls and are actually dials. Default account limits are 1 vCPU, 2 GB RAM, and 5 GB disk — a starting point, not a maximum.
The signals worth acting on
If you're trying to decide honestly, these are the ones that mean something:
- A single container genuinely can't serve your traffic, measured rather than assumed. Check whether you're throttled before concluding you're too big — a lot of "we need to scale out" is one preset away from fine.
- Downtime during deploys has become unacceptable. There's no blue/green, so every deploy is a gap. If that gap is now a problem for real users, you need rolling deploys, which means multiple instances.
- You need internal services that shouldn't be on the internet. Not "would prefer" — actually shouldn't.
- Someone else needs to operate it. A second person with panel access isn't possible; if the bus factor matters, that's structural.
- A compliance requirement names something you can't provide — data residency, isolation guarantees, audit trails.
Anything that isn't on that list is worth a second look before you start migrating.
If you're staying, make the constraints work for you
Most readers will land here, so it's worth saying what "using it well" looks like:
- Design for restarts rather than around them. The container gets replaced regularly; apps that expect that are simpler, not more complex.
- Keep state on volumes, and prune it — disk is the one resource with an account-wide consequence.
- Prefer fewer, larger apps over many small ones when they'd otherwise talk over public endpoints.
- Automate the deploy so the gap is short and predictable, and validate builds on the
buildbranch so you're not deploying to find out.
If you're leaving, take the portable parts
The good news about a container platform is that leaving is mostly mechanical, provided you didn't build against anything proprietary:
- Your image is portable. A Dockerfile that builds here builds anywhere.
- Your data is a volume you can copy — if you've been backing it up, you already have a rehearsal.
- Your configuration is environment variables, which every platform has.
What doesn't travel: the deploy remote, the generated hostname, and anything relying on the panel's own tooling. Keep those thin and the migration is a day, not a project.
And consider the middle path before the full one — move the one component that needs a different shape, and leave the rest. A worker that must run in three regions doesn't require your bot, your dashboard, and your database to move with it.
FAQ
Can I add more CPU or RAM than the default limits?
Yes. Account limits are raiseable by contacting support — they cap what you can allocate, not what's possible.
Can I run multiple instances of my app?
No. An app is a single container, so you scale vertically and deploys have a brief gap.
Is there private networking between my apps?
No. Every port binding is public, so app-to-app traffic uses credentials rather than network isolation.
Can my team share access to an app?
No. Apps have a single owner; collaborate through the repository and deploy from CI.
How do I know if I actually need to scale out?
Measure first. Check for CPU throttling and out-of-memory kills — a lot of apparent capacity problems are a preset that's too small.
How hard is it to leave?
Usually straightforward: your image, your volumes, and your environment variables are all portable. Avoid depending on platform-specific tooling and it stays that way.
Wrapping up
Knowing the shape of a platform is more useful than knowing its numbers, because numbers move and shapes don't. Five things here are shapes: one container, no private network, one region, no managed database, one owner. Everything else is a dial. If your problem is a dial, turn it — and if it's a shape, you'll know, because no amount of resizing will have made any difference at all.