OpenFaaS: the CE licence gates commercial use before you read a line of Go

The CE licence is the first thing to read, not the code

OpenFaaS is easy to like and easy to misjudge, because the repository is public and the code is Go, but the licence is not a conventional open source grant. The repository's licence field does not resolve to a standard identifier, and the README states plainly that Community Edition is licensed for individual exploration and hobbyist use, with a 60 day limit applying to commercial proofs of concept. Commercial and production workloads are directed to the Standard or Enterprise products.

The tiers section is more direct. CE is licensed for non-commercial use by individuals and as a time-limited trial for commercial proofs of concept, and internal use within a company or business requires a licence. It also states that CE has usage restrictions set out in an EULA file, that it has basic or primitive features compared to the commercial versions, and that it is not licensed for commercial use of any kind beyond the initial trial.

Consequence for the reader: a team that finds OpenFaaS attractive cannot simply run the Community Edition on a company cluster and expect to be within the terms. That is a licensing question, not an engineering one, and the answer lives in the EULA, which you should read against your own situation rather than take from any summary, including this one.

faas-cli scaffolds a function that becomes an OCI image

The mechanism is straightforward. You scaffold a function with the CLI, passing a name and a language template, for example `faas-cli new --lang node20 stripe-webhooks`, and the result is code plus a build recipe. That code, or an existing binary, is packaged into an OCI-compatible image which is deployed as a highly scalable endpoint with auto-scaling and metrics.

So the unit of deployment is a container image, and the unit of work is a single function. Official templates exist for many popular languages and are extensible with Dockerfiles, and there is a template store. The CLI also supports YAML for templating and defining functions.

What you get for free from the platform is the part that usually takes work in a functions setup: the endpoint, the scaling behaviour, and the metrics. What you own is the code inside the image and the build of that image.

This design is why OpenFaaS is described as portable. It runs on existing hardware or on public or private cloud by leveraging Kubernetes, and it can deploy to Kubernetes or OpenShift. Portability here means it runs on a substrate such as Kubernetes, OpenShift or faasd, not that it is substrate-free.

Each language template defines its own handler signature

There is no single universal SDK, because the handler contract is defined by the template you pick. Three examples in the documentation show three different shapes.

For Node.js with the `node20` template, the handler is an async function that receives an event and a context and builds its response through that context:

"use strict"

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

For the `python3-http` template the handler is a plain function returning a dictionary with a status code and a body. For the `golang-middleware` template, the example is a `net/http` handler that reads the request body and writes a response, so the Go path is a middleware signature rather than an event-and-context pair.

Consequence for the reader: the abstraction is a function, not a framework. Porting a function between languages means relearning the response convention, and a team with a strong house style will find themselves adapting to the template rather than the template to them.

Auto-scaling includes scaling to zero, which changes the cost shape

The scaling story is the part that most affects whether OpenFaaS fits, and the specific claim is that it auto-scales as demand increases including to zero.

Scaling to zero is a double-edged property. It removes the idle cost of a function that nobody is calling, which is the main economic argument for a functions platform over a small always-on service. It also means a cold start is part of normal operation rather than an exception, so the first request after an idle period pays the wake-up latency. For a webhook receiver or a bursty job that is a good trade. For anything with a tight latency budget and sparse traffic, it is a design decision you are making about your own users.

The platform is also described as running on existing hardware, so scaling and portability are linked to running on a substrate you control. The metrics that come with each function are what you use to watch this behaviour, and they are part of the same endpoint contract.

The README does not quantify cold start time, so treat any figure you have seen elsewhere as unverified against this project.

Triggers reach past HTTP into Kafka and SQS, with built-in async

HTTP is the default trigger, but the documentation points to event sources as well, naming Apache Kafka and AWS SQS specifically. Alongside that there is a built-in queuing and background processing capability, referred to as async.

So the intended shape is not only request and response. A function can be the consumer of an event stream, and long-running or slow work can be handed to the platform's queue rather than held in an HTTP request. That is what separates this from a thin wrapper over a web framework.

Consequence for the reader: the event-driven and async parts are where the real design work lives, and the README does not describe their semantics, delivery guarantees or retry behaviour. Those details are in the linked documentation, not here, so treat the trigger list as a capability headline rather than a specification and read the triggers and async references before designing around them.

The gateway build targets amd64 and its models are generated

If you build from source, two things in the build configuration are worth knowing. The gateway is built through a buildx command that targets a single architecture:

(cd gateway;  docker buildx build --platform linux/amd64 -t ${NS}/gateway:latest-dev .)

The platform flag is hard-coded to `linux/amd64`, and the image is tagged as a development build. Building the gateway for arm64, the usual case on Apple silicon or ARM cloud hosts, is not what this target does, so you would adjust the platform yourself.

The second detail is that the gateway's data models are generated, not hand-written. A make target removes the existing generated model files and regenerates them from an OpenAPI specification using an openapi-generator tool, writing them into the gateway models package from a spec file kept in the repository. If you see a generated file, editing it directly will be overwritten the next time the target runs.

A version detail is also easy to misread. The module file declares its minimum Go version as 1.22, while a recent release is titled around updating Go to 1.24 and vendoring for the Community Edition gateway. The declared minimum and the toolchain used to produce a given release are not the same number, so build with the version the release notes reference rather than the one in the module file.

Multi-tenancy, the dashboard and GitOps sit above the free tier

Several of the capabilities that make a functions platform feel production-ready are pointed at the commercial tiers rather than included in CE. The Standard and Enterprise products are described as full and distinct commercial products, maintained and developed independently by a full-time team with commercial support and active maintenance for CVEs and updates across the Kubernetes and cloud native ecosystem.

The dashboard is one of them. The quickstart shows a Community Edition interface designed for ease of use, and separately notes that Standard and Enterprise have their own newer dashboard with multi-tenancy support. So the multi-tenant console a platform team would want for serving several internal groups is a paid feature, not something you get by deploying CE.

Around that sit ecosystem links, some commercial and some not: GitOps from OpenFaaS Cloud, production guides, and service mesh integration with Istio or Linkerd through featured tutorials. CVEs deserve particular attention for anyone running this in anger, because the README ties active CVE maintenance to the commercial tiers.

Consequence: evaluate the CE gaps against your actual requirements, especially multi-tenancy and security response, rather than assuming the open repository covers them.

Editorial conclusion

OpenFaaS suits an individual learning functions, or a company evaluating whether the Standard or Enterprise tier justifies its cost, since the function model, the OCI image packaging and the Kubernetes deployment are genuinely approachable. It is a poor fit for running it as-is inside a business, because the Community Edition licence is not a standard open source grant and internal use requires a licence. Before you deploy anything, read three things: the EULA that governs your use, whether the CE feature gaps matter for a production workload, and which Kubernetes, OpenShift or faasd target you are deploying to.

Frequently asked questions

Official sources

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