JEKYO: Stop doing ops

You build the app. JEKYO and your AI agent do everything below it: the cluster, the certificates, the deploys, the backups, the 3am restarts. Any server becomes your own cloud.

Installation

Install the CLI and turn a server into a JEKYO cluster with one command.

Your first app

From an empty directory to a deployed, TLS-served app in five minutes.

The jekyo.yaml file

One file for everything: build, runtime, domains, volumes, GPUs.

CLI reference

Docker-grade ergonomics: up, ls, logs, exec, rollback, and friends.

JEKYO is a single open-source binary. It installs Kubernetes (k3s) with ingress, automatic TLS, a private registry, a WireGuard VPN, and NVIDIA GPU support, then gets out of the way. You never have to learn what any of those are.

Build the app, not the platform. One jekyo.yaml describes your whole app: build, domains, certificates, storage, backups. JEKYO compiles it to Kubernetes you never have to look at. The platform is there when you need it and invisible when you don't.

Deploy in minutes, with tools you already have. A server, SSH, and one binary. jekyo up builds your images, ships them, routes traffic, and issues certificates. Rollbacks are one command, and a staging server is just another context. There is no pipeline to stand up and no YAML archaeology.

Hand the ops to your agent. JEKYO teaches Claude Code, Codex, and Cursor to deploy, monitor, back up, and fix apps on your server. Say what you want in plain language. You review results, not runbooks.

Setting up and maintaining a platform is not where your product wins. Put your energy where it matters and let the machine below stay boring.

And the bill is just the server

Managed clouds bill you per app, per database, per gigabyte, per GPU-hour. A server bills you once. JEKYO gives one machine the full platform experience (apps, databases, GPU models, TLS, deploy on push), so adding your next app costs nothing.

Quick start

Everything starts with a server you can SSH into and one command:

jekyo server install root@1.2.3.4 --ip 1.2.3.4 --storage /storage \
  --domain example.com --acme-email you@example.com

The installer runs a preflight check suite first (it refuses to break an occupied machine), then converges the server into a ready cluster. Re-running it is always safe.

Then describe an app:

app: acme
services:
  api:
    build:
      context: .
    port: 8080
    http:
      domain: api.acme.com

Point your domain's A records (or a wildcard *.example.com) at the server's IP, and ship:

jekyo up

Your source is built (content-hashed, so unchanged code never rebuilds), pushed to the cluster's private registry, deployed, routed, and TLS-certified. jekyo ls, jekyo logs api -f, and jekyo rollback work the way you expect them to.

Or just ask your agent

you>   /jekyo deploy this app
agent> jekyo render   (valid: 2 services, 1 volume)
agent> jekyo up
       App shop deployed. api: https://api.shop.example.com

One command teaches any coding agent the whole tool: jekyo skill install --global. From then on, deploys, log digging, and rollbacks are a conversation.

You own everything

JEKYO has no cloud, no account, and no lock-in: the cluster is stock k3s, jekyo render prints the exact Kubernetes YAML it generates, and jekyo server uninstall returns the machine to clean.

How does it compare?

Real Kubernetes underneath instead of Docker scripts. Driven by a file in your repo and a CLI your AI agent can operate, not click-throughs. Volume backups and GPU workloads built in. And the rows where Coolify, CapRover, Dokploy, or Kamal win, we say so: see the honest comparison.

Why Kubernetes underneath

Because the primitives are worth it: per-app namespaces today enable per-client isolation and resource quotas tomorrow; ingress and certificates are declarative; GPUs are schedulable; and a future second server is server join, not a rewrite. JEKYO's job is making none of that your problem.