PUBLIC ALPHA · LINUX INFRASTRUCTURE
Deploy by manifest. Onto Linux that volunteered.
Kikapu schedules manifest-first workloads onto opted-in nodes. The control plane places it, the node dials out, rootless Podman runs it — one tenant at a time, every boundary in plain sight.
open source · alpha-stage · no availability promise
simulated deploy readout · illustrative
BUILT ON TOOLS YOU ALREADY RUN
// Architecture
Three systems.
One declared result.
- 01
Central plane
Run the Kikapu server, PostgreSQL, and Caddy. Mint an API key. The control plane chooses fitting capacity inside a single transaction.
- 02
Node agent
The owner opts in on supported Linux. The agent opens an authenticated outbound WebSocket/yamux tunnel — no node public address ever enters a deploy request.
- 03
Manifest apply
The tenant runs kikapu deploy. The agent builds a hardened rootless workload and reports running only after the loopback service answers.
// Control plane
See what you deploy into.
One plane for placement, tunnels, and running workloads — every node opted in, every boundary on the record.
interface mock · illustrative data
// Workflow
Commands stay copyable.
Two commands from login to a running workload. Examples use Kitabu placeholders — set your real server, credentials, images, and root domain first.
kikapu login --server https://control.apps.example.comkikapu deploy --file kikapu.yaml// Security boundary
Isolation for tenants.
Not secrecy from the host.
A node owner with root can inspect your workload processes, storage, environment values, signed desired-state cache, and Podman state. Keep external backups. Never deploy secrets or data you would not hand the selected node owner.
Read the boundary in Kitabu →node-owner-root can inspect:
→ workload processes
→ storage & environment values
→ signed desired-state cache
→ podman state
✓ visible by design, not by accident
// FAQ
Plain answers.
No. It is alpha-stage. Existing tests and docs do not turn it into a general-availability promise.
Ready to build?