The compute model
Cold starts, warm reuse, concurrency and scale to zero for Gigadrive Network Functions, and what each of those costs you.
Your code on Gigadrive Network runs as Functions. 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 goes to sleep shortly after the traffic stops. A sleeping Function costs you nothing.
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 awake but stops consuming CPU: shortly after the last request finishes, its CPU is paused. The next request resumes it before anything is forwarded, so you are not billed CPU time for the gap and your users do not notice it. The copy keeps its memory while it is awake, and that memory is billed until the Function goes to sleep. Anything still streaming counts as in flight, so its CPU is never paused: a server-sent-events response is in flight for its entire lifetime, and so is 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.
| Plan | Concurrent requests per Function |
|---|---|
| Starter | 100 |
| Pro | 500 |
| Enterprise | Unlimited |
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 30 seconds without a request goes to sleep, and its memory is released. The check runs once a minute, so in practice a Function falls asleep within about a minute of its last request.
The next request wakes it with no action from you: nothing to restart, and no URL that stops working in the meantime.
On Pro, each application can wait longer before its Functions go to sleep: 30 seconds, 1 minute, 5 minutes, 10 minutes or 30 minutes. A longer delay means fewer requests wait for a wake-up, and more hours of memory on your bill. Starter is fixed at 30 seconds.
Going to sleep never interrupts work in flight, so a Function holding an open WebSocket or a response it is still streaming stays awake.
If you would rather your production traffic never waited for a wake-up, Pro and Enterprise plans can mark an application always-warm. Its production deployment's Functions never go to sleep, and you pay for their memory the whole time. Staying awake is best effort rather than a guarantee, so a Function can still go to sleep 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.
| Meter | Measures |
|---|---|
| Invocations | Requests that actually reached your code |
| Active CPU | CPU time consumed while your code is running |
| Provisioned memory | Memory held while a Function is awake, integrated over time |
Active CPU is not awake time. An hour of active CPU means an hour of your code doing work, so a copy that waits between two requests contributes nothing to it. Provisioned memory works the other way: it accrues for as long as a copy is awake, including the time between requests, and stops when the Function goes to sleep. A sleeping Function reports zero for both.
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.
