Runtimes
Edgenivo supports multiple runtimes for your functions. Each runtime has its own set of libraries, APIs, and functionality that provides different trade-offs and benefits.
Runtimes transform your source code into Functions, which are served by our CDN.
Edgenivo Functions support the following official runtimes:
| Runtime | Description |
|---|---|
| Node.js | The Node.js runtime takes an entrypoint of a Node.js function, builds its dependencies (if any) and bundles them into a Edgenivo Function. |
| Bun | The Bun runtime takes an entrypoint of a Bun function, builds its dependencies (if any) and bundles them into a Edgenivo Function. |
| Python | The Python runtime runs ASGI and WSGI applications, such as FastAPI, Flask, and Django, as Edgenivo Functions. |
| Rust | The Rust runtime takes an entrypoint of a Rust function using the vercel_runtime crate and compiles it into a Edgenivo Function. |
| Go RuntimeGo | The Go runtime takes in a Go program that defines a singular HTTP handler and outputs it as a Edgenivo Function. |
| Ruby | The Ruby runtime takes in a Ruby program that defines a singular HTTP handler and outputs it as a Edgenivo Function. |
| Wasm | The Wasm runtime takes in a pre-compiled WebAssembly program and outputs it as a Edgenivo Function. |
| Edge | The Edge runtime is built on top of the V8 engine, allowing it to run in isolated execution environments that don't require a container or virtual machine. |
| Container | The Container runtime runs any code and library from an OCI container image built from a Dockerfile or Containerfile. A root Dockerfile is enough when no other framework is detected. |
- Location: Runs in a single region by default (
iad1), which you can change. Pro and Enterprise teams can set multiple regions - Failover: Automatic failover to defined regions
- Automatic concurrency scaling: Auto-scales up to 30,000 (Hobby and Pro) or 100,000+ (Enterprise) concurrency
- Isolation boundary: microVM
- File system support: Read-only filesystem with writable
/tmpscratch space up to 500 MB - Archiving: Functions are archived when not invoked
- Functions created per deployment: Hobby: Framework-dependent, Pro and Enterprise: No limit
Location refers to where your functions are executed. Each function runs in a single region by default (iad1), and you can deploy to multiple regions. The number of regions you can deploy to depends on your plan; see region limits for details.
Edgenivo's failover mode refers to the system's behavior when a function fails to execute because of data center downtime.
Edgenivo provides redundancy and automatic failover for Edgenivo Functions using the Edge runtime. For Edgenivo Functions on the Node.js runtime, you can use the functionFailoverRegions configuration in your vercel.json file to specify which regions the function should automatically failover to.
In Edgenivo, the isolation boundary refers to the separation of individual instances of a function to ensure they don't interfere with each other. This provides a secure execution environment for each function.
With traditional serverless infrastructure, each function uses a microVM for isolation, which provides strong security but also makes them slower to start and more resource intensive.
Filesystem support refers to a function's ability to read and write to the filesystem. Edgenivo functions have a read-only filesystem with writable /tmp scratch space up to 500 MB.
Edgenivo Functions are archived when they are not invoked:
- Within 2 weeks for Production Deployments
- Within 48 hours for Preview Deployments
Archived functions will be unarchived when they're invoked, which can make the initial cold start time at least 1 second longer than usual.
When using Next.js or SvelteKit on Edgenivo, dynamic code (APIs, server-rendered pages, or dynamic fetch requests) will be bundled into the fewest number of Edgenivo Functions possible, to help reduce cold starts. Because of this, it's unlikely that you'll hit the limit of 12 bundled Edgenivo Functions per deployment.
When using other frameworks, or Edgenivo Functions directly without a framework, every API maps directly to one Edgenivo Function. For example, having five files inside api/ would create five Edgenivo Functions. For Hobby, this approach is limited to 12 Edgenivo Functions per deployment.
A runtime can retain an archive of up to 100 MB of the filesystem at build time. The cache key is generated as a combination of:
- Project name
- Team ID or User ID
- Entrypoint path (e.g.,
api/users/index.go) - Runtime identifier including version (e.g.:
@vercel/go@0.0.1)
The cache will be invalidated if any of those items changes. You can bypass the cache by running vercel -f.
You can use environment variables to manage dynamic values and sensitive information affecting the operation of your functions. Edgenivo allows developers to define these variables either at deployment or during runtime.
You can use a total of 64 KB in environments variables per-deployment on Edgenivo. This limit is for all variables combined, and so no single variable can be larger than 64 KB.
The following features are supported by Edgenivo Functions:
Edgenivo's Secure Compute feature offers enhanced security for your Edgenivo Functions, including dedicated IP addresses and VPN options. This can be particularly important for functions that handle sensitive data.
Streaming refers to the ability to send or receive data in a continuous flow.
The Node.js runtime supports streaming by default. Streaming is also supported when using the Python runtime.
Edgenivo Functions have a maximum duration, meaning that it isn't possible to stream indefinitely.
Node.js and Edge runtime streaming functions support the waitUntil method, which allows for an asynchronous task to be performed during the lifecycle of the request. This means that while your function will likely run for the same amount of time, your end-users can have a better, more interactive experience.
Cron jobs are time-based scheduling tools used to automate repetitive tasks. When a cron job is triggered through the cron expression, it calls a Edgenivo Function.
From your function, you can communicate with a choice of data stores. To ensure low-latency responses, it's crucial to have compute close to your databases. Always deploy your databases in regions closest to your functions to avoid long network roundtrips. For more information, see our best practices documentation.
A Global Config is a global data store that enables experimentation with feature flags, A/B testing, critical redirects, and IP blocking. It enables you to read data at the edge without querying an external database or hitting upstream servers.
Edgenivo supports Tracing that allows you to send OpenTelemetry traces from your Edgenivo Functions to any application performance monitoring (APM) vendors.
Was this helpful?