Overdrive
Everything you run, on one platform.
Overdrive is a workload orchestration platform written in Rust. It is designed
to run long-running services, batch jobs, microVMs, and WebAssembly functions
under one control plane — with mutual TLS, load balancing, identity,
and health checks built in. One platform to operate on your own hardware,
instead of a stack you assemble and babysit.
Status: early. Overdrive runs on a single node today and is
pre-production. This README marks what runs now and what is intended;
nothing here is presented as shipped that isn't, and there are no benchmark
numbers because there is nothing at fleet scale to measure yet. The full
design — most of which is still ahead of the implementation — is tracked in
the roadmap below.
What runs today
Single-node and pre-production. This is the shipped surface — what you can
actually run right now:
- Ship from one file. Describe a service or job in a single TOML spec and
deploy it with
overdrive deploy. Deploy is idempotent on the spec's content
hash — an identical spec is a no-op, so it is safe to run straight from CI.
- Boot a microVM with enforced limits. Declare a
[vm] workload and it
boots as a Cloud Hypervisor microVM with its own kernel, isolated by hardware
virtualization. The hypervisor runs confined — non-root, seccomp- and
Landlock-restricted — and the platform reports the guest's real exit code, so
a VM that boots and fails is never counted as a success. You supply the
kernel and rootfs; the node needs /dev/kvm.
- Health-checked and restarted. Readiness and liveness probes gate traffic
and catch failures; an allocation that fails its liveness check restarts, and
the platform holds the replica count you declared.
- In-kernel load balancing. Traffic to a service spreads across its healthy
backends in the kernel, with no userspace proxy in the path.
- An identity per workload. Every workload gets a short-lived cryptographic
identity (SPIFFE) from a built-in certificate authority, so policy can name
what a service is rather than the IP it currently holds.
Encryption in the kernel, WebAssembly functions, the gateway, multi-node HA, and
the immutable OS are all on the roadmap below — designed, not yet shipped.
Deploy a workload
A workload is a TOML file: what to run, the CPU and memory it gets, and the
health checks that tell the platform when it's ready.
# payments.toml
[service]
id = "payments"
replicas = 1
[vm]
command = "/opt/payments/bin/server"
kernel = "/var/lib/overdrive/kernel"
rootfs = "/var/lib/overdrive/rootfs.ext4"
[[listener]]
port = 8080
[[health_check.readiness]]
type = "http"
path = "/healthz"
port = 8080
$ overdrive deploy payments.toml
payments · deploying…
payments · running 1/1 healthy
Re-run it any time — deploy is idempotent, so an identical spec changes nothing
and a CI job that can't tell whether it already landed is safe to run anyway.
The full walkthrough is in the
deploy guide.
The [vm] block names the guest command plus the operator-supplied kernel and
rootfs; the guest is hardware-isolated and its real exit code is reported back. See
microVMs.
Roadmap
The platform is built in phases, each tracked as a GitHub milestone. Phase 1 is
essentially complete (22 of 24 issues closed); Phase 2 is in progress (19 of 34);
Phases 3–7 are planned and mostly unstarted, though the Cloud Hypervisor microVM
driver (#42) has landed ahead of the rest of Phase 3 and runs today. Everything
in the phases below is tracked work — designed, issue-by-issue, not shipped.
Issue numbers link the specifics.
Encryption and enforcement move into the kernel: mutual TLS via sockops + kTLS
(#26), BPF LSM mandatory access control (#27), agentless flow and resource
telemetry (#31, #32), the workload SVID lifecycle and near-expiry rotation
(#35, #40), node enrollment (#36), and the real-kernel test harness (#29, #30).
Run more than processes: WebAssembly serverless functions with scale-to-zero
(#44) and shared volumes (#43). A dual policy engine compiles Regorus and WASM
policy down to in-kernel verdicts (#38, #45, #47), and node drain migrates
workloads off unhealthy nodes — the reactive tier of self-healing (#50).
A built-in gateway speaks HTTP/1.1–2, gRPC, and WebSocket with rate limiting,
auth, and circuit breaking (#54–#56) and issues its own certificates over ACME
(#57). WASM sidecars add the credential proxy and content inspector (#51, #52)
behind an SDK (#53). And deployment strategies grow up: rolling deploys (#64),
canary promotion with SLO-based rollback (#65), multi-stage rollout workflows
(#62, #66), and scheduled cron jobs (#63, #166).
High availability through a Raft intent store and a gossiped observation store
(#67, #68), with zero-downtime single→HA migration (#70). Operator identity and
CLI auth (#80, #81). And the sealed appliance itself: the meta-overdrive
immutable node OS and Image Factory (#75, #76), with an optional WireGuard or
Tailscale mesh underlay (#77, #78).
The tiered self-healing story lands here. An LLM SRE agent (#85) runs
first-class investigations (#86), proposes typed actions through a risk-based
approval gate (#88), correlates signals by workload identity (#89), and reasons
over the reflexive and reactive tiers (#91) — learning from incident memory
(#94). Plus right-sizing (#92), scale-to-zero (#93), and persistent stateful
microVMs (#96–#100).
Multi-region federation (#104–#107), language SDKs for functions and workflows
(#109, #110), unikernel drivers (#112), OpenTelemetry export (#111), in-place OS
upgrades with dm-verity + TPM attestation and Secure Boot (#117, #118), and
operator SSO via OIDC (#119).
The full tracker — 146 open issues across these milestones — lives at
github.com/overdrive-sh/overdrive/issues.
Documentation
License
Source-available under the Functional Source License (FSL-1.1-ALv2). Every
release converts to Apache 2.0 two years after publication, under the
irrevocable future grant written into the license. Internal use is
unrestricted; the two-year window only restricts offering a competing
commercial product. See LICENSE for the full text.
