Shared infrastructure and isolation
The most important consequence of Aleph's design is economic: bounded apps can safely share machines, and sharing is much cheaper than giving every app its own.
The problem with one stack per app
A typical small backend runs on dedicated pieces:
- an isolated runtime: a Lambda function, a Docker container, or a VPS
- a database
- a cache
- a queue
- an auth service
Each is sized for the worst day, and each is mostly idle. Before an app has any users, that stack often costs around $100 a month. Serverless removes the idle server, but not the database and the rest, and it introduces cold starts and per-invocation surprises.
The reason apps can't simply share one big server and database is trust. If one app's request can loop forever, allocate gigabytes, or scan a whole table, it can starve every app next to it. So providers isolate apps with dedicated resources, and you pay for the isolation.
Why Aleph apps can share
An Aleph app is a manifest of bounded operations, run by a trusted core. That changes what a runtime can promise:
| Risk in a shared runtime | Why it can't happen with Aleph |
|---|---|
| A request runs away with the CPU | Every loop has a known maximum, and every request's operations are bounded statically and metered at run time |
| A request floods the shared database | Reads, writes, and bytes per request are bounded; queries are always by key or range with a limit |
| Memory spikes take down the process | The bytes a request can hold are bounded too |
| Handlers set each other off without end | Trigger cycles are rejected before deploy, and chains stop at 16 hops |
| One tenant reads another's data | Keys are built inside the tenant's keyspace; a plan can't name anyone else's |
| Author code escapes its sandbox | There's no author code: the runtime interprets data |
So many apps, from many unrelated authors, can run in the same processes against the same database. A runtime can also use each request's known worst case to admit work fairly. See Tenants and isolation.
What that means for cost
- No idle stack per app. Capacity is pooled across apps, so an app with ten requests a day costs roughly ten requests' worth, not a server's worth.
- Predictable bills. Every request has a worst case, so the most a route can use, and so be billed for, is known before anyone calls it.
- Cheaper to run. Requests are microseconds of CPU in a native Rust interpreter, with no per-app process to boot.
Tenants and isolation
Aleph is designed so many apps, and many tenants of each app, can share one runtime safely.
Keys can't escape their tenant
Every storage key a plan touches is built by the core inside the executing tenant's keyspace: a prefix the plan can't see or change. A plan names entities and key values, never raw keys. There's no expression that produces another tenant's prefix, so cross-tenant access isn't something a check prevents. It can't be expressed at all.
Property tests check this for keys, pagination cursors (which can't be forged to escape the range they came from), and generated plans.
Resources can't be monopolized
- Per request: every request's usage is bounded before it runs and metered while it runs. One app's expensive route can't run long enough to hurt others.
- Over time: a runtime can use the static bounds for admission control and fair scheduling, such as reserving a request's worst case and charging what it actually used.
Code doesn't run
A manifest contains no author code, so there's no sandbox to escape. The runtime interprets data with a small, trusted Rust core, property-tested and fuzzed against randomly generated and mutated manifests. Integrations are the only way out, and they're declared, typed, and executed by the runtime.
Auth is the runtime's job
Authentication (who the caller is) happens before the core. The core enforces each route's declared authorization: public, signed-in, org member with roles, or API key with scopes. In development, aleph dev takes the caller from headers.