The compute model

Your code runs as Functions on Substrate, the compute model behind Gigadrive Network. There is no server you keep running: a copy of your Function starts when a request needs one, is reused by the requests that follow, and stops costing you anything when the traffic stops.

Starting cold

Publishing a deployment does not start anything. It records where the artifact lives and which paths route to which Function, and then it waits. The first request to reach a Function is what starts the first copy of it.

That request pays for the boot and the ones behind it do not. There are no warmers to configure and no ping endpoint to schedule.

Memory is the one setting that changes what a cold start has to move. A Function gets at least 256 MB regardless of what you asked for, rounded up to an even number of megabytes, so a config value of 128 runs with 256 MB. See Memory and CPU.

Warm reuse

max_duration bounds one invocation: a single HTTP request, one response stream, or one WebSocket connection. It does not bound the copy serving it. The default is 30 seconds and the ceiling is 8 hours. An invocation that runs past its limit before sending any headers gets a 504. One that runs past it after headers are already committed gets its response body cut off instead, because the status line has already gone out.

Between invocations a copy stays alive but stops consuming CPU: shortly after the last request finishes, it pauses. The next request resumes it before anything is forwarded, so the pause changes what you are billed and not what your users see. Anything still streaming holds the copy awake: a server-sent-events response counts as in flight for its entire lifetime, and so does an open WebSocket.

Reuse is also why global state in your handler is not a cache you can rely on. It survives between two requests that land on the same copy, and nothing else.

Concurrency

Every plan sets one number that matters: how many requests a single Function may process at the same time.

That limit is a sum across everything serving that Function, not a per-copy cap. Under it, requests are spread across the warm copies of your Function, and more copies are added as load rises.

At the limit, a request that cannot be admitted gets a 429 with Retry-After: 2. Raising the ceiling means changing plan, not tuning a setting; Concurrency explains how to read your current usage.

Scaling to zero

A Function that has gone five minutes without traffic is suspended and its memory released.

The next request wakes it with no action from you: nothing to restart, and no URL that stops working in the meantime.

Suspension never interrupts work in flight, so a Function holding an open WebSocket or a response it is still streaming stays up.

If you would rather your production traffic never waited for a resume, Pro and Enterprise plans can mark an application always-warm. That keeps the production deployment's Functions resident and exempt from pausing, and you pay for the resident memory the whole time. Residency is best effort rather than a guarantee, so a Function can still pause under load. Pro allows 5 such applications and Enterprise 25.

What you are billed for

Three meters run against a Function, and they measure different things on purpose.

Active CPU is not residency. An hour of active CPU means an hour of your code doing work, so a copy that sits paused between two requests contributes nothing to it. Provisioned memory follows the same rule: it accrues while a copy is running and stops when it pauses, and a suspended Function reports zero.

Requests the edge answers by itself never enter any of the three, which is the single largest lever you have over a compute bill. How a request is served lists what qualifies, Usage metrics defines each figure exactly, and Plans has the included allowances and rates.