Fission lets developers provide a function and connect it to an HTTP request or another event, while the platform handles running that code on Kubernetes. It is useful for small event-driven services where developers do not want to assemble a separate deployment around every function. The runtime environment supplies the language support, and triggers decide when execution starts. Actual startup latency and resource use depend on that configuration and the workload.
Deployment and operating notes
Fission’s current installation guide uses the fission-all chart and states that fission-core was removed in the 1.15 release. It also specifies release-dependent Kubernetes and architecture requirements and treats CRDs as a separate installation concern. The recovered approximately 100-millisecond cold-start claim is historical context, not a measured result for present runtimes or workloads.
Inventory functions, environments, packages, triggers, secrets and storage before upgrading. Match the CLI, control-plane components and runtime environments to the documented release path. Review router authentication changes and trigger compatibility; a function can deploy successfully while event delivery receives authorization errors. Test HTTP invocation, one asynchronous trigger, failure handling and package retrieval in a separate namespace. Preserve source packages and specifications outside the cluster, and verify rollback limitations around CRD changes. Choose pool-based or other execution behavior according to measured latency and resource cost, rather than assuming every function gets the same warm-container behavior.
Historical upstream link check · 2026-10-09
The recorded upstream address redirects to https://fission.io/ and returned HTTP 200 on 2026-10-09. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
Fast Serverless Functions for Kubernetes.
Fission is a fast serverless framework for Kubernetes with a focus on developer productivity and high performance.
Fission operates on just the code: Docker and Kubernetes are abstracted away under normal operation, though you can use both to extend Fission if you want to.
Fission is extensible to any language; the core is written in Go, and language-specific parts are isolated in something calledenvironments (more below). Fission currently supports NodeJS, Python, Ruby, Go, PHP, Bash, and any Linux executable, with more languages coming soon.
Performance: 100msec cold start
Fission maintains a pool of “warm” containers that each contain a small dynamic loader. When a function is first called, i.e. “cold-started”, a running container is chosen and the function is loaded. This pool is what makes Fission fast: cold-start latencies are typically about 100msec.
Kubernetes is the right place for Serverless
We’re built on Kubernetes because we think any non-trivial app will use a combination of serverless functions and more conventional microservices, and Kubernetes is a great framework to bring these together seamlessly.
Building on Kubernetes also means that anything you do for operations on your Kubernetes cluster, such as monitoring or log aggregation, also helps with ops on your Fission deployment.
Fission Concepts
A function is a piece of code that follows the fission function interface.
An environment contains the language- and runtime-specific parts of running a function.
The following environments are currently available:
| Environment | Image |
|---|---|
| Binary (for executables or scripts) | fission/binary-env |
| Go | fission/go-env |
| .NET | fission/dotnet-env |
| .NET 2.0 | fission/dotnet20-env |
| NodeJS (Alpine) | fission/node-env |
| NodeJS (Debian) | fission/node-env-debian |
| Perl | fission/perl-env |
| PHP 7 | fission/php-env |
| Python 3 | fission/python-env |
| Ruby | fission/ruby-env |
You can also extend environments or create entirely new ones if you want. (An environment is essentially just a container with a webserver and dynamic loader.)
A trigger is something that maps an event to a function; Fission supports HTTP routes as triggers today, with upcoming support for other types of event triggers, such as timers and Kubernetes events.
Usage
# Add the stock NodeJS env to your Fission deployment
$ fission env create –name nodejs –image fission/node-env
# A javascript one-liner that prints “hello world”
$ curl https://raw.githubusercontent.com/fission/fission/master/examples/nodejs/hello.js > hello.js
# Upload your function code to fission
$ fission function create –name hello –env nodejs –code hello.js
# Map GET /hello to your new function
$ fission route create –method GET –url /hello –function hello
# Run the function. This takes about 100msec the first time.
$ fission function test –name hello
Hello, world!
See the examples directory for more.
Running Fission on your Cluster
See the installation guide.
Compiling Fission
See the compilation guide.
Status
Fission is in early alpha. It’s not suitable for production use just yet.
Fission is a project by Platform9 Systems and many contributors.
Sources & further reading
Spotted something that needs another look?
Help improve this page →