SwiftCube — the orchestrator for swift-os fleets.
A Swift-everywhere control plane that schedules applications onto swift-os nodes, keeps desired state reconciled, and programs your load balancers. A simplified-but-complete analogue of Kubernetes — except it does the one thing that makes it fast: it removes the container abstraction instead of optimizing it.
A deployed instance is a Cell — not a container.
The headline idea. SwiftCube does not run containers; it schedules swift-os Cells, the kernel's own capability-based isolation domain.
A Cell already bundles everything an orchestrated workload needs — so there is nothing left to assemble at deploy time. No container runtime to start, no image to layer, no union filesystem to stack, no daemon to talk to. Because the substrate is the kernel itself, an instance doesn't boot — it's admitted, in milliseconds.
instance = Cell, not a container.
How the control plane is wired.
sctld is a single binary — API, scheduler, reconcilers, LB programmer, and an embedded cubestore — running as a 3-node Raft quorum. Each node runs a slet.
- drives Cellsthe instances
- node-proxyeast-west · virtual service IP
- node-local PVon datafs
- 1
sctl applywrites a Deployment — forwarded to the Raft leader and committed. - 2The scheduler loop expands it into N Assignments — spread across nodes, fit by cpu/mem.
- 3Each node's
sletwatches its assignments and makes local reality match — creating, supervising, or reaping Cells — then reports status back. - 4The endpoints loop watches healthy Cells and programs the external load balancers.
Self-healing falls out for free — when a node's lease expires, its assignments are re-placed elsewhere.
cubestore lives in-process with the reconcile loops, SwiftCube skips the apiserver↔etcd network hop Kubernetes pays. A 3-node Raft group gives linearizable writes; a minority partition goes read-only. v1 nodes are swift-os only.Two things make it different.
Both fall out of building on the Cell substrate rather than on top of a container runtime.
Cells instead of containers
An instance is a kernel isolation domain, not a packaged process tree. The read-only base is shared across every replica; only the RAM scratch is per-instance.
- → Millisecond start — no runtime to spin up
- → Shared read-only base, deduplicated on the node
- → Per-instance RAM scratch, gone on stop
Capabilities instead of root-in-container
A workload's identity is its capability set. You don't grant a uid and hope; you enumerate exactly the kernel rights it holds — nothing ambient, nothing implied.
Declare it. SwiftCube reconciles it.
A flat, compose-like manifest — no apiVersion/kind/spec wrapper. Apply it; the control loops pull reality toward it.
# SwiftCube manifest — flat, compose-like (SWIFTCUBE_DESIGN §10)
app: edge-api
image: registry.local/edge-api@sha256:9f2c… # content-addressed, read-only
replicas: 3
command: [ /bin/edge-api, --serve ]
update: { strategy: canary, canarySteps: [25, 50, 100], progressDeadlineSeconds: 300 }
resources: { cpu: 500m, memory: 256Mi } # request == limit in v1
ports:
- name: http
container: 8080
expose: { via: lb, provider: nginx, listen: 443, protocol: https, tlsCertRef: edge-api-tls }
env: { LOG_LEVEL: info }
secrets: [ db-password ] # from cubestore, mounted in tmpfs
volumes:
- { name: state, mount: /var/lib/edge-api, persistent: true, size: 1Gi } # node-local, fenced
capabilities: [ net.listen:8080, fs.read:/etc/edge-api ] # identity IS the capability set
health:
readiness: { http: /health, port: 8080, period: 1s, failureThreshold: 3 }
liveness: { http: /livez, port: 8080, period: 5s }
placement: { spread: node, nodeSelector: { zone: eu-central } }apply it · single node
$ sctl --local ./state apply -f edge-api.yaml deployment/edge-api created (revision 1, replicas 3)
read state
$ sctl --local ./state get deployments NAME REPLICAS REVISION STRATEGY-REQ edge-api 3 1 cpu=500m/mem=256Mi $ sctl --local ./state rollout status edge-api rollout edge-api: strategy: canary revision: 2 replicas: 3 phase: Progressing revisions: r1=1 r2=2 traffic: r1:50% r2:50% ready: 3 history: r1 r2
sctld's reconcile loops — watch them land with rollout status.Four pieces. Everything Swift.
If you know Kubernetes, you already know the shape — SwiftCube just collapses it into far less moving machinery.
A 3-controller quorum gives you fault tolerance; cubestore living in-process with the reconcile loops is what removes the network hop Kubernetes pays between apiserver and etcd.
What it does for the fleet.
The orchestration surface you'd expect — built directly on the Cell substrate and one consistent store.
Reconciliation-driven
Declarative by default. Control loops pull reality toward desired state, so self-healing isn't a feature — it's the normal operating mode.
Strong consistency
One Raft group, linearizable writes, leader forwarding. A 3-controller quorum keeps the cluster's truth single and correct.
Automatic rollouts
Rolling, blue-green, and canary — every step gated on readiness, with automatic rollback the moment a gate fails.
Sticky volumes
Node-local persistent volumes with fencing for stateful workloads — the instance comes back to its data, never to a torn write.
Secure by construction
mTLS everywhere, RBAC on the API, and secrets envelope-encrypted then delivered via tmpfs — never written to disk on the node.
Built for the flagship profile
Fits swift-os's application & AI-hosting profile cleanly — long-running services and inference workloads, scheduled as Cells.
Where it actually stands.
In the swift-os tradition: we tell you what's real. SwiftCube is built through milestone SC9b, host-tested, and single-node sctl --local works today.
v1 scope: swift-os nodes only. The whole speed thesis depends on the Cell substrate — so SwiftCube doesn't pretend to orchestrate anything else yet. Remaining seams: production mTLS accept-loop, image registry, RBAC/secrets delivery, full multi-node in QEMU.
- SC0cubestore — single-node MVCC KV + watch + WAL/snapshot
- SC1Raft consensus — elections, replication, quorum of 3, leader forwarding
- SC2node join — bootstrap token, mTLS, TTL leases
- SC3slet — reconcile loop driving the C6 Cell supervisor
- SC4scheduler — Deployment → Assignments (spread + fit)
- SC5readiness/liveness probes → ready-only endpoints loop
- SC6LB provider interface + nginx backend
- SC7east-west — service registry + userspace node-proxy
- SC8node-local sticky PVs on datafs + single-writer fencing
- SC9sctl CLI + manifest parser + rollout state machine (rolling/blue-green/canary + rollback)