Skip to main content
Functions are designed to let you deploy code once and invoke it on demand, without managing long-running processes or reserving compute for idle time. You package your handler in an OCI image, deploy it to FissionPlane, and invoke it over HTTPS or on a schedule. Between invocations FissionPlane releases the compute slot entirely — scaling to zero. When a request arrives, a microVM starts from a warm snapshot in milliseconds and runs your handler to completion.
Functions are on the FissionPlane roadmap and are not yet available in the current release (v0.0.1). The design described on this page reflects planned behavior. If you need one-shot isolated execution today, sandboxes are the right primitive — create a sandbox, run your command, collect the result, and delete it.
Functions and sandboxes run on the same substrate — the same Firecracker microVMs, the same immutable templates, the same capability token model — but serve different use cases. A sandbox is stateful and interactive: you create it, run a series of commands, and delete it when you’re done. A function is deployed once and invoked many times: each invocation is ephemeral and isolated from every other.

​
How functions will work

1

Build a template from your OCI image

FissionPlane boots your image, runs any setup steps you specify, and snapshots the result as a template artifact. This is the warm snapshot every invocation will start from.
2

Deploy a function pointing at that template

A function deployment binds a handler entry point to a template version. FissionPlane maintains a pool of warm snapshots ready to be restored on demand.
3

Invoke the function

Each invocation restores a microVM from the warm snapshot, runs your handler, and returns the result. The microVM is released when the handler exits. The next invocation gets a fresh environment.
Because each invocation starts from the same snapshot, your handler always sees the same initial filesystem and process state. Side effects from one invocation never bleed into the next.

​
Planned API shape

The examples below illustrate the intended API. These methods are not available in v0.0.1.

​
Deploying a function

TypeScript
Python

​
Invoking a function

TypeScript
Python

​
Scheduling functions

TypeScript
Python

​
Versioning and rollback

Every deployment creates a new version. Versions are immutable: deploying new code does not change existing versions. You can roll back to any previous version with a single call.
TypeScript
Python

​
Intended use cases

Serverless APIs

Put your handler behind a stable HTTPS endpoint. FissionPlane scales it down to zero between requests and back up in milliseconds when traffic arrives.

Scheduled jobs

Run functions on a cron schedule. Each execution gets a clean, isolated microVM — no accumulated state, no dependency on previous runs.

Batch processing

Fan out work across many function invocations in parallel. Each runs in isolation and exits when complete.

Webhooks and event handlers

Wire up a function to any HTTPS webhook. Handle events without maintaining a long-running service.

​
What to use today

Until functions ship, sandboxes cover the one-shot execution pattern well. Create a sandbox, run your command, collect the result, and delete it. The latency is slightly higher than a pre-warmed function invocation, but the isolation guarantees are identical — the same Firecracker microVM, the same hardware boundary.