28 April 2026 · 6 min read

From git push to live URL — the EZKeel workflow.

Five commands. Zero YAML. Your VPS, your code, your coding agent. Here's the full path from a fresh box to a running app.

The shape of the problem

Spinning up a coding agent on a remote machine is still cluncky. SSH keys here, devcontainer there, secrets somewhere else. MCP servers sprawl. You end up with a setup.md that lies the moment you blink.

EZKeel bundles the pieces — Forgejo for git, Caddy for TLS, Docker for runtime, an agent that listens on the box, and a CLI that wires the whole thing together. One install. One push. The agent does the rest.

Step 1

Install the CLI

$ curl -fsSL https://ezkeel.com/install.sh | sh
  Downloading ezkeel v0.4.x...
  Installed to /usr/local/bin/ezkeel

$ ezkeel version
ezkeel v0.4.x

One static binary. No Node, no Python, no Homebrew tap. The CLI is the front door — the dashboard at app.ezkeel.com is for when you'd rather click than type.

Step 2

Provision a VPS

$ ezkeel server add --hetzner
  ? Hetzner API token  ******************
  ? Server name        production
  ? Plan               cpx22 ($5/mo)
  ? Location           fsn1

  → creating server in fsn1...
  → waiting for SSH...
  → bootstrapping Docker + Caddy + agent...

  Done. Server "production" ready at 5.75.x.x

The auto-provisioner stands up Hetzner Cloud, lays down Docker, Caddy, the EZKeel agent, and a hardened SSH config. Already have a VPS? Use ezkeel server add without the flag and paste an SSH key — the bootstrap is the same.

Step 3

Point your coding agent at it

$ ezkeel ai claude
  Launching Claude Code with EZKeel MCP server attached...
  → ezkeel-mcp connected (7 tools)
  → workspace: ~/code/myapp
  → secrets: injected via Infisical

The MCP server gives the agent read-only tools: list apps, tail logs, query the database, view files, check deploy status. No shell tool, no key access, no surprise rm -rf. Want Cursor instead? ezkeel ai cursor. Codex? ezkeel ai codex. Same wiring.

The agent now sees your VPS the way it should: as a structured set of capabilities, not as a shell prompt where one bad token reads ~/.ssh/id_rsa.

Step 4

Ship code

$ ezkeel up https://git.example.com/me/notes-app
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ✓ detected Express
  ✓ generated Dockerfile.ezkeel
  ✓ built notes-app:latest
  ✓ provisioned PostgreSQL: notes_app
  ✓ deployed to production
  ✓ health check passed

  notes-app · Express · production · 18s
  → https://notes-app.apps.example.com

Six steps. Auto-detected stack. Auto-provisioned database. Auto-issued TLS cert. The first deploy of an app is also the slowest — subsequent git push events go through the Forgejo webhook and ship in under ten seconds.

Step 5

Iterate

From here on, the loop is short:

• Tell your agent what to change.
• Agent commits, pushes to Forgejo.
• Forgejo fires the webhook.
• EZKeel rebuilds, redeploys, runs the health check.
• Agent reads the new logs over MCP, confirms the change shipped.

Rollback is one command:

$ ezkeel rollback notes-app
  → reverted to deploy 7f3a91c (12 minutes ago)

What you didn't have to write

• A GitHub Actions workflow.
• A Dockerfile (unless you wanted to).
• A docker-compose.yml.
• A reverse-proxy config.
• A TLS cert renewal cron.
• A secrets-injection step.
• A setup.md for the agent.

Where this is going

The next month is about polish: better error messages, sturdier MCP scoping, mosh-resilient agent sessions for laptops on flaky WiFi. The platform is in private beta — if you want in, drop your email on the waitlist.