How it works

JEKYO is deliberately boring underneath: standard components, pinned versions, no custom control plane.

On the server

server install converges a machine to this stack:

• k3s: lightweight certified Kubernetes, pinned version, embedded containerd.
• Contour + Envoy: ingress on host ports 80/443, serving standard Ingress resources.
• kcert: a single-pod ACME client issuing and renewing Let's Encrypt certificates for labeled ingresses.
• Private registry: registry:2 with auth, storing your built images on the persistent storage path; every node resolves it without pull secrets.
• wg-easy: WireGuard into the cluster network, with CoreDNS pushed to clients.
• NVIDIA runtime: driver, container toolkit, and RuntimeClass, when a GPU is present.

Addons are applied through k3s's manifest directory, the same mechanism k3s uses for its own components. There is no helm, no operator, and no JEKYO process running on the server.

On your machine

The CLI compiles jekyo.yaml to plain Kubernetes resources (see them: jekyo render), applies them with server-side apply, prunes what a new revision no longer declares, and records each deploy as a revision in the cluster. Cluster-internal endpoints (registry API, VPN admin) are reached by dialing through the SSH connection. Nothing internal is ever exposed publicly.

App state lives in the cluster, not in local files: any machine with the context sees the same apps, history, and status.

No lock-in, by construction

• The cluster is stock k3s. Every kubectl tutorial applies.
• jekyo render hands you the exact YAML; if you stop using JEKYO tomorrow, you keep working manifests and a working cluster.
• jekyo server uninstall removes everything cleanly (it's the k3s uninstaller plus JEKYO's own config).

Security posture

• Credentials (registry, VPN) are generated at install, stored in your local context, never in the repo.
• The registry requires auth; internal services aren't published; the VPN is the intended path to reach them.
• App namespaces isolate workloads; per-tenant quotas and network policies are on the roadmap (the namespace-per-app foundation is why they'll be easy).