OpenFaaS CE: what the openfaas/faas repository actually gives you

The problem openfaas/faas solves, and who it is for

Deploying a small HTTP handler to Kubernetes normally means writing a Deployment, a Service, an Ingress, a horizontal pod autoscaler and a health check before the first line of business logic runs. OpenFaaS collapses that into a function definition and a container image. The README states the goal plainly: deploy event-driven functions and microservices to Kubernetes "without repetitive, boiler-plate coding", packaging code or an existing binary in an OCI-compatible image to get "a highly scalable endpoint with auto-scaling and metrics".

The audience is narrower than the tagline suggests. The README carries a blockquote stating that OpenFaaS Community Edition is licensed for individual exploration and hobbyist use, that a 60 day limit applies for commercial PoCs, and that commercial and production workloads require OpenFaaS Standard or OpenFaaS for Enterprises. Internal use within a company requires a licence. So the repository is a learning and personal-project tool, not a free production platform. Anyone evaluating it for a company should read that sentence before anything else.

What is inside the openfaas/faas repository

This repository is not the whole platform. The top-level entries are the gateway, api-docs, sample-functions, contrib, docs, a pro directory, a Makefile, go.mod, and governance files including EULA.md, LICENSE and SECURITY.md. The Go module is declared as github.com/openfaas/faas on Go 1.22. The gateway is the component this repo builds; the Kubernetes provider lives in a separate project, faas-netes, which the README links when it describes portability.

The Makefile shows how the gateway image is produced. It sets TAG to latest and NS to openfaas by default, and the build-gateway target runs a docker buildx build for linux/amd64, tagging the result as openfaas/gateway:latest-dev. There is also a generate target that deletes gateway/models/model_*.go and regenerates them from api-docs/spec.openapi.yml using openapi-generator-go. That spec is the contract between the gateway and its clients, and the models directory is generated rather than hand-written. A commented-out test-ci target points at contrib/ci.sh, so the CI recipe is present but disabled in this file.

How the gateway, templates and scaling fit together

The architecture in the README is a layered stack: a gateway in front, a provider that talks to the orchestrator behind it, and functions as OCI images. The gateway is the single entry point that receives HTTP calls and routes them. The provider translates those calls into Kubernetes objects. Functions are ordinary containers, which is why the README can claim portability to existing hardware or public or private cloud through Kubernetes.

Scaling is handled by the platform rather than the function. The README lists auto-scaling as demand increases, "including to zero", and links to an autoscaling page in the docs. Triggers are separate from invocation: the README points to HTTP or event sources such as Apache Kafka and AWS SQS, and to built-in queuing and background processing for asynchronous work. Metrics are part of the pitch, and Prometheus is listed among the repository topics.

Language support comes from templates, not from a runtime the project maintains. The README shows a Node.js handler exporting an async function that receives event and context and returns context.status(200).headers(...).succeed(...); a Python handler named handle that returns a dict with statusCode and body; and a Go handler using net/http. Official templates exist for many languages and the README notes they are extensible with Dockerfiles, so any language with a container image is reachable.

Installing OpenFaaS CE and running a first function

The README does not give a single install command. It points to a deployment guide at docs.openfaas.com/deployment for Kubernetes, OpenShift or faasd, and it recommends faasd as the lightweight way to start learning. Follow that guide for the platform itself; the commands below are the ones the README does show, for scaffolding and building a function once a gateway is reachable.

Scaffold a function from an official template. The README gives this exact example, naming the function stripe-webhooks and the node20 template:

faas-cli new --lang node20 stripe-webhooks

That produces a handler file and a YAML definition. The Node.js handler the README shows returns a response through the context object:

"use strict"

module.exports = async (event, context) => {
    return context
        .status(200)
        .headers({"Content-Type": "text/html"})
        .succeed(`
        <h1>
            👋 Hello World 🌍
        </h1>`);
}

If you prefer Python, the README's python3-http example is a function named handle returning a dictionary with statusCode and body:

def handle(event, context):
    return {
        "statusCode": 200,
        "body": "Hello from OpenFaaS!"
    }

Build and push the image, then deploy through the same CLI and YAML file that scaffolding created. The README describes the CLI as using a YAML format for templating and defining functions, and the UI portal as the other way in. It shows the Community Edition UI running an inception function from the store, so a first successful deploy is visible as a function you can invoke from the portal.

Where OpenFaaS CE stops being the right tool

The licence is the first wall. The README states that CE is not licensed for commercial use of any kind beyond an initial trial period, and that internal use within a company or business requires a licence. A team that prototypes on CE and then ships the same setup to production is outside the terms, not merely under-supported.

The feature gap is the second. The README describes CE as having "basic or primitive features and capabilities compared to the commercial versions", and says the commercial products are maintained and developed independently by a full-time team with commercial support, active maintenance for CVEs, and updates in the Kubernetes and cloud native ecosystem. That last point matters operationally: a self-hosted gateway that tracks Kubernetes releases needs someone to keep it current, and CE does not come with that commitment.

There is also a scope limit inside this repository. It builds the gateway. The Kubernetes provider is faas-netes, and the lightweight option is faasd, both separate projects. Anyone expecting a single clone-and-run repository will be surprised by how much of the system lives elsewhere. The README's own quickstart routes you to the deployment guide rather than to a command in this repo.

OpenFaaS vs Knative, OpenWhisk and the alternatives

The closest comparison people search for is Knative. Knative is a set of Kubernetes primitives for serving and eventing, and it expects you to work in Kubernetes terms: revisions, routes, brokers and triggers are Kubernetes resources you compose yourself. OpenFaaS puts a gateway in front and exposes functions as HTTP endpoints with a CLI and a UI, which is a smaller conceptual surface but also less flexible when your traffic pattern does not look like a function behind a route.

Apache OpenWhisk takes a different route again. It is an event-driven platform with its own action model and a heavier control plane, historically aimed at multi-tenant operation. OpenFaaS's distinguishing choice is that a function is just an OCI image, which means your existing build pipeline and registry keep working and there is no new packaging format to learn. The cost of that choice is that you own the image lifecycle yourself.

The honest summary is that OpenFaaS CE competes on simplicity of the developer path, not on depth of platform features. If you need the depth, the README points at the commercial tiers rather than at a community roadmap.

Licence, maintenance and upgrade cost

The repository is not archived, and the last push was on 2026-07-02. The most recent release listed is 0.27.14, described as protecting telemetry with BasicAuth, on the same date. Before that, 0.27.13 updated Go to 1.24 and vendored dependencies for the CE gateway on 2025-08-29, and 0.27.12 was a maintenance release on 2024-12-09. The pattern is maintenance rather than feature work, with gaps of months between releases.

The licence field on the repository is NOASSERTION, and the repository ships an EULA.md alongside LICENSE. The README's own wording is the operative part: CE is for individual exploration and hobbyist use, with a 60 day limit for commercial PoCs, and commercial or production workloads require a paid tier. This is not legal advice; read EULA.md and LICENSE yourself, and treat the EULA as the document that governs your use.

Upgrade cost is a real line item. The gateway is built from this repo, and the Makefile's build-gateway target produces openfaas/gateway:latest-dev for linux/amd64, which is a development tag rather than a pinned release. If you run CE, you are responsible for tracking gateway releases, the Go toolchain version, and the Kubernetes API changes the commercial team tracks for paying customers. Budget for that, or budget for a licence.

Editorial conclusion

Adopt OpenFaaS CE if you are an individual or hobbyist who wants event-driven functions on Kubernetes or faasd and can live with the CE EULA. Do not adopt it for commercial or production workloads: the README states those require OpenFaaS Standard or OpenFaaS for Enterprises, and the CE tier is described as having basic or primitive features. Before you commit, read EULA.md in full, confirm which gateway image the deployment guide pulls, and check whether faasd or faas-netes fits your environment.

Frequently asked questions

Official sources

1. Issues
2. openfaas/faas on GitHub
3. Project website
4. README
5. Releases