# OpenLambda is a serverless laboratory, and its papers are the output > OpenLambda is an Apache 2.0 licensed serverless computing platform written mostly in Go and based on Linux containers, whose stated goal is to enable exploration of new approaches to serverless computing, with a single node worker implemented so far and a cluster mode in progress. The repository also carries Rust for the WebAssembly worker and native function images, a directory of two dozen example workloads, and five academic papers that use it as a testbed. **open-lambda/open-lambda** — An open source serverless computing platform - Repository: https://github.com/open-lambda/open-lambda - Stars: 1,018 · Forks: 152 - Language: Go - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/open-lambda-open-lambda ## The goal is exploration, and the README says so first The README states the aim before it states the features. OpenLambda is an Apache-licensed serverless computing project, written mostly in Go and based on Linux containers, and the primary goal is to enable exploration of new approaches to serverless computing, with the hope to eventually make it suitable for use in production as well. That ordering is the honest summary of the project. It is a laboratory that happens to contain an implementation, and the implementation exists because you cannot explore a new approach to task provisioning without a system to provision tasks in. The audience is a researcher, a student or an engineer who wants to try an idea about how lambdas should be packaged or scheduled, and the counter-indication is that a system described in this way is not one to put in front of production traffic. ## The worker takes HTTP requests and runs lambdas locally The main system implemented so far is a single-node OpenLambda worker that can take HTTP requests and invoke lambdas locally to compute responses, and there is documentation for it in docs/worker/README.md plus a getting started page at docs/worker/getting-started.md for deploying a worker. The single-node scope is the important limitation and it is stated plainly rather than hidden behind a cluster diagram. A worker that serves HTTP and runs lambdas in Linux containers is enough to experiment with the things the project is interested in, which are the packaging and the startup cost of a lambda, not the distributed coordination. The related publications section confirms the direction, with papers on fitting zygote trees for faster package initialisation and on rapid task provisioning with serverless-optimised containers, both of which are questions about how a task starts rather than how a fleet is scheduled. ## The cluster mode is a boss over a pool of VMs The project is working on a cluster mode, where a pool of VMs running the worker service are managed by a centralized OpenLambda boss. The README is relaxed about the current state of that, noting that with a bit of work you could also manually deploy workers yourself and put an HTTP load balancer in front of them. That sentence is worth reading carefully, because it describes the two ways to use the system today, the cluster mode being the intended one and the manual deployment being the escape hatch for someone who wants a worker pool without the boss. The design is a central component that knows about the workers, and the papers on zygote trees and serverless-optimised containers are both about a boss-style system that prepares execution environments in advance and hands them to workers. ## Go, Rust and WebAssembly in the same repository The build is where the polyglot design shows. The Makefile builds several things: the ol binary, the ol-wasm image, the wasm-worker, the wasm-functions, the native-functions and the container-proxy. The wasm-worker is Rust, built with cargo in the wasm-worker directory and copied to ./ol-wasm, and the wasm-functions target builds the functions and runs install-wasm.sh to place test-registry.wasm, then checks that the hashing and noop modules exist. The native-functions target builds with cargo for a target triple that the Makefile detects from uname -m, mapping x86_64 to x86_64-unknown-linux-gnu and aarch64 to aarch64-unknown-linux-gnu, and erroring out on an unsupported architecture. There is a container-proxy component, a min-image/ directory with a Dockerfile and a spin.c and a Python runtime under min-image/runtimes/python, and an update-dependencies target that runs cargo update in the wasm-image, wasm-worker, bin-functions and container-proxy directories. The stack is Go for the control plane and Rust for the pieces where startup time and size matter. ## Two dozen examples that double as the workload catalogue The examples/ directory is the best single view of what the platform can do, and it reads like a benchmark suite. There is hello and hello2 for the trivial case, echo, and then the interesting ones. There are three install examples, install1, install2 and install3, which is how you would expect a project that cares about package initialisation to expose that as a test. There is lambda-config-test, timeout, max_mem_alloc and thread_counter, which are the resource and scheduling behaviours. Then there are the real applications: flask-test, flask-entry-test, fastapi-test, syslog, env-test, and a family of data workloads with pandas, pandas-v1, pandas-tests, numpy21, numpy22 and pip-compile. And three Kafka examples, kafka-basic, kafka-db-sum and kafka-metadata, which are the streaming path. A project with this many examples is not trying to look busy, it is trying to cover the space of what a lambda might be, because the research questions are about how those different shapes behave under the platform's packaging. ## Five papers, and what they were trying to do The related publications list is the clearest statement of what this project is for. Forklift, Fitting Zygote Trees for Faster Package Initialization, by Yang and others at WoSC '24, is about a shared tree of prepared environments so that a task does not have to install its packages from scratch. SOCK, Rapid Task Provisioning with Serverless-Optimized Containers, by Oakes and others at ATC '18, is about the same problem with containers, and the OpenLambda code is the implementation those papers were written against. Pipsqueak, Lean Lambdas with Large Libraries, by Oakes and others at ICDCSW '17, is about the awkward case of a small function that depends on a large library. And there are two earlier Serverless Computation with OpenLambda papers, one in ;login '16 and one at HotCloud '16, by Hendrickson and others, which are the introductions. A project whose output is five papers over eight years is a project whose success metric is not adoption, and that is worth knowing before you spend an afternoon on it. ## Where the project actually stands The release history is sparse in a way that tells you what to expect. There are two tagged releases, v0.1.0 titled First release! on 2016-06-19 and v0.1.1 on 2016-09-08, and nothing since, while the last push to the repository was on 2026-05-20 and the repository is not archived. So the code is being worked on, in the sense that commits and the continuous integration badge are live, but there is no versioned artefact with a 2026 date, and the version number has not moved past 0.1.1 in a decade. The licence is Apache 2.0, with a LICENSE.md at the root, which is the permissive choice and the right one for a research platform that you might want to build on. The repository layout supports the picture, with go/ for the Go sources, bin-functions/ for the Rust function binaries, wasm-worker/ and wasm-image/ for the WebAssembly side, container-proxy/, min-image/ for the minimal container image, python/ for the Python runtime, benchmarks/, experiments/, scripts/, stacks.py, autocomplete/, docs/ and the examples/ catalogue. For a reader who wants to understand serverless internals, that is a well-organised tree. For a reader who wants a serverless platform to run, it is not that. ## Conclusion OpenLambda is worth reading as a research artefact rather than as something to deploy, because the five papers that use it show how a serverless system is built and measured when the measurements are the point, and the example workloads make it possible to reproduce those experiments. It is the wrong tool for production, and the project says so, since the goal is to enable exploration and only eventually to be suitable for use in production as well, and the only tagged releases are v0.1.0 and v0.1.1 from 2016. Before you build on it, read the worker documentation and the getting started page, and look at the examples directory, since the fastest way to understand the platform is to run one of the existing workloads and read the paper that measured it. ## FAQ ### What is OpenLambda? It is an Apache 2.0 licensed serverless computing project written mostly in Go and based on Linux containers. The stated primary goal is to enable exploration of new approaches to serverless computing, with the hope to eventually make it suitable for production use as well. ### What can OpenLambda actually run today? The main system implemented so far is a single-node OpenLambda worker that takes HTTP requests and invokes lambdas locally to compute responses. A cluster mode is in progress, where a pool of VMs running the worker service are managed by a centralized OpenLambda boss, and you can also deploy workers manually behind an HTTP load balancer. ### Which languages and runtimes does OpenLambda support? The control plane is Go, the WebAssembly worker and the native function images are built with cargo, and the minimal image carries a Python runtime. The Makefile builds the ol binary, the ol-wasm image, the wasm-worker, the wasm-functions, the native-functions and the container-proxy, and it detects the Rust target triple from uname -m. ### What is the state of the OpenLambda releases? There are two tagged releases, v0.1.0 on 2016-06-19 and v0.1.1 on 2016-09-08, and the last push to the repository was on 2026-05-20. The project is not archived and the CI badge is live, so the tree is being worked on even though no versioned artefact has been published in a decade. ## Sources - [Issues](https://github.com/open-lambda/open-lambda/issues) - [License: Apache-2.0](https://github.com/open-lambda/open-lambda/blob/main/LICENSE) - [open-lambda/open-lambda on GitHub](https://github.com/open-lambda/open-lambda) - [README](https://github.com/open-lambda/open-lambda/blob/main/README.md) - [Releases](https://github.com/open-lambda/open-lambda/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/open-lambda-open-lambda