Usage

This section is the hands-on guide to using Fission once it is installed on your cluster. Each page states what you will accomplish, lists the commands to run, and shows the output to expect.

If you have not installed Fission yet, start with the Installation guide. For the concepts behind these tasks, see Concepts.

Guide map

Work through the function workflow in roughly this order:

• Create an environment — register a language runtime (NodeJS, Python, Go, and more) so Fission can run your code.
• Create a function — deploy code, add an HTTP route, and test, update, and inspect functions.
• Package source code — build functions from source archives or ship pre-built deployment packages.
• OCI image packages — ship function code as an OCI image instead of an archive, with cache-friendly cold starts.
• Control function execution — choose an executor (poolmgr, newdeploy, or container) and tune scaling, concurrency, and cold starts.
• Provisioned concurrency — keep a floor of warm specialized pods, with cron-scheduled warming windows, so requests inside the floor never pay a cold start.
• Run a container as a function — turn any existing container image into a Fission function.
• Access secrets and ConfigMaps — read Kubernetes Secrets and ConfigMaps from inside a function.
• Access URL parameters — read path parameters from REST-style routes.
• Function versions and aliases — publish immutable versions, route traffic through movable aliases like prod and staging, split traffic between two versions, and roll back instantly.
• Version lifecycle and interactions — automatic publishing, retention, environment drift, and how versions interact with the rest of Fission.
• Canary deployments — roll out a new function version gradually and roll back automatically on failure.

Durable and asynchronous execution:

• Asynchronous invocation — invoke a function fire-and-forget with a durable id, background retries, a dead-letter queue, and result destinations.
• Statestore eventing — publish events to durable built-in topics and subscribe functions with at-least-once delivery, with no external broker.
• Workflows — orchestrate several functions as one durable, resumable state machine with parallelism, retries, and durable waits.

Operational and advanced topics:

• Stream function responses — return SSE, chunked, or WebSocket responses incrementally for LLM tokens, chat, and long-running calls.
• Expose functions as MCP tools — let LLM agents discover and invoke functions over the Model Context Protocol.
• Expose functions with the Gateway API — route external traffic through a Kubernetes Gateway (the successor to Ingress).
• Multi-namespace tenancy — onboard and offboard namespaces at runtime with fission tenant enable/disable, each isolated by its own keys and RBAC.
• Pull from a private registry — authenticate image pulls with an imagePullSecret when an environment image lives in a private registry.
• Use a URL as an archive source — embed a remote URL directly in a package archive instead of uploading the file, for faster, more portable package creation.
• Enable Istio on Fission — install Fission alongside the Istio service mesh with sidecar injection enabled.

For reproducible, version-controlled deployments, also read about the spec-based workflow and how to deploy from CI/CD.