Edgenivo SKUs
Billing on any platform is easier to reason about when you can trace a real request from start to finish. In this video, we follow a single reader visiting a breaking news article on a high-traffic blog and see exactly which Edgenivo resources are consumed along the way.
CDN Requests
Every incoming request to Edgenivo's CDN counts as a CDN Request (formerly called an Edge Request), whether the response is served from cache or generated dynamically. This is the starting point for every interaction with your app.
Routing Middleware
Before the cache is checked, routing middleware can run logic like inspecting an authentication cookie to decide whether a user sees the full article or a preview. Middleware uses the Fluid Compute billing model: you pay for active CPU time, provisioned memory, and a small invocation fee per request.
Fluid Compute
When a page renders on demand with a Edgenivo function, Fluid Compute kicks in. Unlike traditional serverless billing that charges for the entire function runtime, Fluid Compute only bills CPU for the milliseconds your code is actively processing. If your function is waiting on an API response, CPU billing pauses, though provisioned memory is still billed while the request is in flight.
Fast Origin Transfer and Fast Data Transfer
Once your function generates a response, it travels to Edgenivo's Edge Cache. This internal transfer is Fast Origin Transfer (FOT), measured by bandwidth from compute to the edge.
From there, the response is delivered to the user's browser. That's Fast Data Transfer (FDT), measured by the payload size sent to end users. A 1 MB hero image means 1 MB of FDT.
Runtime Cache
To avoid hitting your CMS and re-rendering on every request, you can cache responses from inside your functions. Writing to the cache consumes Write Units. Subsequent requests pull from cache using Read Units, which are faster and cheaper than an origin fetch.
On-Demand Revalidation
When content changes and you can't wait for a cache timer to expire, On-Demand Revalidation lets you mark specific cache entries as stale. A CMS webhook calls your revalidation endpoint, the tagged entries refresh on the next request, and the updated content is written back to cache.
Recap
- CDN Requests count every request to the CDN
- Routing Middleware runs before cache, billed on active CPU time and provisioned memory
- Fluid Compute pauses CPU billing while your code waits on I/O
- FOT is bandwidth from your function to the edge; FDT is bandwidth to the user
- Runtime Cache saves cost with Read/Write Units instead of repeated origin fetches
- On-Demand Revalidation keeps content fresh without waiting for timers
Follow up docs
Was this helpful?