RunR vs OpenFaaS
RunR is an open-source (MIT) serverless platform: functions, multi-file projects and containers on Knative, on Kubernetes clusters you operate. OpenFaaS runs functions packaged as container images on Kubernetes, or on a single host with faasd, in a Community Edition (CE) and the commercial Standard and Enterprise editions.
Both are self-hosted and deploy functions from templates or images. RunR has one edition under the MIT license; OpenFaaS splits its features between CE and the commercial editions.
Differences at a glance#
| RunR | OpenFaaS | |
|---|---|---|
| License and editions | MIT; every feature in one repository (License) | CE under an EULA that limits commercial use to one installation per company for up to 60 days, with up to 15 functions; Standard and Enterprise are commercial (CE EULA, editions) |
| Where it runs | Your Kubernetes clusters (1.30 or newer); the control plane on Kubernetes with Helm or on one host with Docker Compose (Regions, Single-host install) | Kubernetes, or a single host without Kubernetes with faasd (faasd, OpenFaaS Edge) |
| Scale to zero | On by default for every project (Scaling) | Standard and Enterprise (scale to zero) |
| From source | Web editor, git push or the CLI; images are built in the cluster with Kaniko (Git deploy, CLI) |
faas-cli build builds images from templates with local Docker; the Function Builder API is in Enterprise (build, Function Builder) |
| Events | HTTP, schedules, queues, webhooks, topics, Kafka, NATS, RabbitMQ, MQTT, Postgres CDC, S3 and IMAP, with retries and dead letters (Triggers) | Cron in CE; Kafka, RabbitMQ, Postgres, AWS SQS and SNS and Google Pub/Sub connectors in Standard and Enterprise (triggers, editions) |
| Asynchronous calls | Queue and topic triggers through the event gateway (Triggers) | A JetStream queue-worker in Standard and Enterprise; CE keeps an in-memory queue (async, editions) |
| Isolation | runc, gVisor or Kata Containers per project type, installed per region from the console (Kata Containers hypervisors) | A runtimeClass such as gVisor through Profiles, in Enterprise (Profiles) |
| GPUs | GPU functions and containers; Hugging Face model services (GPU workers, Hugging Face models) | GPUs through Profiles in Standard and Enterprise (editions) |
| Console and teams | A web console; organizations, tenants, roles and single sign-on (Roles and permissions, Modules) | A dashboard in Standard and Enterprise (CE: the legacy UI); SSO with OIDC, IAM and several namespaces in Enterprise (editions) |
| Configuration as code | runr.yaml and the runr CLI, the Terraform / OpenTofu provider brf-tech/runr (CLI, Terraform provider) |
A stack file (stack.yaml) and faas-cli (stack file) |
When to choose which#
OpenFaaS fits when you want functions on a single host without Kubernetes (faasd), or when its commercial editions and their support match what you need.
RunR fits when you want every feature — scale to zero, event sources, sandboxing, GPUs, single sign-on — under the MIT license without an edition boundary, and when functions should sit next to multi-file projects, containers, durable workflows and the Sandbox API on one platform (Durable workflows, Sandbox API).
RunR documentation to read next#
The statements about OpenFaaS come from the OpenFaaS documentation and repositories, read on 2026-11-03 and linked next to each one. OpenFaaS is a trademark of OpenFaaS Ltd. RunR is not affiliated with or endorsed by OpenFaaS Ltd.