# Apache OpenWhisk: A Self-Hosted Serverless Platform With a Pekko Migration in Its Path

> Apache OpenWhisk runs functions in Docker containers and composes them into workflows with triggers and rules. It is a full stack you operate yourself, and the master branch changed its actor framework in October 2025, which forces a redeploy.

**apache/openwhisk** — Apache OpenWhisk is an open source serverless cloud platform

- Repository: https://github.com/apache/openwhisk
- Website: https://openwhisk.apache.org/
- Stars: 6,798 · Forks: 1,177
- Language: Scala
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/apache-openwhisk

## What OpenWhisk Is and Who Ends Up Running It

OpenWhisk is a serverless functions platform for building cloud applications. The README describes it as offering a programming model for creating serverless APIs from functions, composing functions into serverless workflows, and connecting events to functions using rules and triggers. That last part is the real differentiator. A trigger is an event channel, a rule binds a trigger to an action, and a package groups related actions and feeds. You are not just uploading a handler; you are declaring an event topology.

The audience follows from that. OpenWhisk targets teams that want the FaaS model but not someone else's runtime: platform engineers building an internal function service, researchers who need to run functions on their own hardware, and organizations with data that cannot leave their network. The repository is mostly Scala, licensed Apache-2.0, and the deployment paths in the README assume you are comfortable with Gradle, Docker and, for the production route, Kubernetes. This is infrastructure software. Nobody adopts it to avoid operating infrastructure.

## How the Standalone Stack and the Kubernetes Deployment Differ

There are two documented ways in. The standalone stack runs a full-featured OpenWhisk as a Java process for convenience, with serverless functions running inside Docker containers. It needs Docker, Java and Node.js on the machine. When it is up, it opens a browser to a functions Playground, typically served from http://localhost:3233 for the API and http://localhost:3232 for the Playground. This is the path for evaluating the programming model.

The second path is a Kubernetes install, and the README points to a separate repository for it: apache/openwhisk-deploy-kube. It supports managed clusters such as AKS, EKS, IKS and GKE, plus Minikube and Kubernetes for Mac via Docker 18.06 or higher. The split matters because the deployment tooling is not in this repository. If your evaluation is really an evaluation of the Helm chart and controller, you are reading a different project's README.

The repository layout backs this up: core/, common/, ansible/, tools/, tests/, and a build.gradle at the top level. The system is built from a number of components, and the README's structure section points to docs/dev/modules.md for the breakdown. Expect a multi-service architecture, not a single binary you drop on a host.

## Installing OpenWhisk Standalone and Invoking Your First Action

The README's quick start is three commands. Clone the repository, change into it, and start the standalone stack with the Gradle wrapper. The first run pulls Docker images, so give it time.

```bash
git clone https://github.com/apache/openwhisk.git
cd openwhisk
./gradlew core:standalone:bootRun
```

When the stack is up, your browser opens the Playground, typically at http://localhost:3232. You can create and run functions there without installing anything else. For the full feature set you need the wsk command line tool, which the README says to download from https://s.apache.org/openwhisk-cli-download.

Point the CLI at the local stack with the credentials the README gives for standalone use. Copy this block exactly; the auth value is the documented standalone default.

```bash
wsk property set \
  --apihost 'http://localhost:3233' \
  --auth '23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP'
```

After that, wsk commands talk to the local API host. The README does not walk through creating an action in this file; it links to docs/actions.md, docs/triggers_rules.md and docs/packages.md for the concepts and commands. Read those before assuming the CLI surface resembles another FaaS vendor's.

The standalone deployment is also configurable: the README says additional capabilities can be deployed when desirable and points to core/standalone/README.md. That is where you go if the default stack is missing something you need.

## The Pekko Migration Breaks Existing Deployments

The most consequential thing in the README is a notice dated 10/17/2025. OpenWhisk migrated to the Apache Pekko framework. The master branch as of that date uses Pekko. The README states this results in a breaking change such that you must re-deploy new clusters and cutover traffic to the new cluster. It also states that if your deployments use Akka configuration overrides, you now need to update those to the Pekko equivalent. A 3.x release branch will eventually follow.

Read that carefully before planning an upgrade. This is not a library bump you absorb with a version pin. The documented path is a parallel deployment and a traffic cutover, which means double the infrastructure for the duration and a rollback plan that the README does not describe. The README is silent on rollback procedure. If you run OpenWhisk in production, the Pekko change should be treated as a migration project with its own test cycle, not a routine upgrade.

The release history reinforces the point. The latest listed release is 2.0.0 from 2024-04-07, preceded by 1.0.0 in November 2020. The master branch has moved past 2.0.0 into Pekko territory, but the README says the 3.x branch that would carry that change as a release will eventually follow. Until then, anyone tracking master is running ahead of the released artifacts.

## Where OpenWhisk Is the Wrong Choice

The operational surface is the first limitation. Standalone mode is a Java process plus Docker plus Node.js on one machine, which is fine for a laptop and not a production topology. The Kubernetes path puts a multi-component system on your cluster, and the deployment tooling lives in a separate repository with its own instructions. If your team has no appetite for running and upgrading a control plane, a managed function service will cost less in engineering time even if it costs more in dollars.

The second limitation is the upgrade model. A framework migration that requires new clusters and a traffic cutover is a real cost, and the README does not document a rollback. Teams that cannot absorb a parallel deployment should not be on master.

The third is fit. OpenWhisk's model is triggers, rules, packages and feeds. If your workload is one HTTP handler behind a load balancer, or a cron job that runs a script, the trigger and rule machinery is overhead you will configure once and never use. The same is true if your functions need long execution times or persistent local state; the README describes functions running within Docker containers, and container lifecycle is not something you control from the action code.

## OpenWhisk Against Lambda, OpenFaaS and Knative

The comparison people search for most is OpenWhisk versus Lambda, and the difference is ownership. Lambda is a managed service; you do not run a cluster or choose a framework version. OpenWhisk is software you deploy, so you inherit the Pekko migration, the Kubernetes install and the upgrade cadence. The trade is control: your functions run in your infrastructure, and the API, triggers and rules are yours to extend.

Against OpenFaaS, the split is the programming model. OpenFaaS centers on packaging functions as containers behind an HTTP gateway. OpenWhisk adds triggers, rules and packages as first-class objects, which is what makes event-driven composition possible without an external orchestrator. If you only want containers invoked over HTTP, OpenFaaS's model is closer to the metal; if you want to wire events to actions declaratively, OpenWhisk's abstractions are the point.

Against Knative, the difference is scope. Knative builds serving and eventing on top of Kubernetes primitives, so it inherits the cluster's scheduling and scaling model. OpenWhisk is its own system with its own controller and its own deployment repository. Knative fits teams already standardized on Kubernetes-native tooling; OpenWhisk fits teams that want the function platform to be a distinct layer they operate. None of these is a drop-in replacement for another, and the migration cost between them is mostly the cost of rewriting the event wiring.

## Maintenance, Licensing and What to Check Before You Commit

The repository is not archived, and the last push was on 2026-09-08. That is recent activity. It does not tell you what is in those commits, and the README's own notice suggests the branch is mid-migration. Judge the project by the release branch you intend to run, not by the default branch's commit date.

The licence is Apache-2.0, which is permissive and includes an explicit patent grant. The README carries the standard ASF header and the repository has LICENSE.txt and NOTICE.txt at the top level. For most adopters that is the end of the question; if you redistribute OpenWhisk or bundle it into a product, read NOTICE.txt and the files under licenses/ before you ship, since those carry the attribution requirements. That is a description of what is in the repository, not legal advice.

Upgrade cost is the part to price honestly. The Pekko change is documented as requiring new clusters and a traffic cutover. Beyond that, the README does not describe a supported upgrade procedure, and the deployment tooling is in a separate repository whose README you would need to consult. Before committing, verify three things: which release your deployment tooling targets, whether your configuration uses Akka overrides that must be rewritten in Pekko form, and whether your team can run two clusters during a cutover.

## Conclusion

Adopt OpenWhisk if you need a serverless control plane you own, with triggers, rules and packages as first-class objects, and you are ready to run the stack yourself. Skip it if you want a managed function service with no cluster to operate, or if you only need a single HTTP handler that a container already covers. Before deploying, read the Pekko notice, confirm which release branch your deployment tooling targets, and check whether your existing configuration uses Akka overrides that must be rewritten in Pekko form.

## FAQ

### What is Apache OpenWhisk?

It is an open source serverless functions platform for building cloud applications. It lets you create serverless APIs from functions, compose functions into workflows, and connect events to functions using rules and triggers.

### Is OpenWhisk dead?

The repository is not archived and the last push was on 2026-09-08. The latest listed release is 2.0.0 from 2024-04-07, and the README states a 3.x release branch will eventually follow the Pekko migration.

### How does OpenWhisk compare with AWS Lambda?

Lambda is a managed service where you do not run the cluster or choose the framework version. OpenWhisk is software you deploy yourself, so you inherit the Kubernetes install, the upgrade cadence and the Pekko migration, in exchange for running functions in your own infrastructure.

### What is the difference between Apache OpenWhisk and OpenFaaS?

OpenFaaS centers on packaging functions as containers behind an HTTP gateway. OpenWhisk adds triggers, rules and packages as first-class objects, which supports declarative event-driven composition without an external orchestrator.

### What is the difference between Apache OpenWhisk and Knative?

Knative builds serving and eventing on top of Kubernetes primitives, so it inherits the cluster's scheduling and scaling model. OpenWhisk is its own system with its own controller and a separate deployment repository, so it runs as a distinct layer you operate.

## Sources

- [apache/openwhisk on GitHub](https://github.com/apache/openwhisk)
- [License: Apache-2.0](https://github.com/apache/openwhisk/blob/master/LICENSE)
- [Project website](https://openwhisk.apache.org/)
- [README](https://github.com/apache/openwhisk/blob/master/README.md)
- [Releases](https://github.com/apache/openwhisk/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/apache-openwhisk