Isolation
One request. One isolated runtime.
Each request receives its own instance, with no application memory carried from the request before it.
Fresh executionAfterburner runtime
A fresh runtime for every request.
Afterburner turns each request into isolated, metered WebAssembly execution—starting in under a millisecond and disappearing when the work is complete.
Infrastructure that exists for the work—not the waiting.
Afterburner replaces the long-lived server as the unit of operation. Capacity begins at execution, follows demand, and returns to zero when demand is gone.
Startup
The runtime arrives before infrastructure becomes a decision.
Sub-millisecond starts make instance creation part of request handling, not a capacity-planning event.
< 1 msCapacity
Concurrency becomes the platform’s problem.
New work receives new execution without a warm pool, scaling threshold, or idle fleet for your team to administer.
0 → demandThe request is the lifecycle.
Afterburner performs a short, complete sequence for every unit of work. Nothing has to remain running in anticipation of what might arrive next.
-
IngressRequest arrives
Routing identifies the workload and hands the request to the runtime.
-
InstantiateRuntime starts
A fresh WebAssembly component is instantiated for this request.
-
ExecuteWork runs
The component handles the request in its isolated execution context.
-
MeterUsage is measured
Consumption follows the actual execution rather than reserved idle capacity.
-
ReleaseInstance ends
The runtime is discarded when the response is complete.
No warm pool before demand. No idle instance after it.
Bring the workload. Afterburner handles the runtime.
Start in the Hyjal console, or walk through your request path with the team.