Skip to main content
FissionPlane ships as a single Helm chart that installs the entire platform — control plane, gateway, and node runtime — into your existing Kubernetes cluster. The chart requires no operator and makes no cluster-wide changes. Once it’s running, you’ll retrieve the control plane URL and API key, then point any FissionPlane SDK at them.
FissionPlane is currently at version 0.0.1. Treat the platform and all SDKs as unstable. Breaking changes may occur between releases without a deprecation period until a stable release is published.

Prerequisites

Confirm the following before you begin:
  • Kubernetes 1.28 or later. FissionPlane is tested against the three most recent minor releases.
  • Helm 3. The chart uses Helm 3 features and is not compatible with Helm 2.
  • A node pool with KVM support. Firecracker requires hardware virtualization. Each node in the sandbox pool must expose /dev/kvm. Verify this by running ls /dev/kvm on a candidate node.
  • Object storage for snapshots. Sandbox pause/resume writes memory snapshots to an S3-compatible bucket or blob store. You’ll configure the storage credentials during the Helm install.

Supported platforms

FissionPlane runs on any conformant Kubernetes distribution:

Amazon EKS

Use metal or compute-optimized instance types (for example, c5.metal or m5.metal) that expose nested virtualization.

Google GKE

Enable nested virtualization on your node pool. GKE Bare Metal and GKE on Google Cloud both work.

Azure AKS

Use Dv3 or Ev3 series VMs with nested virtualization enabled, or AKS on bare-metal hardware.

k3s / bare metal

Any Linux node that exposes /dev/kvm works. Air-gapped networks are fully supported.

Node pool requirements

Run sandbox workloads on a dedicated node pool to isolate them from control-plane components and other cluster workloads.
  • Each node must expose /dev/kvm (hardware or nested virtualization enabled at the hypervisor).
  • Apply the taint fissionplane.dev/sandbox=true:NoSchedule to sandbox nodes so only FissionPlane workloads are scheduled there.
  • Size the pool based on your expected concurrent sandbox count. Each Firecracker microVM reserves its own CPU and memory.

Install with Helm

1

Add the FissionPlane Helm repository

Register the FissionPlane chart repository with Helm:
The chart repository URL above is a placeholder. The Helm chart has not yet been published to a public repository. Check the FissionPlane repository for the latest deployment instructions and the actual chart location when it is available.
2

Update your local chart cache

Fetch the latest chart metadata from the repository:
3

Install the chart

Install FissionPlane into a dedicated namespace. Pass your chosen API key as a Helm value — you’ll use this key to authenticate SDK clients.
The chart deploys the control plane, gateway, and node-runtime components. Kubernetes will schedule sandbox workloads only on nodes that tolerate the fissionplane.dev/sandbox=true:NoSchedule taint.
For production installs, store your full configuration in a values.yaml file and pass it with -f values.yaml instead of using --set flags on the command line. This makes upgrades and version control much easier.
4

Verify the installation

Wait for all pods to reach the Running state:
You should see output similar to:
If any pod is stuck in Pending or CrashLoopBackOff, check the node pool taint configuration and confirm /dev/kvm is accessible on your sandbox nodes.
5

Retrieve the control plane URL

Get the external address of the FissionPlane gateway service:
Look for a service of type LoadBalancer. The EXTERNAL-IP column shows the address your SDK clients will use. If you’re on a cluster without a load balancer controller, configure an Ingress or use NodePort instead.
Your control plane URL is https://<EXTERNAL-IP> (or your DNS name if you’ve configured one).

Air-gapped installs

If your cluster cannot reach the public internet, pull all required container images from an external machine first, push them to your internal registry, and then override the image registry during the Helm install.
For air-gapped installs, also mirror the chart itself using helm pull fissionplane/fissionplane --untar and serve it from your internal chart repository, so helm repo update doesn’t need internet access.

Configure the SDK after install

Once the control plane is running, export its URL and your API key so any FissionPlane SDK can connect automatically:
Every SDK reads these two variables at startup. You can verify connectivity by creating and immediately deleting a sandbox:
A successful run confirms that your control plane, node runtime, and SDK are all wired up correctly. Head to the Quickstart for a full end-to-end walkthrough.