Cloud Parts

Fission

Open-source functions on Kubernetes: a pool of warm, generic pods takes your code on the first call, so cold starts stay around 100 ms.

What it is
Serverless functions (FaaS)
Type
Open source
Made by
Fission project (started at Platform9)
License
Apache 2.0
Facts checked
6 October 2026
Website Source code

What it is

Fission adds four object types to a Kubernetes cluster as custom resources. An Environment is a language runtime image (Node.js, Python, Go and others); a Package holds your code; a Function ties code to an environment; and a Trigger binds an event to a function. There are four kinds of trigger: an HTTP route, a cron timer, a message-queue consumer and a watch on Kubernetes objects. Every one of them ends up as an HTTP request to Fission’s router, which forwards it to a pod running the function.

Where that pod comes from depends on the executor you pick per function. The default, poolmgr, keeps a pool of generic pods warm for each environment. On a first call it takes one out of the pool, copies the package in and tells the runtime to load it, which for a small function typically takes well under 100 ms; the pod is reaped after it sits idle. newdeploy instead creates a Deployment, Service and CPU-driven autoscaler per function, and can keep a minimum number of pods running so there is no cold start at all. A third type, container, runs your own prebuilt image.

Platform9 started Fission in 2016, and engineers at InfraCloud, which sells a supported version, have maintained it in recent years. Its pace has been uneven: v1.21.0 (January 2025) and v1.22.0 (December 2025) came nearly a year apart, then five releases followed in May and June 2026, up to v1.27.0 on June 22, 2026. Commits continue, but most of them in 2026 come from a single maintainer.

Why teams pick it

  • Fast cold starts from the pre-warmed pool: typically under 100 ms for a small function
  • Plain Kubernetes underneath: functions are pods and its objects are custom resources, so existing monitoring, RBAC and GitOps tools apply
  • Pick latency or idle cost per function: warm pool, a per-function Deployment with a minimum scale, or your own container image
  • Message-queue triggers built on KEDA cover Kafka, SQS, Kinesis, Pub/Sub, NATS, RabbitMQ and Redis lists, and scale their consumers to zero

Watch out for

  • A small, concentrated maintainer base: most 2026 commits come from one person, after an eleven-month gap between releases in 2025
  • Scale to zero applies to function pods, not to the cluster: you still run the control plane, nodes and the warm pools
  • Every invocation passes through the router as HTTP, and newdeploy scales on CPU rather than on requests or queue depth
  • Cold start grows with package size, so large dependencies erode the warm pool’s advantage

Alternatives

What all serverless functions (faas) have in common →
AWS LambdaAWSAWS’s functions service: upload a handler, connect a trigger, and pay per request and per millisecond.Beta9Open sourceThe open-source engine behind Beam’s cloud: decorate a Python function and it runs as an autoscaling GPU endpoint, task queue or sandbox, on Beam or on your own Kubernetes cluster.Cloudflare Browser RunRenamedCommercialHeadless Chrome on demand in Cloudflare’s network, called Browser Rendering until April 2026: one HTTP call for a screenshot, PDF, Markdown or crawl, or a full browser session driven by Puppeteer, Playwright, CDP or an AI agent.Cloudflare WorkersCommercialFunctions that run in V8 isolates on Cloudflare’s network, close to the user, with almost no cold start.+1 WranglerworkerdOpen sourceThe open-source JavaScript and WebAssembly server runtime behind Cloudflare Workers, which you can run yourself as an application server, a local dev server or a programmable HTTP proxy.Workers AICommercialServerless inference on GPUs in Cloudflare’s network: call one of 50+ open models by name from a Worker binding or a REST API, and pay per unit of GPU work instead of renting GPUs.

How it fits with other technologies

Deploy a function, then expose it over HTTP and on a schedule · bash

fission env create --name nodejs --image ghcr.io/fission/node-env

# default executor (poolmgr): code is loaded into a warm pod on first call
fission fn create --name hello --env nodejs --code hello.js

fission httptrigger create --url /hello --method GET --function hello
fission timer create --name minute --function hello --cron "@every 1m"

# or: a Deployment + autoscaler per function, with one pod always warm
fission fn create --name report --env nodejs --code report.js \
  --executortype newdeploy --minscale 1 --maxscale 3

See it in a real stack

No architecture uses Fission yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2016–2026

Kubernetes was powerful but asked a lot of a newcomer before anything useful ran. Soam Vasani began Fission at Platform9 in late 2016 so that customers could be productive on the first day they installed a cluster. Platform9 announced it on January 24, 2017, together with its managed Kubernetes service, pitching it as Lambda-style functions that run on any Kubernetes cluster.

The alpha supported Node.js and Python, triggered functions from HTTP routes, timers and Kubernetes watches, and already used a pool of warm containers to keep cold starts near 100 ms. Version 1.0 followed in February 2019. Fission was one of several Kubernetes function frameworks of that period; one of its peers, VMware’s Kubeless, has since been archived (its last commits date from December 2021).

Development then slowed: 2024 brought only patch releases of v1.20, and 2025 just two minor releases, eleven months apart. A burst of work in 2026 brought five releases in two months, including a v1.27.0 rewrite that collapsed the executor’s nine controllers into three.

Why it’s built this way

A pool of warm, generic pods
Instead of starting a new container per function, Fission keeps runtime pods already running and loads code into one on demand. That is what brings a cold start down to about 100 ms, at the cost of keeping the pool alive.
Language runtimes as swappable environments
Each environment is a container with a small web server and a dynamic loader, much like a buildpack. Adding a language means building an environment image, not changing Fission’s Go core.
Built on Kubernetes, not its own scheduler
Its authors expected real applications to mix functions with ordinary microservices, and running both on Kubernetes lets one set of monitoring, logging and deployment tools cover everything.
Every trigger becomes an HTTP call
Timers, queue consumers and watchers all post to the same router that serves HTTP routes, so there is a single invocation path to scale and debug.

Timeline

  1. 2016

    Soam Vasani starts Fission at Platform9

  2. 2017

    Announced January 24 as an open-source alpha for Node.js and Python

  3. 2019

    Version 1.0 released in February

  4. 2025

    Releases slow: v1.21.0 in January, v1.22.0 in December

  5. 2026

    Five releases in May and June, through v1.27.0 and an executor rewrite

Sources11 · facts checked 6 October 2026

Improve this page on GitHub