Apache OpenServerless: building serverless runtimes from source

Two audiences, and the README serves the second one

The first thing the Apache OpenServerless README does is sort you into one of two groups. If you want to install it to use it, the documentation site and the quick start are linked. If you want to contribute, the contribution guide and the developer guide are the documents to read. If you want to discuss, there is a mailing list, and if you are releasing a version, there is a release process document.

Then the README draws a line under that and says the rest of the document covers building Apache OpenServerless from source, for developers of the project itself. That is a candid framing, and it tells you what kind of repository you are looking at. The user documentation lives on openserverless.apache.org, and the repository README is a developer document with an important warning attached.

That warning is about the main branch. Building from the latest sources in git is not recommended for production use, because the main branch may contain unstable, untested or incomplete changes, and for production deployments you should use an official release tarball instead.

The project is Apache OpenServerless, marked as incubating, an effort undergoing incubation at the Apache Software Foundation and sponsored by the Apache Incubator PMC. The licence is Apache 2.0, the homepage is openserverless.apache.org, the topics are cloud, kubernetes, openserverless and serverless, and the last push was on 2026-10-22. The repository publishes no GitHub releases, which is consistent with the version being taken from the distribution area instead.

Building from a release tarball means verifying a signature first

The recommended build path for anyone who wants to build the project is a release tarball from the Apache distribution area rather than a git clone. The commands are:

curl -O https://dist.apache.org/repos/dist/dev/incubator/openserverless/<version>/openserverless-<version>-incubating-src.tar.gz
tar xzvf openserverless-<version>-incubating-src.tar.gz
cd openserverless-<version>-incubating-src

The version placeholder is the release you want, for example v0.9.0, and the distribution area page lists the available versions. Note the -incubating suffix in the filename, which is how the ASF marks a project that has not yet graduated.

Release artifacts are signed, and the README says to verify the tarball against the project KEYS file before building:

curl -O https://dist.apache.org/repos/dist/dev/incubator/openserverless/<version>/openserverless-<version>-incubating-src.tar.gz.asc
curl -O https://dist.apache.org/repos/dist/release/incubator/openserverless/KEYS
gpg --import KEYS
gpg --verify openserverless-<version>-incubating-src.tar.gz.asc

The KEYS file comes from the release path rather than the dev path, which is the detail to get right, since the two directories hold different things.

Alternatively you can clone the latest sources from the main branch or a release branch:

git clone --branch <branch> https://github.com/apache/openserverless --recurse-submodules
cd openserverless

And the flag is not optional. Most of the code lives in git submodules, so --recurse-submodules is required, and if you already cloned without it you run git submodule update --init --recursive before building, otherwise the submodule directories are empty and the build fails in confusing ways.

The build runs inside a disposable VM so your host stays clean

There is one script per platform, and each of them builds and tests inside a disposable Linux VM or WSL distribution, so the build never touches your host toolchain. That is the central design decision of the developer workflow, and it solves a real problem: a serverless runtime builder pulls in Go, container tooling, Kubernetes clients and license checking, and installing all of that onto a laptop is a good way to break something else.

On Linux you need Ubuntu 22+ or Debian 11+, and you execute the build-and-test-ubuntu.sh script directly. It can work on other distros but you have to adapt the scripts.

On Windows you need Windows 10 or 11 with WSL, and you execute the build-and-test-windows.ps1 script from PowerShell.

On macOS you have to install lima, for example with brew install lima, and then run the build-and-test-mac.sh script.

The lima dependency on macOS is the interesting one, because the build needs a Linux environment, and a lightweight virtual machine tool provides one.

The top level of the repository holds all three scripts plus a build directory, a dependencies/ directory, a devcontainer and an openserverless.code-workspace file, so there is a containerised development path as well as the VM one.

The prerequisites list is the real dependency list

The development setup section lists what you need on the path, and it is a longer list than a Go project usually carries.

You need a Unix environment, either macOS, Linux or Windows WSL. You need docker on the path. You need go available on the path. You need task, the Taskfile runner, available in the path. You need jq, zip, unzip and kubectl available in the path. And you need license-eye on the path, to check the license headers.

That last one is an Apache project convention turned into a build dependency. Every file in the repository has to carry the standard Apache licence header, and license-eye is the tool that checks it. The repository has a .licenserc.yaml and a .rat-excludes file for it, and the task file exposes it as a separate command.

The per-platform sections install all of these. On a plain Ubuntu Linux with a user who has sudo, the sequence is:

sudo apt-get update
sudo apt-get -y install jq
sudo snap install go --classic
sudo snap install task --classic
sudo snap install kubectl --classic
curl -sL get.docker.com | sudo bash
go install github.com/apache/skywalking-eyes/cmd/license-eye@latest
export PATH="$PATH:$(go env GOPATH)/bin"
sudo usermod -aG docker $USER
newgrp docker
docker ps

The last three lines are the ones that trip people up. Adding yourself to the docker group and starting a new group session takes effect only after newgrp docker, and the docker ps at the end is there to confirm the daemon is reachable with the new group membership rather than to check anything about the project.

The macOS variant is shorter, since Homebrew covers most of it:

brew install task go jq kubernetes-cli
go install github.com/apache/skywalking-eyes/cmd/license-eye@latest
export PATH="$PATH:$(go env GOPATH)/bin"

The Windows route installs Ubuntu-24.04 into WSL and then uses snap for go, task and kubectl, because WSL does not have a native package manager for those.

Three task commands cover the build, the tests and the headers

The build itself is driven by Task, with the task file at the repository root as Taskfile.yml, and the README describes the task files as basically shell scripts wrapped in a yaml environment.

The procedure is to clone with submodules, change directory, then build with task build, run the test suite with task test, and check that all the files have the license header with task license.

The README also points you at the developer guide for a guided tour of how the system is put together, listing the topics: the cli, the opsroot.json configuration, how tags drive the builds, the development loop, and how images are published. The existence of a single configuration file called opsroot.json and a whole section on how tags drive the builds is a strong hint about the design, and the fact that the guide covers the image publication path tells you the project produces container images as its main output.

The repository layout backs that up. There is a cli/ directory, an admin-api, oplugins and oplugins-op for the plugin side, a runtimes directory, a streamer, a testing directory, a dependencies directory and a build directory, plus scripts for the release process such as releasing.py, syncimages.py, sync-branch.sh and get-diff.sh. There is also a rebrander.md and a rebrander.py, which is a script for renaming things, and a no-release.txt file, which in an Apache repository is the marker that means this version is not going out as a release.

The governance documents are complete for an Apache project: CONTRIBUTING.md, DEVEL.md, RELEASE.md, VERIFY.md, ROADMAP.md, VERSIONS.md, CHANGES, a DISCLAIMER file and an Apache .asf.yaml file, which is the machine readable description the ASF uses to track the project.

What this project is not

It is worth being clear about what Apache OpenServerless is not, because the name invites the wrong comparison.

It is not a function runtime in the AWS Lambda sense. It does not give you an API to call, a trigger configuration, and a cold start measured in milliseconds. The repository is a build system and a control plane for building and operating serverless runtimes on a Kubernetes cluster, and its artefacts are images and configuration rather than a hosted endpoint.

The alternative, then, is a managed serverless platform. The difference in approach is that a managed platform owns the control plane, the runtime images, the scaling, the billing and the cold start behaviour, and you supply a function and a trigger. OpenServerless asks you to own a Kubernetes cluster and build and run it yourself, and what you get in return is control over the images, the runtime versions and the deployment pipeline, at the cost of everything the managed platform was doing for you.

The other alternative is building that runtime yourself on the cloud function engine you already run. Most managed platforms let you provide your own container image, which means you get most of the control without an operator, and the trade is that you are still inside that platform's trigger, scaling and permission model.

What OpenServerless offers is the layer in between, and it is a layer that only makes sense for an organisation that has decided it needs its own runtime supply chain. The incubating status, the opsroot.json configuration and the plugin directories all point the same way: this is infrastructure for people building serverless platforms rather than for people using one.

Editorial conclusion

Adopt Apache OpenServerless if you want to run your own serverless functions on a Kubernetes cluster you control, and you are prepared to follow an incubating project's conventions closely. Do not adopt it if you want a supported product or a managed service, because it is an Apache incubation effort with no GitHub releases, and the README warns that the main branch may contain unstable, untested or incomplete changes. Before you build it, clone with --recurse-submodules, since most of the code lives in submodules and a shallow clone fails in confusing ways, and use a release tarball rather than the branch if you intend to run it in production.

Frequently asked questions

Official sources

1. apache/openserverless on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README