Open source · MIT · Knative

RunR

An open-source, self-hosted serverless platform on Kubernetes and Knative.

Functions, multi-file projects, containers and WebAssembly on Knative — on your own Kubernetes clusters, with a Sandbox API, durable workflows, GPUs and MCP built in. No per-request fees. No lock-in.

Quick start GitHub
0+
BUILT-IN RUNTIMES
0
SANDBOX RUNTIMES
0
BINDING TYPES
0
IDLE PODS · SCALE-TO-ZERO
MIT
OPEN SOURCE
The RunR console: the Projects list of an organization with the type, runtime, region, status and last deployment of every project

The RunR console: the projects of an organization, with type, runtime, region, status and last deployment.

THREE PROJECT TYPES

From a single file to a full container.

One platform, three deployment models — all scaling to zero on Knative. Deploy from the web editor, with git push or from the CLI; trigger by HTTP, schedule, queue or workflow.

X

XaaS

One file, one function. Write or paste code in the web editor and hit deploy.

Python Node.js Go PHP Wasm + plugins
  • Scale-to-Zero · Knative
  • Triggers: HTTP · schedule · queue · workflow
  • Sandbox: runc · gVisor · Kata
  • Version history + rollback
F

FaaS

Multi-file projects — in the web IDE or from your own git repository. Every save and every push is a version in the project's git repository; dependencies are built in-cluster.

Python Node.js Go PHP PyTorch TensorFlow Wasm
  • Scale-to-Zero · Knative
  • git push · GitHub · GitLab · Forgejo / Gitea
  • A preview environment per pull request
  • Dependencies built with Kaniko
C

CaaS

Any container image: from a registry, from an uploaded docker save archive or as a GPU workload. Optional Kata micro-VM isolation.

OCI Docker Any Lang GPU Cron Queue
  • Scale-to-Zero · Knative
  • Kata + Cloud Hypervisor (recommended)
  • GPU: count · product · minimum memory
  • Zot pull-through cache
The web editor of a single-file function in the RunR console, with the Deploy button and the version history

The web editor

Write a single-file function in the browser. Deploy ships that version to Knative; the history keeps every one, ready to roll back.

The Overview tab of a project: URL, status, the latest versions, and the requests and errors of the last hours

A project at a glance

URL, status, the latest versions, requests and errors of the last hours, and the tabs for code, deployments, triggers, environments, logs and metrics.

IN ONE INSTALL

More than deploy — a complete platform.

Deploy, events, environments, data, networking, access control, supply chain, observability, multi-tenancy and billing calculation — all in the same open-source install. Not a single feature behind a paywall.

D

Deploy

git · CLI · Terraform · GitHub Action · GitLab CI/CD

Every project has its own git remote: push, and it deploys. GitHub App, GitLab and Forgejo / Gitea connections come with commit statuses and a deploy history.

  • A preview environment per pull / merge request, removed on close
  • runr CLI: init · dev · deploy and commands for every feature
  • The brf-tech/runr provider on the Terraform Registry, a GitHub Action and a GitLab CI/CD job
  • Image uploads: docker save, OCI tars, .wasm — also for regions without internet
E

Triggers + Events

Webhooks · Topics · Kafka · NATS · CDC

Every project has a list of triggers: HTTP, schedules in a time zone, queues, a webhook inbox, fan-out topics and platform events. The project's event gateway delivers each event as a CloudEvent, with retries and dead letters.

  • Broker and external sources: Kafka, NATS JetStream, RabbitMQ, MQTT, Postgres CDC, S3 and e-mail over IMAP
  • An event is acknowledged only once it is delivered or dead-lettered
  • Webhook signature presets and a generic HMAC; stored events can be replayed
  • Credentials are write-only trigger secrets
P

Environments + Rollouts

dev · staging · prod · blue-green · canary

A project runs in several environments, each with its own URL, configuration overrides, secrets, bindings and region. Promotion moves the same image to the next environment after a preview of what changes; promotions into production wait for approval.

  • A git branch per environment: a push deploys it
  • Blue-green and canary rollouts with test URLs and health checks
  • A canary rolls back by itself when the new revision's error rate or p95 latency crosses its threshold
  • Timed warmer: containers kept warm on a weekly schedule
  • Rollback with the configuration a version ran with
N

Network + Global

Internal network · Global DNS · API keys

Projects of a region call each other by name on an internal network, admitted only by the callee's allow list. A project is public, public to an IP allow list, or internal only.

  • Global projects: one host name across several regions, HA or proximity mode, failover
  • A dedicated Postgres binding of a global project replicated to every region; switchover without data loss
  • API product: consumers, API keys, JWT routes, rate-limit plans and measured usage
  • cert-manager set up in every region for custom-domain certificates
B

Data + Workflows

KV · S3 · Postgres · Workflows

Bindings attached to projects: managed KV (Redis), object storage (Garage or an external S3) and Postgres (CloudNativePG). Credentials arrive as environment variables, with rotation, retention and restore.

  • Durable workflows resume after crashes, redeploys and sleeps of days
  • Steps, retries, timers, events, child workflows
  • Python (runr-workflows) and TypeScript (@runr/workflows) SDKs
  • Per-organization quotas and usage metering
  • Organization export and import: one versioned file — another installation or disaster recovery
R

Access + Security

RBAC · SSO · Secrets · Audit

One permission catalog: built-in and custom roles, groups, per-project access and API tokens limited to a subset of their owner's permissions. SSO groups map to RunR groups and roles.

  • SSO: Google, GitHub, Microsoft, GitLab, OIDC, SAML 2.0
  • Every stored secret encrypted at rest, with key rotation
  • Secret variable values live in the region (Kubernetes Secret or OpenBao), not in RunR's database, or are read from your own secret store: HashiCorp Vault / OpenBao, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault
  • Signed runtime patch feed: the level, reason and CVEs of every runtime patch, and a deadline for critical ones
  • Append-only audit log: CSV / JSON export, SIEM forwarding
S

Supply Chain + Residency

SBOM · Scan · Sign · Admission

Every image RunR builds or receives gets an SBOM (SPDX, CycloneDX), a vulnerability scan (also with an offline database) and a cosign signature with the region's key.

  • A policy gate before deploy
  • Signed-image admission in the region, re-scans of deployed images
  • WebAssembly apps are signed and verified too
  • Data residency: organizations limited to allowed regions and data locations
O

Observability

OpenTelemetry · Tempo · Prometheus · Loki

An OpenTelemetry Collector and Grafana Tempo per region (or your existing backend), auto-instrumented functions and a Traces tab with search and waterfall; metrics and logs per project.

  • Request replay: re-run a captured failed request, diff the response
  • Uptime checks run by the region agent
  • A public status page per organization
  • Alert channels and rules
  • k6 load tests from inside the region: p50 / p95 / p99 latency, errors, pods and cold starts
  • Rightsizing: size recommendations from what the pods really used, applied with one click
T

Multi-Tenant + White-Label + Billing

Tenancy · Branding · Billing API

A PostgreSQL schema per tenant, quotas per region. The brand of the installation and of each tenant without a rebuild; self-service signup with e-mail verification.

  • Billing module, with or without tenancy: a monthly bill per project, pay-as-you-go or fixed-resource regions
  • Tenants resell the regions the platform shares with them to their own projects, with a markup
  • Your own billing system invoices: billing API + signed webhooks
  • A monthly cost limit per project: notify or stop
  • Support tickets with attachments, assignment and real-time updates
  • Single-tenant or multi-tenant edition
THE CONSOLE

Everything 0.6 added, as it looks in the console.

Scenes from a RunR 0.6 installation. Each one is a feature of the same open-source install; the documentation page of every feature is linked.

Deploy strategies

Blue-green and canary, with an automatic brake.

Pick a strategy per function. Blue-green starts the new revision next to the serving one, with 0 % of the traffic and a test URL of its own, then moves all traffic at once: by hand, or by itself once the health check passes. Canary raises the new revision's share in steps (10 % → 50 % → 100 % by default); when its error rate or p95 latency crosses the threshold during a step, the rollout rolls back on its own.

  • The previous revision stays warm: a rollback is instant
  • Thresholds per function: error rate, p95 latency, time per step
  • The same settings in the console, the CLI and the Terraform provider
Deploy strategies →
Deploy strategy settings of a function: canary steps, the interval per step and the error-rate and p95 thresholds that roll the release back automatically
Environments and promotion

dev, staging, production: one project, promoted step by step.

A project runs in several environments, each with its own URL, configuration overrides, secret variables, bindings, custom domains, git branch and region. Promotion moves the same code version and image to the next environment, never built again, with the target's own configuration; a preview shows what will change, and promotions into production wait for an approver by default.

  • A git branch per environment: a push deploys that environment
  • Preview environments per pull request stay separate and are removed on close
  • Rollback with the configuration a version ran with
Environments →
The Environments tab of a project: dev, staging and production with their URLs and versions, and a promotion into production waiting for approval
Global projects

One host name, several regions, failover included.

A global project runs in several regions behind one host name. In HA mode the primary region answers while it is healthy and the others take over when it is not; in proximity mode the healthy region closest to the client answers. When the primary fails, RunR fails over to the next healthy region: the Postgres replica there is promoted, and the triggers and the DNS follow.

  • Dedicated Postgres bindings replicated to every region; switchover without data loss
  • Health checks per region; switchover by hand or through failover
  • Managed KV, object storage and shared Postgres stay in their region
Global projects →
A global project across regions: HA mode, the health of every region, the primary region and the DNS records of the host name
Triggers and the event gateway

Every event a project reacts to, in one list.

HTTP, schedules in a time zone, queues, a webhook inbox with signature presets, fan-out topics, platform events, and brokers and external sources: Kafka, NATS JetStream, RabbitMQ, MQTT, Postgres change data capture, S3 buckets and e-mail over IMAP. The project's event gateway delivers each event as a CloudEvent with retries and a dead letter; a message is acknowledged only once it is delivered or dead-lettered.

  • Credentials are write-only trigger secrets
  • Stored events can be replayed; a generic HMAC covers any webhook
  • Delivery state, retries and the dead letter, visible per trigger
Triggers →
The Triggers list of a project: HTTP, schedule, queue, webhook, Kafka and Postgres CDC triggers with their delivery state
Durable workflows

Functions that outlive crashes, redeploys and sleeps of days.

A workflow is an ordinary function in a project, written step by step. Every step's result is recorded, so a run continues where it left off after a crash or a redeploy; a workflow can sleep for ten minutes or ten days, wait for an event, retry a failing step and call other workflows. The console shows every run with its steps and timings.

  • Python (runr-workflows) and TypeScript (@runr/workflows) SDKs
  • A language-neutral protocol: any runtime can implement it
  • Per-organization quotas and usage metering
Durable workflows →
A durable workflow run in the console: its steps, sleeps and awaited events with their timings
Supply chain and secret stores

Know every image you run; keep secrets out of the database.

Every image RunR builds or receives gets an SBOM (SPDX and CycloneDX, attached as OCI referrers), a vulnerability scan that also works with an offline database, and a cosign signature with the region's key. A policy gate decides before deploy, and the region admits only signed images. Secret variables never land in RunR's database: they live in the region's Kubernetes Secrets or in an OpenBao RunR runs there, or stay in your own HashiCorp Vault / OpenBao, AWS Secrets Manager, GCP Secret Manager or Azure Key Vault, read with the region's identity.

  • Signed runtime patch feed: the level, reason and CVEs of every patch, deadlines for critical and zero-day ones
  • Dynamic Postgres credentials: short-lived database users from the region's OpenBao
  • Append-only audit log with export and SIEM forwarding
Supply chain → Secret stores →
The supply chain of an image: its SBOM, the result of the vulnerability scan, the cosign signature and the verdict of the policy gate

More of the console

A deployment in progress in the RunR console: the build and rollout steps streaming live with their durations

A deployment, live

Build and rollout steps stream into the console as they happen; every change is a version you can roll back.

The Logs and Metrics tabs of a project: live log lines next to request, latency and replica charts

Logs and metrics per project

Live log lines next to request, latency and replica charts; traces with a waterfall in the Traces tab, request replay for failed calls.

Roles and permissions in the RunR console: built-in and custom roles against the permission catalog

Roles and permissions

One permission catalog, built-in and custom roles, groups, per-project access and API tokens scoped to a subset of their owner's permissions.

The region wizard: a kubeconfig is checked and Knative Serving, Traefik, the registry and the observability stack are installed step by step

Add a region

Paste a kubeconfig. RunR installs Knative Serving, Traefik, the Zot registry, Redis, Prometheus, Loki and its region agent on the cluster, and keeps them current.

SOURCE TO POD

Source code to pod. No container required.

Write the handler, not the Dockerfile. RunR takes your source — a single file or a whole project, from the web editor, git push or the CLI — installs its dependencies, compiles Go, builds the image inside your cluster with Kaniko and hands it to Knative.

THE CONTAINER ROUTE

The classic container workflow

Every change: build an image, push it, roll it out.

1Write code
2Write Dockerfile
3docker build (minutes)
4Push to a registry
5Write Deployment / Service / Ingress YAML
6Roll out + tune autoscaling
⏱ Minutes / change
VS
RunR

Paste code → Deploy

RunR installs dependencies, compiles Go, builds the image in-cluster with Kaniko and ships it to Knative.

1Write code in the web editor or git push — every change is a version
2Hit deploy, run runr deploy or let the push deploy

Behind the scenes: dependency install or Go compile → Kaniko build as a Kubernetes Job (linux/amd64) → push to the region's registry → Knative revision. Code without dependencies skips the build and goes live straight from a ConfigMap.

⚡ ~3 s (no dependencies) · ~23 s (with a build) / change

RunR measurement: v0.4.2, single-node k3s (8 vCPU, 16 GB); median from save until the new code answers (n=3). No dependencies 2.7 s (2.7–3.7 s); with a build 23.0 s (22.0–25.0 s; Kaniko, Node + 1 npm dependency, base images from the region registry cache). A project's first-ever build adds a one-time base-image fetch.

Built-in runtimes

Python Node.js Go PHP PyTorch TensorFlow

Runtime images track upstream: every version that hasn't reached end-of-life is available, and each project picks its own.

Any language: runtime plugins

C Rust Bash Q your language

A runtime is a runtime.yaml manifest plus an image. The universal wrapper (runr-wrapper) turns HTTP requests, queue messages and schedule ticks into invocations over stdin / stdout, in http, exec or persistent mode. Platform administrators and organizations register their own runtimes; runr dev runs them locally on the same images.

WebAssembly (Spin)

Rust Go (TinyGo) JavaScript / TypeScript Python wasm-exec: C / C++ · Zig · .wasm

Wasm functions run as Spin components on runwasi's Spin shim, installed per region in one click from its Isolation tab. wasm-exec runs any WASI command on Spin's WAGI executor.

⚡ From zero to first response: Rust 1.54 s · JavaScript 2.12 s

RunR measurement: v0.5.0, 2026-10-15, single-node k3s v1.34.11 on a test VM (8 vCPU Broadwell, nested KVM, 15.6 GiB), Knative 1.21.3; Spin shim, 250m / 128 MiB, image on the node, RunR's default scale-to-zero; HTTPS from inside the VM through Traefik, a new connection per request; median (p90) from zero replicas to the first full HTTPS response, n=12 each: Rust 1.54 s (1.84), JavaScript 2.12 s (2.58); warm request median 9 / 11 ms (n=100).

AI · ON YOUR OWN CLUSTER

Infrastructure for GPUs, models and agents.

RunR detects GPU nodes, serves Hugging Face models in one click, gives AI agents permission-scoped access over MCP and runs the code they write in isolated sandboxes.

G

GPU Workers

NVIDIA device plugin · GPU Operator

Detects the NVIDIA GPU nodes of a region, installs the device plugin or the GPU Operator and schedules GPU functions and containers there — scaling to zero, metered by GPU time.

  • config.gpu: count · product · minimum GPU memory
  • GPU Feature Discovery, optional time-slicing
  • Under runc or gVisor (nvproxy)
  • PyTorch and TensorFlow runtimes, with CPU and CUDA images
  • GPU quota per tenant
H

Hugging Face Models

vLLM · TGI · TEI · hf-serve

One-click model services from a Hub browser — vLLM, TGI, TEI, RunR's hf-serve or your own image — online or fully offline.

  • Offline copies in the region's model volume
  • Chunked uploads and imports for air-gapped regions
  • A playground in the console
  • Model bindings: RUNR_MODEL_<ALIAS>_* variables in any language
M

MCP Server + MCP Hosting

Model Context Protocol · OAuth 2.1

A built-in MCP server at /mcp: agents such as Claude Code operate RunR within their token's permissions, and every call is audited. MCP clients connect with an API token or one-click OAuth 2.1.

  • Your own MCP servers run as projects behind a gateway
  • Access: public, RunR token or OAuth
  • A signed caller identity, a call log and an inspector
  • Python and TypeScript starter runtimes
S

Sandbox API

gVisor · Kata · warm pools · SDKs

Isolated, short-lived sandboxes for the code AI agents write: under the region's strongest isolation (a Kata micro-VM on nodes with KVM, otherwise gVisor), without network access by default, with their own CPU, memory and disk limits.

  • Exec as JSON, Server-Sent Events or WebSocket, also on a terminal (TTY); files, background processes
  • A code interpreter, a console terminal and runr sandbox exec -it
  • Warm pools, pause / resume, TTL, quotas and usage metering
  • Python (runr-sandbox) and TypeScript (@runr/sandbox) SDKs
⚡ Create to first command: 0.28–0.36 s from a warm pool · 2.0–4.0 s cold
The Hugging Face Hub browser in the RunR console, with a model service being deployed to a GPU region

Hugging Face models

Browse the Hub in the console and deploy a model service with vLLM, TGI, TEI or hf-serve, online or fully offline, then try it in the playground.

MCP in the RunR console: the built-in MCP server endpoint, connected clients and a hosted MCP server behind the gateway with its call log

MCP server and MCP hosting

The built-in MCP server at /mcp for agents, and your own MCP servers hosted behind the gateway with public, token or OAuth access, a call log and an inspector.

The Sandbox API page: running sandboxes with their class (gVisor or Kata), the warm pool and the quota of the organization

Sandbox API

Running sandboxes with their class (gVisor or Kata), warm pools and quotas; exec, files, background processes and a code interpreter over the API and the SDKs.

RunR measurement: v0.5.0, 2026-10-15, single-node k3s v1.34.11 on a test VM (8 vCPU Broadwell, nested KVM, 15.6 GiB), Knative 1.21.3, gVisor 20260921.0, Kata Containers 3.28.0; Sandbox API (POST /api/sandboxes, called from inside the VM), Python 3.14, 500m / 512 MiB, image on the node; timed until the first command returns, median (p90), n=10 per class — cold: gVisor 2.01 s (3.79), Kata Firecracker 2.99 s (4.00), Kata Cloud Hypervisor 4.01 s (4.07); from a warm pool of 2: Kata Firecracker 0.28 s (0.30), Kata Cloud Hypervisor 0.34 s (0.61), gVisor 0.36 s (0.40). A command in a running sandbox: 0.16–0.22 s.

WHY RUNR

Serverless experience — on your own metal.

Cloud-provider ergonomics, with the freedom of open source.

⚡

100% Open Source

All code under the MIT license. Self-host, fork, modify. Nothing is locked behind a paywall.

MIT license · BRF Teknoloji
📉

Scale-to-Zero

Knative-powered: idle pods scale to zero. Replicas reach zero ~60 s after the last request and the pod is gone by ~93 s (RunR v0.4.2 measurement; Knative defaults: 60 s stable window + 30 s grace period). Idle functions hold no resources; the capacity is freed for other workloads.

A region admits scale-to-zero projects against an overcommit budget — by default 3× its CPU and 1.5× its memory, set per region — while always-on projects reserve their full size.

🏢

Multi-Tenant + RBAC

Schema-per-tenant isolation and quotas per region; built-in and custom roles, groups, SSO group mapping and scoped API tokens.

🛡️

Sandbox Isolation

Chosen per project type in each region: gVisor for syscall-level isolation, Kata Containers micro-VMs (Cloud Hypervisor, QEMU, Dragonball, Firecracker; on nodes with hardware virtualization) or plain runc.

🔓

Zero Vendor Lock-in

Standard Knative APIs, OCI images and MIT-licensed code. Your workloads move to any Kubernetes that runs Knative, and the platform itself is yours too.

🌍

On Your Own Clusters

Install the platform with its Helm chart or with Docker Compose on a single host (air-gapped too), then add as many Kubernetes clusters as you like as regions with their kubeconfig — in the console or with runr regions create.

SANDBOX & RUNTIME ISOLATION

When you need to change what's beneath the container.

Each region maps XaaS, FaaS, CaaS and build jobs to a container runtime of their own via RuntimeClass: runc by default, gVisor or Kata once installed. gVisor intercepts syscalls, Kata runs each pod in its own micro-VM, and Firecracker (the same Lambda uses) is the most minimal micro-VM of them. The same isolation protects the sandboxes of the Sandbox API.

gVisor SYSCALL

Google · User-space kernel · runsc shim

Cold start · Python
2.0 s
Mem overhead
Low (no VM)
Isolation
OS
Use
XaaS · FaaS
  • Syscall interception (270+ filtered)
  • Hardened against container escapes
  • Far smaller host-kernel attack surface
  • One-click install (installer DaemonSet)

Kata + CLH VM

Kata Containers · Cloud Hypervisor · kata-clh shim

Cold start · Python
3.1 s
Mem overhead (0.4.2)
~130–150 MiB
Isolation
Hardware
Use
CaaS · Build
  • Each pod gets its own micro-VM, booted straight into the Kata agent (no guest systemd)
  • Cloud Hypervisor (Rust-based, lightweight)
  • Hardware virtualization (Intel VT-x / AMD-V)
  • Gold standard for untrusted code

Firecracker μVM

AWS · Rust · firecracker-containerd

Cold start · Python
3.2 s
Mem overhead (0.4.3)
~145–155 MiB
Isolation
Hardware
Use
High-throughput
  • The engine behind AWS Lambda
  • Minimal device emulation (small binary)
  • Designed for high packing density
  • Root filesystem on containerd's devmapper snapshotter
  • Optional — via Kata FC variant

RunR measurement: v0.5.0, 2026-10-15, single-node k3s v1.34.11 on a test VM (8 vCPU Broadwell, nested KVM, 15.6 GiB), Knative 1.21.3, gVisor 20260921.0, Kata Containers 3.28.0; function 250m CPU / 256 MiB, image on the node, RunR's default scale-to-zero; HTTPS from inside the VM through Traefik, a new connection per request; median (p90) from zero replicas to the first full HTTPS response, n=12 each, Python — runc 1.50 s (2.14); gVisor 1.97 s (2.64); Kata Cloud Hypervisor 3.11 s (3.25), Firecracker 3.21 s (3.47; root filesystem on containerd's devmapper snapshotter), QEMU 3.89 s (4.45), Dragonball 3.95 s (4.04). Kata was measured with Python only. Warm request median 9–12 ms (n=100). Memory overhead was measured with earlier releases on the same test VM: ~130–150 MiB for Cloud Hypervisor (RunR v0.4.2) and ~145–155 MiB for Firecracker (RunR v0.4.3), the host PSS of shim + VMM (+ virtiofsd with Cloud Hypervisor) per idle Kata pod, minus the function's own memory in the guest.

⚙️

Containerd shim selection — per project type

Each region maps XaaS, FaaS, CaaS and build jobs to a runtime of their own — runc by default, gVisor or any Kata hypervisor as soon as it is installed. On deploy the Knative manifest gets the matching runtimeClassName (gvisor, kata-clh, kata-qemu, kata-dragonball, kata-fc) automatically; WebAssembly functions run on the Spin shim with wasmtime-spin-v2.

🔧

Cilium sandbox network fix — solved in-platform

Sandbox pods can't reach ClusterIP services from the host-net namespace by default (Cilium upstream bug). RunR auto-applies bpf-lb-sock-hostns-only: true on the cluster — non-disruptively, on a running cluster.

TECHNICAL ARCHITECTURE

Not a single box — a 12-layer platform.

The control plane — Vue SPA, Laravel API on Octane, queue workers, scheduler and WebSocket server, behind one gateway — ships as a Helm chart or a single-host Compose install. RunR then installs Knative Serving, Traefik, the Zot registry, sandboxes, the Spin shim, GPU support, data services and the observability stack on every region cluster for you.

User Browser · CLI · MCP Vue 3 + Vite 100+ component · 30+ composable 7 store · driver.js tour Tailwind · Monaco · xterm.js · i18n runr-ui Laravel 12 API · PHP 8.3 110+ Controller · 70+ Service 70+ Job · 100+ Model · 90+ Trait Sanctum · Scramble · ETag · RBAC MCP · git HTTP · OAuth 2.1 runr-api · Octane (FrankenPHP) REST + WS Horizon Queue · Build · Deploy Reverb WebSocket · Shell PTY PostgreSQL 17 Central + Tenant schemas Redis 7 Queue · Cache · WS broker Region · any Kubernetes cluster · add-ons via Helm kubeconfig Knative Serving Scale-to-zero · Revision matched to K8s XaaS · FaaS · CaaS pods Sandbox runc · gVisor (runsc) Kata · Spin (Wasm) RuntimeClass per type Traefik + Cilium Ingress · L7 LB bpf-lb-sock-hostns eBPF dataplane Zot Registry OCI · pull-through S3 / PVC / External Build artifacts Observability Metrics + Logs Prometheus + cAdvisor Loki + Promtail Traces OpenTelemetry + Tempo replay · uptime · alerts Region Agent Go · one per region metrics · sessions · events Usage + Billing UsageAggregationJob Billing API · webhooks Tenancy Modules/ Tenancy AuthProvider Ticket Billing Frontend plugin.js Tenant switcher Billing pages *_ENABLED flags
01

Frontend

Vue 3 · Vite · runr-ui
100+ component30+ composablePiniaMonacoxterm.jsi18n EN · TR
02

Backend API

Laravel 12 · PHP 8.3 · Octane (FrankenPHP)
110+ controller70+ service100+ modelSanctumHorizonScramble
03

Real-Time

Reverb WebSocket · runr-reverb
Private channelsShell PTYNotificationsLive metrics
04

Kubernetes

K8s 1.30+ · Helm
HelmHPAPDBRBACMulti-cluster
05

Knative Serving

Matched to K8s · auto-scale
Scale-to-zeroRevisionsMin / max scaleKPACapacity admission
06

Sandbox

RuntimeClass per project type
runcgVisorKata: CLH · QEMU · Dragonball · FCSpin (Wasm)
07

Network

Traefik Gateway · Cilium
L7 ingresseBPF dataplaneAPI gatewaySubdomain routing
08

Registry

Zot · OCI compliant
Pull-through cacheS3 / PVCNode pre-pullImage uploads
09

Observability

OpenTelemetry · Tempo · Prometheus · Loki
TracesReplayUptimeStatus pageAlertsRegion agent
10

Tenancy

stancl/tenancy v3 + Modules v11
Schema-per-tenantResource syncImpersonationWhite-label
11

Supply Chain

SBOM · scan · cosign · admission
SPDX · CycloneDXOffline scan DBPolicy gateSigned admission
12

Migration & DR

Region cutover · DNS flip
Region migrateDNS cutoverAuto redeployRollback
0+
Components
0+
Controllers
0+
Services
0+
Models
0+
Composables
0+
Queued Jobs
HOW IT WORKS

Four steps, live in production.

1

Write

Write code in the web editor, git push or start with runr init — pick a runtime, RunR handles the rest.

2

Deploy

Every change is a version, built automatically when needed. One click, a push or runr deploy puts that version live on Knative.

3

Scale

Auto scale-to-zero and scale-out. Reacts to traffic in seconds.

4

Monitor

Live logs, metrics, traces and cost tracking. Prometheus, Loki and OpenTelemetry built in.

COMPARISON

RunR next to the alternatives.

Bare Knative, Knative Functions, OpenFaaS, AWS Lambda and Vercel, feature by feature, from their own documentation.

FEATURE RunR Knative (bare) Knative Functions OpenFaaS AWS Lambda Vercel
License MIT, every feature Apache-2.0 (CNCF) Apache-2.0 CE: EULA, commercial use one installation per company for up to 60 days · Standard / Enterprise paid Proprietary Proprietary
Where it runs Your Kubernetes clusters: bare metal, private or managed, air-gapped too Your Kubernetes cluster Your Knative cluster Your Kubernetes cluster, or one host with faasd AWS only Vercel's cloud only
Console Web console: editor, logs, metrics, traces, shell, every setting kn CLI and YAML func CLI Dashboard in Standard / Enterprise AWS Console Dashboard
From source, no Dockerfile Web editor, git push or CLI; built in-cluster with Kaniko Container images only func build: Node.js, Python, Go, Quarkus, Rust, Spring Boot, TypeScript templates faas-cli build with templates (local Docker); builder API in Enterprise Zip for managed runtimes, or a container image Framework builds from git
Container images Any OCI image (CaaS); uploads for air-gapped regions Yes Functions build to images Yes (functions are images) Yes, up to 10 GB Container runtime for functions (beta); Daemons (beta)
WebAssembly Spin shim: Rust, TinyGo, JS / TS, Python; wasm-exec for any WASI command With a Wasm RuntimeClass you set up — — — Edge runtime: Wasm modules
Scale to zero Yes (Knative) · measured cold start 1.5–1.7 s (runc), 2.0 s (gVisor), 3.1–4.0 s (Kata) Yes Yes (Knative) Standard / Enterprise Yes Yes (Fluid compute)
Sandboxing runc, gVisor or Kata (Cloud Hypervisor, QEMU, Dragonball, Firecracker) per project type, installed from the console The cluster's RuntimeClass, set up by you The cluster's RuntimeClass, set up by you runtimeClassName through Profiles: Enterprise Firecracker, managed by AWS Managed; Sandbox runs Firecracker microVMs
Event sources HTTP, schedules, queues, webhooks, topics, Kafka, NATS, RabbitMQ, MQTT, Postgres CDC, S3, IMAP; CloudEvents with retries and dead letters Knative Eventing: Kafka, RabbitMQ, Redis, GitHub, GitLab, Ping, API server and more CloudEvent functions behind Knative Eventing Kafka, RabbitMQ, Pub/Sub, Postgres, SNS / SQS connectors in Standard SQS, Kinesis, DynamoDB Streams, EventBridge, S3, MSK and self-managed Kafka, MQ HTTP, Cron Jobs, Queues
Durable workflows Built in: steps, retries, timers, events, child workflows; Python and TypeScript SDKs — — — Lambda durable functions; also AWS Step Functions Vercel Workflows
Environments and promotion dev, staging, production per project; promotion of the same image, with approval Namespaces Namespaces Namespaces (several in Enterprise) Versions and aliases Preview and Production; custom environments on Pro / Enterprise
Blue-green / canary Blue-green with a test URL; canary in steps with automatic rollback on error rate or p95 latency Traffic split by revision; time-based gradual rollout; no metric-based rollback Through Knative traffic splitting — Weighted aliases; canary / linear with alarm rollback through CodeDeploy Rolling Releases (Pro / Enterprise): staged shares, you advance or abort; Instant Rollback
Multi-region projects Global projects: one host name, HA or proximity mode, failover with Postgres replicas — — — Per region; multi-Region endpoints for Web Functions (latency routing, no health-based failover) Edge network; function regions
Tenancy, RBAC, SSO Organizations and tenants, roles, groups, scoped tokens; SSO with Google, GitHub, Microsoft, GitLab, OIDC, SAML Kubernetes namespaces and RBAC Kubernetes namespaces and RBAC Multiple namespaces, IAM and SSO in Enterprise AWS IAM Teams and roles; SAML SSO on Enterprise
Supply chain SBOM, scans (offline too), cosign signatures, policy gate, signed-image admission — — — Code signing (AWS Signer) —
GPUs and models GPU functions and containers; Hugging Face model services (vLLM, TGI, TEI); model bindings Kubernetes GPU resources — GPU through Profiles (paid editions) — —
MCP Built-in MCP server at /mcp; hosting for your own MCP servers — — — Your own, as a function Vercel MCP; host your own with mcp-handler
Infrastructure as code Terraform / OpenTofu provider brf-tech/runr, runr CLI, GitHub Action, GitLab CI job Kubernetes manifests func.yaml + func CLI stack.yaml + faas-cli AWS provider, SAM, CDK Terraform provider vercel/vercel, CLI
Pricing Free software; you pay only your own infrastructure Free; your cluster Free; your cluster CE free within its limits (15 functions, 60-day commercial trial); Standard / Enterprise subscriptions $0.20 / 1M requests + $0.0000166667 / GB-s (us-east-1, 2026-10-01) Hobby free; Pro $20 / developer / month + usage (2026-10-01)

One at a time, with sources: RunR vs Google Cloud Run · RunR vs AWS Lambda · RunR vs Vercel · RunR vs Knative · RunR vs OpenFaaS

Compiled from each project's public documentation on 2026-11-02 (links below); paid-edition notes follow the vendors' own edition pages, and “—” means the documentation describes no such feature. Knative is a CNCF project; OpenFaaS, AWS Lambda and Vercel are trademarks of their owners. RunR is not affiliated with or endorsed by any of them.

Sources, read on 2026-11-02: Knative rollouts · Knative Eventing sources · Knative Functions · OpenFaaS editions · OpenFaaS Profiles · OpenFaaS pricing · Lambda container images · Lambda alias routing · Lambda event sources · Lambda code signing · Lambda pricing · Vercel Rolling Releases · Vercel environments · Vercel Sandbox · Vercel Daemons · Vercel pricing · read on 2026-11-03: OpenFaaS CE EULA · Lambda durable functions · Lambda Web Functions endpoints · Vercel Container runtime · Vercel Workflows

RunR measurement: v0.5.0, 2026-10-15, single-node k3s v1.34.11 on a test VM (8 vCPU Broadwell, nested KVM, 15.6 GiB), Knative 1.21.3, gVisor 20260921.0, Kata Containers 3.28.0; function 250m CPU / 256 MiB (container 500m / 512 MiB, WebAssembly 250m / 128 MiB), image on the node, RunR's default scale-to-zero; HTTPS from inside the VM through Traefik, a new connection per request; median from zero replicas to the first full HTTPS response, n=12 each — runc: Python 1.50, Go 1.54, Node.js 1.62, PHP 1.65 s, container (CaaS) 1.57 s; gVisor: Python 1.97 s; Kata (Python only): Cloud Hypervisor 3.11, Firecracker 3.21, QEMU 3.89, Dragonball 3.95 s; WebAssembly: Rust 1.54, JavaScript 2.12 s; warm request median 9–12 ms (n=100). The pricing row: official pricing pages as of 2026-10-01 (USD, excluding tax and data transfer); regions and source links in the note below.

Full Monthly Cost · Heavy Data Processing

5M requests/month · 2 GB, 1 vCPU, 3 s each · per request 2 MB read + 1 MB written to object storage (kept 30 days) · 500 KB response · 1 KB log · list prices, USD, 2026-10-01

RunR Self-Host

Software: $0

RunR is software, not a hosted service: no per-request, ms×memory, API gateway or log-ingestion fees. It runs on the infrastructure you already have (bare metal or your cloud installation), so you pay only that infrastructure, whatever it costs you. Data that stays in your own data center pays no hyperscaler egress or storage fees.

AWS Lambda

≈ $876 / mo

Lambda ms×GB $501 (30M GB-s + 5M requests) · egress $225 (2,500 GB × $0.09) · S3 storage + requests $142 · API Gateway $5 · CloudWatch logs $3 (us-east-1)

GCP Cloud Run

≈ $890 / mo

Cloud Run vCPU-s + GiB-s $437 (1 vCPU, 2 GiB, 15M s + 5M requests) · egress $285 (2,500 GiB × $0.12–0.11) · Cloud Storage + operations $127 · load balancer $38 · logs $3 (us-central1)

Azure Functions

≈ $1,142 / mo

Flex Consumption ms×GB $782 (30M GB-s × $0.000026 + 5M runs) · egress $217.50 (2,500 GB × $0.087) · Blob storage + operations $131 · Log Analytics $11.50 (East US; Flex, as Consumption stops at 1.5 GB)

Light API (1M requests, 256 MB, 200 ms, 5 KB responses): $2.58–$2.75 a month in full on AWS, Azure or Cloud Run's default URL, and the free tiers cover nearly all of it — small APIs are nearly free on the hyperscalers. Heavy workload above: each request is 1 GET + 1 PUT, results kept 30 days (→ 5,000 GB stored), 500 KB out (→ 2,500 GB egress), one request per instance (CPU-bound) and the same duration everywhere; month = 730 h; free tiers not deducted (they would remove $18.52 on AWS, $8.78 on Google Cloud, $22.90 on Azure). HTTP entry: API Gateway HTTP API (AWS), the external Application Load Balancer Google recommends for production custom domains, the function app's own hostname with a free managed certificate (Azure); storage over a free private path (S3 gateway endpoint, Private Google Access, Storage service endpoint); GiB-priced lines use the GB figures. Excluded: tax, support plans, backups, WAF, KMS, cross-zone traffic. Regions: AWS us-east-1 (x86 / Linux), GCP us-central1, Azure East US.

Sources (official pricing pages and documentation, read on 2026-10-01): AWS Lambda · API Gateway · S3 · CloudWatch · AWS VPC · Google Cloud Run · GCP network · Cloud Load Balancing · Cloud Storage · Cloud Logging · Cloud Run custom domains · Azure Functions · Flex Consumption · Azure Functions limits · Azure bandwidth · Azure Blob Storage · Azure Monitor · Azure Retail Prices API · Vercel Functions · Vercel plans

MIGRATION

From cloud to RunR — hours, not months.

See how much work it takes to migrate your existing workloads to RunR.

AWS Lambda→RunR

Handlers map 1:1 to XaaS. Remove AWS SDK, paste, deploy.

Small code changes

GCP Cloud Run→RunR

Cloud Run is Knative — RunR IS Knative. Containers work as-is.

No code changes

Azure Functions→RunR

Strip SDK bindings, convert to standard HTTP handlers.

Moderate code changes

Vercel→RunR

Standard Node.js handlers. Copy to FaaS, add package.json, deploy.

Small code changes

Heroku→RunR

Containerize, deploy as CaaS. Scale-to-zero included; idle capacity goes back to other workloads.

Add a Dockerfile

Docker Compose→RunR

Each service becomes a CaaS project. Same image, same env. Now with auto-scale.

No code changes

AWS ECS/Fargate→RunR

Task definitions are already container specs. Same image, point to CaaS.

No code changes

Fly.io / Render→RunR

Standard Docker works as-is. No fly.toml or render.yaml needed.

No code changes

K8s YAML→RunR

Your images are ready. Deploy from UI, skip the YAML.

No code changes
INSTALL

Install it, connect a cluster, deploy.

RunR is software you install, not a hosted service: the control plane and every region run on infrastructure you operate — bare metal, a private cloud or managed Kubernetes, connected or air-gapped.

Helm Kubernetes

The control plane as one Helm chart: gateway, UI, API, workers, scheduler and Reverb, plus PostgreSQL and Redis unless you point it at your own.

The chart is in BRF's public Helm repository: no credentials needed, and domain is the only required value.

helm repo add brf-tech https://helm.brf.sh
helm repo update
helm upgrade --install runr brf-tech/runr \
  -n runr --create-namespace \
  --set domain=runr.example.com
Helm install guide →

Docker Compose single host

A production install on one machine: compose/build.sh builds the images from the release tag; air-gapped hosts get them as runr-images.tar.

git clone -b v0.6.3 \
  https://github.com/BRF-Tech/runr.git
cd runr && bash compose/build.sh
cd compose && cp .env.example .env
cp api.env.example api.env  # + APP_KEY
docker compose up -d
docker compose run --rm migrator
Single-host install guide →

runr CLI Linux · macOS · Windows

Scaffold, run locally on the runtime images and deploy. One command installs it; binaries and checksums are on runr.sh/dl.

curl -fsSL https://runr.sh/install.sh | sh
runr login https://runr.example.com
runr init hello --runtime python
cd hello
runr dev       # localhost:8080
runr deploy
Download the CLI →

Terraform brf-tech/runr

Projects, variables, domains, deployments, bindings, runtimes, workflow triggers, models, MCP servers, roles and branding — as code.

terraform {
  required_providers {
    runr = {
      source  = "brf-tech/runr"
      version = "~> 0.6"
    }
  }
}
Terraform provider →

CI/CD GitHub Actions · GitLab CI/CD

Deploy on every push and run preview environments for pull / merge requests: the ready-made Action on GitHub, a job that installs the CLI and runs runr deploy on GitLab CI/CD.

# GitHub Actions: secrets RUNR_API_URL, RUNR_TOKEN
- uses: brf-tech/runr/actions/deploy@v0.6.3
  with:
    api-url: ${{ secrets.RUNR_API_URL }}
    token: ${{ secrets.RUNR_TOKEN }}
    path: ./functions/orders

# GitLab CI/CD: variables RUNR_API_URL, RUNR_TOKEN
deploy:
  image: alpine:3.21
  script:
    - apk add --no-cache curl tar
    - curl -fsSL https://runr.sh/install.sh | sh
    - runr deploy ./functions/orders
GitHub Actions → GitLab CI/CD →

Documentation

The architecture, a page for every feature, upgrade notes between releases and the changelog — at runr.sh/docs.

OPEN SOURCE

Not ours — yours.

RunR is developed by BRF Teknoloji and open source under the MIT license; nothing sits behind a paywall. Run it on your own clusters, on your own terms — fork it, change it, contribute.

✓ MIT license ✓ All features free ✓ On your own infrastructure ✓ Open to contributions
Downloads View on GitHub Contribute
FAQ

Frequently Asked

What exactly is RunR?
RunR is an open-source serverless platform on Kubernetes and Knative, developed by BRF Teknoloji under the MIT license. You deploy single-file functions (XaaS), multi-file projects (FaaS), containers (CaaS) and WebAssembly from the web console, with git push, from the CLI, Terraform or a GitHub Action — with sandboxes, durable workflows, bindings, GPUs and MCP built in. Think of it as your own AWS Lambda + ECS, on Kubernetes clusters you control.
Is RunR a hosted service?
No. RunR is software you install: you set up the control plane with Helm or with Docker Compose on a single host, then add your own Kubernetes clusters as regions. Your code, data and logs stay on your infrastructure.
Is it really free? Where does money come from?
Yes. MIT license, no feature gates, not open-core: tenancy, SSO, RBAC, the audit log, billing calculation and observability all ship in the same repository. Revenue comes from enterprise support and SLA guarantees for teams that want them.
How do I install it?
On Kubernetes with the chart from BRF's public Helm repository (helm repo add brf-tech https://helm.brf.sh, chart brf-tech/runr; Helm install), on a single host with Docker Compose (single-host guide). The runr CLI installs with curl -fsSL https://runr.sh/install.sh | sh or downloads from runr.sh/dl; the Terraform provider is brf-tech/runr on the Terraform Registry (runr.sh/brf-tech/runr for OpenTofu). Details in the install section above and in the documentation.
How is it different from raw Knative?
Knative is the engine; RunR is the car. Knative gives you primitives, but you still write YAML, build images, manage deployments and set up isolation and monitoring. RunR wraps it in a console and an API: versions, one-click or git push deploys, sandboxes, live logs and traces, roles, billing calculation, multi-tenancy — all included.
Can I run without multi-tenancy?
Yes. Multi-tenancy is a toggleable module (TENANCY_ENABLED=false). When off, the platform runs single-tenant: user management, roles and groups still work and multiple users can use it, just without tenant isolation.
Can one project run in several regions?
Yes. A global project runs in several regions behind one host name: in HA mode the primary region answers while it is healthy, in proximity mode the closest healthy region. A failed primary fails over to the next region with its triggers and data; dedicated Postgres bindings get a replica in every region. Details: global projects.
How secure is code execution?
Every project type runs in the sandbox its region assigns: plain runc, gVisor (a user-space kernel) or Kata Containers (a micro-VM per pod, on nodes with hardware virtualization). On top: RBAC with scoped tokens, secrets encrypted at rest, an append-only audit log, SBOMs, scans, signatures and signed-image admission in the region. Projects are isolated from each other on the internal network too: one project reaches another only through its allow list. Tenants get CPU, memory and GPU quotas per region.
How hard is it to migrate from AWS/GCP/Azure?
Not very. Lambda handlers map 1:1 to XaaS (remove SDK, paste). Cloud Run containers work as-is in CaaS (same Knative base). Azure needs SDK removal. Most migrations take hours, not weeks — the migration cards above show what each platform needs.
Is it production-ready?
Yes. RunR is actively deployed in production on multi-node K8s clusters — multi-tenancy, real workloads, automated CI/CD. PDB, HPA, health checks, automatic migration and rollback support are all included, and installations upgrade in place with helm upgrade.
How do I report a security issue?
Privately, by e-mail to security@runr.sh — not in a public issue. We acknowledge reports within three business days; details in the security policy.
RELEASE NEWS

Hear about new releases first.

New RunR releases and important announcements in your inbox. No spam, just the important stuff.

Your email is only used for RunR updates. Unsubscribe anytime.