Always running. Never shared.
Each app you deploy runs in its own container — its own filesystem, its own process tree, its own RAM allocation. Your Next.js app is a long-running Node process, exactly as it would be on your own server. That has practical consequences:
- No cold starts. Requests hit a warm process. There is no per-request function boot, ever.
- No noisy-neighbour memory pressure. RAM limits are hard and per-container — another tenant's leak is their problem, not yours.
- In-memory state works. Caches, websockets and background workers behave like they do on a normal server — because it is one.
One honest trade-off: your container runs in one UK region, not on a global serverless edge. For UK audiences that is exactly where you want it; if your traffic is worldwide and edge latency is your top constraint, a serverless platform may genuinely fit better. See our Vercel comparison for the full picture.
Idle containers yield their CPU share; a busy one bursts up to the full pool.
CPU bursting, explained honestly
Most hosts sell you "vCPUs" without telling you how contended they are. We do it differently — and we'll tell you exactly how.
Your plan is a pool
Each plan carries a total CPU allowance — 1 GHz on Starter up to 8 GHz on Agency — shared across all the sites in your subscription.
Fair share by default
Every container gets an equal slice of the pool, enforced by the Linux scheduler. Nothing you run can be starved by a sibling site.
Burst when it matters
Idle containers yield their slice, so a site under load can burst up to your full pool. A traffic spike gets all your CPU — and your bill stays the same.
| Plan | Hosted sites | CPU | RAM | Storage | Price |
|---|---|---|---|---|---|
| Starter | 1 site | 1 GHz CPU | 512 MB RAM | 10 GB | £9/mo |
| Business | 3 sites | 2 GHz CPU pool | 1 GB RAM per site | 20 GB | £19/mo |
| Pro | 10 sites | 4 GHz CPU pool | 2 GB RAM per site | 50 GB | £39/mo |
| Agency | 25 sites | 8 GHz CPU pool | 4 GB RAM per site | 200 GB | £99/mo |
These are the limits our orchestrator actually enforces — the same numbers as the pricing page.
Postgres and Redis, next door
A fast app with a distant database is a slow app. Managed PostgreSQL 15 and Redis 7 instances are provisioned as sidecar containers on the same infrastructure as your app, and your app talks to them over the internal network — not the public internet.
- PostgreSQL 15 — a real Postgres instance for your app, with connection details injected as environment variables.
- Redis 7 — sessions, queues and caching without a third-party Redis provider or per-command pricing.
- MariaDB per site — every site gets its own MariaDB database as standard. One database per site, never shared tables.
- WireGuard private networking (Pro and above) — connect services privately, including from your own machine. Details on the security page.
Per-container CPU and RAM metrics with 90-day retention, per-minute uptime checks with email, Slack and webhook alerts, and an in-browser terminal into your running container. If we're wrong about your app's performance, you'll have the graphs to prove it.
Performance FAQ
How is CPU allocated to my apps?
Your plan gives you a total CPU pool (for example 4 GHz on Pro) shared across your sites. Each container is allocated an equal share, and because idle containers yield their share, a busy app can burst up to the full pool. It is a fair-share model, not a fixed vCPU count — we would rather explain that than invent core counts.
Is RAM shared the same way?
No — RAM is a hard per-container limit (512 MB to 4 GB per site depending on plan). One app can never starve another of memory, and a memory leak in one container cannot take your other sites down.
Do my apps suffer cold starts?
No. Your container is a long-running process, not a function that spins up per request. The first request after a deploy hits a warm, already-running app. (Preview environments are the deliberate exception — they sleep when idle and wake on request.)
Where do the databases run?
Next to your app. Every site gets its own MariaDB database, and managed PostgreSQL 15 and Redis 7 instances are provisioned as sidecar containers on the same infrastructure, reachable over the internal network rather than the public internet.
Can I see what my app is actually using?
Yes. The dashboard shows per-container CPU and RAM metrics with 90-day retention, plus per-minute uptime monitoring with email, webhook and Slack alerts, so you know when to upgrade before your users do.
Get a container of your own
Warm processes, hard RAM limits, databases next door, and metrics to prove it — from £9/mo fixed. Also see deployments and Node.js hosting.