Create Environment
Create a language runtime environment with fission env create, set CPU/memory limits and poolsize, and attach a builder image for source builds.
Function
Fission function
Create Function
Create a function with fission fn create, route HTTP traffic to it, test it, and update its code through the everyday function workflow.
Accessing URL parameters
Define path parameters in an HTTP trigger URL with gorilla/mux patterns and read their values inside a function via request headers.
Secrets, ConfigMaps, and Environment Variables
Mount Kubernetes Secrets and ConfigMaps into a Fission function as files, or inject them and literal values as per-function environment variables.
Pull an Image From a Private Registry
Pull environment images from a private registry by passing an imagePullSecret to fission environment create with –imagepullsecret.
Use URL as archive source when creating functions/packages
Embed a remote URL directly in a package archive when creating functions or packages to cut creation time and improve spec portability.
Local development with run-local
Run a Fission function locally in Docker against its real environment image — no cluster round-trip — with hot reload, a builder pass, and config mounts.
Debugging and diagnosing functions
Diagnose a failing Fission function with fission function describe, failure attribution from fission function test, and per-invocation request-id tracing.
Packaging source code
Create source and deployment packages with fission package, build source archives on the cluster with a builder, and attach packages to functions.
OCI image packages
Ship Fission function code as an OCI image instead of an archive: build a code-only image, create a package with –oci, and pin digests for fast cold starts.
Building a Custom Environment
Build or modify a Fission environment: implement the specialize HTTP contract, write the runtime and builder images, test locally, and add a new language.
Controlling Function Execution
Choose and configure a function executor (poolmgr, newdeploy, or container) with –executortype to control cold starts and per-function autoscaling.
Provisioned Concurrency
Keep a floor of warm specialized pods for a poolmgr function, with cron-scheduled warming windows, so requests inside the floor never pay a cold start.
Running container as functions
Run an existing container image as a function with the container executor via fission function run-container, without an environment or builder.
Function State
Give a function durable, per-key state — counters, sessions, carts, rate limits, agent memory — over a local HTTP API, with no external Redis or database and no credentials in your code.
Streaming Responses
Stream a Fission function’s response incrementally over Server-Sent Events, HTTP chunked transfer, or WebSocket — for LLM tokens, chat, and long-running calls.
Canary Deployments for Functions
Gradually shift HTTP traffic to a new function version with a CanaryConfig, using Prometheus health checks to auto-rollback on failure.
Function Versions and Aliases
Publish immutable versions of a function, route traffic through movable aliases like prod and staging, split traffic between two versions, and roll back instantly — without touching triggers or paying a cold start.
Functions as MCP Tools
Expose a Fission function as a Model Context Protocol (MCP) tool so LLM agents can discover and invoke it, with a JSON Schema for inputs and JWT-scoped access.
Asynchronous Invocation
Invoke a Fission function fire-and-forget — the router enqueues the call, returns a durable invocation id, and delivers it in the background with retries, a dead-letter queue, and result destinations.
Version Lifecycle and Interactions
Mint function versions automatically on every update, bound version history with retention GC, track environment drift, and understand how versions interact with async invocation, canaries, state, and other triggers.
Enabling Istio on Fission
Install Fission with the Istio service mesh and enable automatic sidecar injection for Fission and function pods.