Fission: serverless functions on Kubernetes without the Dockerfile

The problem Fission targets: functions on a cluster you already run

Most function platforms ask you to accept their runtime, their scheduler and their network boundary. Fission takes the opposite position. It assumes Kubernetes is already the substrate, and it treats the cluster as the deployment target rather than something to hide. The README states the reasoning plainly: any non-trivial application mixes serverless functions with conventional microservices, and Kubernetes is where those two meet. That is the argument for the project, and it also defines its audience.

The audience is a platform or backend team that already operates Kubernetes and has monitoring, log aggregation and ingress in place. The README notes that operational tooling you run for the cluster also applies to a Fission deployment, which is the practical benefit of not inventing a parallel control plane. If you do not run Kubernetes, Fission is not a shortcut to running functions; it is a second workload on infrastructure you would have to build first.

The abstraction boundary is worth stating precisely, because it is narrower than the marketing phrase "just the code" suggests. Fission abstracts Docker and Kubernetes away under normal operation, and the README says you can still use both to extend it. So the default path hides images and pods, but the extension path does not. Teams that need custom base images or sidecars will find themselves back in Kubernetes territory quickly.

Environments, warm containers and the 100msec cold start claim

Fission separates language support from the core. The core is written in Go, and language-specific parts live in environments. The README lists NodeJS, Python, Ruby, Go, PHP, Bash and any Linux executable as supported, and describes the environment as the isolation boundary for a language. An environment is created once per cluster and referenced by name when a function is created, which is why the getting-started example creates the NodeJS environment before the function that uses it.

The performance mechanism is a pool of warm containers, each holding a small dynamic loader. When a function is invoked for the first time, a running container is selected and the function is loaded into it. The README describes cold-start latency as typically about 100msec and attributes that figure to the pool. This is a real architectural difference from platforms that start a fresh sandbox per invocation: Fission pays for the pool in idle container memory and buys back start time.

The trade-off is that the pool is a standing resource cost. The README does not document how pool size is tuned, what the memory floor is for an idle environment, or how the loader behaves when a function has heavy native dependencies. Those are the questions a capacity planner will ask, and the README leaves them to the documentation site.

Installing Fission and running a first function

The README does not contain installation steps. It points to the installation guide at fission.io/docs/installation, and the repository carries a charts/ directory plus a skaffold.yaml and kind.yaml at the top level, which is where a cluster-side install would come from. The CLI is the client side of the workflow, and the getting-started block in the README is the shortest path to a working function once a cluster is available.

First, register a language environment. This pulls the stock NodeJS environment image into your Fission deployment:

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

Second, create a function that references that environment by name and points at source code rather than a built image. The README uses a one-line JavaScript example hosted in the examples repository:

fission function create --name hello --env nodejs --code https://raw.githubusercontent.com/fission/examples/master/nodejs/hello.js

Third, invoke it. The README notes this takes about 100msec the first time, which is the warm-pool behaviour described above:

fission function test --name hello

The expected output is the line Hello, world!. What matters here is the shape of the workflow: no Dockerfile, no registry push, no image tag to manage. The function is identified by name and environment, and the code is fetched at creation time. For a team used to building an image per function, that is the whole pitch in three commands.

Where Fission is the wrong tool

The clearest limitation is the one implied by the architecture: Fission is only as available as the cluster it runs on. There is no managed control plane in this repository, and the README makes no availability claim beyond the framework itself. A team that wants a provider to own uptime, scaling limits and regional failover is looking at the wrong category of product.

The second limitation is the one the README is silent on. It documents creating environments and functions, and it points to a troubleshooting guide for debugging functions and installations. It does not document rollback of a function or an environment, and it does not describe versioning of deployed functions. For anyone who has been burned by a bad deploy at an inconvenient hour, that silence is a real gap, and it is a gap in the README rather than a claim that the capability is absent.

The third is the cold-start figure itself. The README's 100msec number is presented as typical and is tied to the warm pool. It is not a guarantee, and the README does not break the number down by language or by payload. A Python function with a large import graph and a NodeJS one-liner are not the same workload, and nothing in the README says they behave the same. Treat the figure as an order of magnitude, not a service level.

Fission against Knative and OpenFaaS

The natural comparison is with the other Kubernetes-native function platforms, and the difference is mostly in what the developer touches. Knative builds on Kubernetes primitives for serving and eventing and expects you to ship a container image, with the revision model providing the versioning and traffic splitting that Fission's README does not describe. If you want canary rollouts and per-revision traffic control as first-class concepts, Knative's model is closer to that requirement out of the box.

OpenFaaS also runs on Kubernetes and also centres on a CLI and a function store, but its default unit is a container image built from a template, and its scaling story leans on its own autoscaler component. Fission's distinction is the environment abstraction plus the warm container pool: the language runtime is a cluster-level resource, and the function is code loaded into a pre-warmed process. That is what produces the sub-second first invocation the README describes, and it is also what makes language support a matter of writing an environment rather than writing a template.

A fair summary: choose Knative if revision-level traffic management and the broader Knative ecosystem matter more than start latency. Choose OpenFaaS if you want the image-build workflow and its ecosystem of templates. Choose Fission if you want to deploy functions from source with a per-language environment and you are willing to run the warm pool.

Maintenance, upgrades and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-15, which is recent. Releases are frequent: v1.25.0 on 2026-06-05, v1.26.0 on 2026-06-13 and v1.27.0 on 2026-06-22, all within the same month. That cadence is the practical upgrade cost. Three minor releases in under three weeks means a team pinning to a version needs a plan for moving forward, and the README does not describe a supported upgrade path or a compatibility policy between releases. The CHANGELOG.md and RELEASES.md files at the top level are where that information would live.

The build tooling is visible in the repository layout: a Makefile with a check target that runs tests, builds the CLI and cleans up, a skaffold.yaml with a kind profile for local cluster development, and a charts/ directory for the Kubernetes install. The Makefile also gates the tree with a custom static analyzer against a baseline file, which is an unusual amount of internal tooling for a project of this size and suggests the maintainers care about code-level consistency.

Fission is licensed under Apache-2.0, with the LICENSE file at the repository root and SPDX headers in source files such as the Makefile. Apache-2.0 permits commercial use and modification and includes an explicit patent grant, which is generally the permissive option enterprises expect. This is a description of the licence text, not legal advice; anyone embedding Fission in a product should have their own counsel review the terms and the notice requirements.

Editorial conclusion

Adopt Fission if you already run Kubernetes and want function deployment driven by source code and a CLI rather than a per-function image build. Do not adopt it if you need a managed control plane, a documented rollback path, or a serverless platform that keeps running when your cluster does not. Before committing, verify three things in your own cluster: that the Helm chart in charts/ installs cleanly against your Kubernetes version, that the environment image you intend to use (for example ghcr.io/fission/node-env) is pullable from your nodes, and what your upgrade path is between the v1.25.0, v1.26.0 and v1.27.0 releases, because the README does not document rollback.

Frequently asked questions

Official sources

1. fission/fission on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases