Scale
How Forge64 apps scale
Last reviewed
Each Forge64 app runs in one container with a plan-set memory limit, backed by its own Postgres database, and each plan has hard limits on always-on apps, bandwidth and storage. Forge64 has not yet measured how much traffic an app or the platform can serve, so it publishes no requests-per-second figure; throughput is being benchmarked. Production hosting is a single server today.
The design
Capacity comes from three things: the container for each app, a hard cap on each metered resource so one tenant cannot starve the others, and the ability to add servers. The first two are in the code. Adding servers is on the Roadmap.
- BuiltOne container per app with a plan-set memory limit and a plan-set number of always-on slots.
- Rolling outPer-tenant limits on connections, bandwidth and build counts, enforced in code so one tenant cannot starve others.
- Rolling outScale to zero for idle apps on Free and Pro, so idle apps do not hold memory.
- Rolling outStatic apps served from object storage and the edge instead of a container, which removes the container from the request path for static sites.
- RoadmapSeveral app instances behind a load balancer for a single app (horizontal scaling of one app).
- RoadmapA multi-node server pool with automatic node scaling and a capacity model.
Limits per plan
These limits are read from the same plan catalog that bills customers, so they cannot drift from the pricing page. Hard caps stop usage; they are not soft quotas.
| Plan | Always-on apps | Sleeping apps | Memory per app | Bandwidth per month | Database storage | Builds per day |
|---|---|---|---|---|---|---|
| Free | 0 | 1 | 256 MB | 5 GB | 256 MB | 3 |
| Pro | 2 included, hard cap 10 | 5 | 256 MB included, hard cap 1024 MB | 100 GB included, hard cap 1,000 GB | 5 GB included, hard cap 50 GB | 50 |
| Business | 8 included, hard cap 25 | 25 | 256 MB included, hard cap 2048 MB | 500 GB included, hard cap 5,000 GB | 10 GB included, hard cap 100 GB | 100 |
| Enterprise | 30 included, hard cap 100 | 100 | 256 MB included, hard cap 4096 MB | 2,000 GB included, hard cap 20,000 GB | 50 GB included, hard cap 500 GB | 500 |
Platform limits that apply today
- BuiltA Postgres cluster refuses to host more than 250 tenant databases. Beyond that, new clusters are required and cross-cluster sharding is not built, so platform-wide app count is bounded by this today.
- BuiltMany empty tenant databases consume disk on the data server; disk capacity is a real limit on the number of apps at the current server size.
- Rolling outPlatform usage (requests, key-value, queue and database operations) is bounded by daily ceilings that refuse traffic before a vendor bill grows.
What has been measured
Nothing that would support a capacity claim for customer apps. The only recorded load measurements are of Forge64's own web front end, taken on a developer laptop in September 2026; they say nothing about hosted customer apps or the production server and are not published as capacity figures. Cold-start time after sleep, throughput under the per-app network caps, and the number of apps a server can hold have not been measured on real infrastructure.
Capacity results will be published on this page, with the date, environment and method, only after they are measured on a staging environment that mirrors production.
- RoadmapRequests per second per app, p95 latency under load, and cold-start time. Being benchmarked; no figure is published.
Load-test methodology
Forge64 load tests use three scenarios (smoke, load and breakpoint). A scenario must declare its billable-request budget first; a calculator refuses to certify a run if the total exceeds the cost ceiling or if any price it relies on is unverified. Load tests never target a billable endpoint such as model generation, and never run against the production server while real users are active. A result is reported with the build tested, the environment, throughput, p50/p95/p99 latency, error rate, the point where throughput stops rising, and the cost of the run.
- BuiltLoad-test tooling with a billable-request budget gate.
- Rolling outLoad tests against a staging environment. The staging environment is defined but its cloud resources are not created yet.
Frequently asked questions
- Can Forge64 handle a large spike in traffic?
- Forge64 has not measured the traffic an app or the platform can serve, so it cannot state a number. Each app runs in a single container with a plan-set memory limit, production hosting is a single server, and horizontal scaling of one app is on the Roadmap. If you expect a large spike, ask first and use a static build where possible.
- How many apps can Forge64 host?
- Each Postgres cluster is capped at 250 tenant databases and sharding across clusters is not built, and production is a single server, so the platform is sized for early access, not for tens of thousands of apps. Scaling beyond that is on the Roadmap.
- What are the limits on each Forge64 plan?
- They are listed in the table on this page and come from the plan catalog: always-on apps, sleeping apps, memory per app, bandwidth, database storage and builds per day. Enterprise starts at From $899 per month, billed annually.
- Does Forge64 scale apps down when they are idle?
- Scale to zero is implemented: Free apps sleep after idle time and wake on the next visit. The master switch is off in production at the review date, and cold-start time has not been measured.
- Will a traffic spike run up my bill?
- No. Every metered resource has a hard cap, and paid plans have an owner-set overage spend cap; when a cap is reached the usage stops instead of billing without limit. The Free plan has no overage.