What is Rune?
Rune is a lightweight, single-binary orchestration platform. Here's what it does, what it doesn't, and when to reach for it.
Rune is an orchestration platform — it takes declarative service definitions and keeps them running. It's inspired by Kubernetes and Nomad but trades surface area for simplicity. There are two binaries:
runed— the server (control plane). Stores state in BadgerDB, runs the orchestrator and reconcilers, exposes a gRPC API and a REST gateway.rune— the CLI. Talks torunedover gRPC.
That's it. No etcd. No kubelet. No CRDs.
What Rune does
- Runs Docker containers and native processes as services with a desired scale.
- Reconciles instances of those services to match the desired state.
- Streams logs and supports interactive exec into running services.
- Manages secrets (encrypted at rest) and configmaps.
- Enforces health checks (HTTP, TCP) and supports liveness probes.
- Models dependencies between services and waits for them on rollout.
- Authenticates clients with bearer tokens and authorizes them via policy-based RBAC.
- Packages multi-service applications as runesets (templated YAML bundles).
What Rune doesn't (yet)
- Multi-node clustering. Single-node today. Raft-backed multi-node is in active development (Release 2).
- Network policy enforcement / ingress controllers. Schema accepts them; runtime enforcement is roadmap.
- Persistent volume management. No volume abstraction yet — bind mounts only.
- Autoscaling. Manual
rune scaleonly; metric-driven autoscaling is roadmap. - Service mesh / mTLS between services. Roadmap.
If you need any of those today, reach for Kubernetes or Nomad.
When Rune is the right tool
- You're a small team running 5–50 services on 1–3 boxes and Kubernetes feels like a tax.
- You're building an internal platform and want a control plane you can actually read end-to-end.
- You have a mix of containers and bare-metal processes and don't want two systems.
- You want a self-hosted alternative to Heroku/Render that you can
sshinto.
When it isn't
- You need multi-region, thousands of nodes, or strict SLAs today.
- You depend on the Kubernetes ecosystem (operators, Helm charts, kubectl plugins).
- You need pluggable storage classes, CSI drivers, or sophisticated scheduling.
How the pieces fit
┌─────────┐ gRPC + REST ┌──────────────────────────────┐
│ rune │ ────────────▶ │ runed │
│ (CLI) │ │ │
└─────────┘ │ ┌─────────────────────────┐ │
│ │ Orchestrator │ │
┌──────────┐ REST/gRPC │ │ (controllers, probes) │ │
│ app / │ ───────────▶ │ └────────────┬────────────┘ │
│ CI/CD │ │ ▼ │
└──────────┘ │ ┌──────────────────────┐ │
│ │ Runner manager │ │
│ │ ┌────────┐ ┌────┐ │ │
│ │ │ Docker │ │Proc│ │ │
│ │ └────────┘ └────┘ │ │
│ └──────────────────────┘ │
│ ┌──────────────────────┐ │
│ │ BadgerDB state │ │
│ │ (encrypted secrets) │ │
│ └──────────────────────┘ │
└────────────────────────────────┘
Read Architecture for the full picture, or jump straight to the quick start.