Skip to content

Public alpha · Linux infrastructure

Deploy manifest. Donate capacity. Keep boundaries visible.

Kikapu connects manifest-first workloads to opted-in Linux nodes. Central plane schedules; node agent dials out; rootless Podman runs per-tenant workloads.

Kikapu deploy pathCLI sends manifest to central plane. Node creates outbound tunnel. Browser traffic reaches workload through tunnel.CLImanifestcentralplanenodeagentrootlessworkloadoutbound tunnel only

Deploy path

Three systems. One declared result.

Read controlled deployment
  1. 01

    Central plane

    Run Kikapu server, PostgreSQL, and Caddy. Mint an API key; control plane chooses fitting capacity inside transaction.

  2. 02

    Node agent

    Owner opts in on supported Linux. Agent opens authenticated outbound WebSocket/yamux tunnel; no node public address enters deploy request.

  3. 03

    Manifest apply

    Tenant runs kikapu deploy. Agent creates hardened rootless workload and reports running only after loopback service is reachable.

Start from current Book

Commands stay copyable.

$ kikapu login --server https://control.apps.example.com
$ kikapu deploy --file kikapu.yaml

Examples use Book placeholders. Configure real server, credentials, images, and root domain before use. No command here is a production-readiness claim.

Security boundary

Tenant isolation, not host-root secrecy.

Node-owner root can inspect workload processes, storage, environment values, signed desired-state cache contents, and Podman state. Keep external backups. Do not deploy secrets or data you would not hand selected node owner.

Read boundary in Book

FAQ

Is Kikapu production ready?

No. It is alpha-stage. Existing tests and docs do not turn it into a general availability promise.

Can I choose node or port?

No. Placement, public node addresses, and selected host ports are excluded from deployment requests.

Does Kikapu track visitors?

Kikapu itself uses no analytics, marketing cookies, or local storage on this public site.