A Claude Code skill that self-deploys 2,200+ open-source apps to your own infrastructure.
Tell Claude Code what to self-host. It does the rest — picks the right install method, provisions the server, configures DNS + TLS, sets up SMTP, hardens it, and brings the app up at your domain.
No more reading a 30-step README and copy-pasting bash for hours. You stay in chat; Claude Code drives the CLIs (aws, gcloud, kubectl, docker, ssh, …) and asks you only the things only you can answer (which cloud, which domain, which credential).
Backed by a self-improving catalog: every deploy can feed gotchas back so the next user starts further ahead.
> "Self-host OpenClaw on AWS Lightsail with Bedrock pre-wired."
Claude Code: Loading verified recipe openclaw.md (v0.24.0).
Claude Code: Combo: AWS Lightsail OpenClaw blueprint (vendor-bundled, Bedrock IAM included).
Claude Code: I'll need your AWS profile and the domain you want.
AWS profile name?
(OpenClaw — the self-hosted personal AI agent at openclaw.ai — is the project's signature use case; works the same way for any of the 2,200+ verified recipes.)
/plugin marketplace add zhangqi444/open-forge
/plugin install open-forge@open-forge
That's it. From now on, just say what you want self-hosted in any Claude Code session:
"Self-host Vaultwarden on my laptop, expose via Cloudflare Tunnel."
"Run Immich on a Hetzner CX22 with restic backups to Backblaze B2."
"Deploy Ghost on AWS Lightsail at blog.mydomain.com."
Claude Code is the canonical home, but the same recipes ship for other agents — see docs/platforms/:
| Platform | How |
|---|---|
| Codex (ChatGPT / CLI) | System-prompt embedding or workspace files |
| Cursor | .cursor/rules/ bundle |
| Aider | --read files + CONVENTIONS.md |
| Continue.dev | Context provider + slash command |
| OpenClaw (personal AI agent at openclaw.ai) | Workspace skill at ~/.openclaw/workspace/skills/open-forge/ |
| Hermes-Agent (Nous Research) | User skill at ~/.hermes/skills/open-forge/ |
| Generic agents | Any LLM that can read files + run shell |
Agent-mode caveat: When running inside an autonomous agent (OpenClaw / Hermes / messaging-channel agents), credential paste is disabled — the skill only accepts file paths, env vars, cloud-CLI sessions, or secrets-manager refs. Pasting credentials into messaging channels (WhatsApp / Telegram / etc.) is meaningfully riskier than into coding-tool chat. Group-channel deploy conversations are also refused.
On Windows? See docs/windows-setup.md for WSL2 + Docker Desktop setup and common Windows gotchas (stale Git proxy, line endings, WSL integration).
To know when a new version ships:
- 📋 CHANGELOG.md — user-visible changes per version
- 📡 Releases atom feed — subscribe in any feed reader (Feedbin, Inoreader, NetNewsWire)
- 🌟 GitHub Watch → Custom → Releases — email notification on each release
To apply an update in Claude Code: /plugin marketplace update zhangqi444/open-forge
Raw Claude Code can absolutely deploy software for you — but it starts from zero every session. open-forge accumulates — every deploy can feed gotchas back into the catalog so the next user starts further ahead.
you deploy ─► skill captures gotchas ─► you review + opt in to share
▲ │
│ ▼
└─ improved recipe ◄─ AI agent patches ◄─ sanitized issue
The loop:
- You deploy. Skill walks you through provisioning, DNS, TLS, SMTP, hardening — recording state for resume.
- Skill drafts a sanitized issue at the end with the gotchas it observed and proposed recipe edits. Domains, IPs, API keys, AWS account IDs are stripped before you see the draft.
- You review and opt in (or don't — never auto-posted). One click; takes seconds.
- An AI agent processes the issue — re-fetches upstream docs, applies the strict doc-verification policy, patches the recipe, opens a PR, bumps the version.
- The next user gets the improved recipe.
That's why captured tribal knowledge already includes things like "OpenClaw's three installers (install.sh, install-cli.sh, install.ps1) don't share state — pick one and stick with it", "the Lightsail OpenClaw blueprint runs the gateway as a systemd USER unit with loginctl enable-linger so it survives no-login sessions", "on Windows, OpenClaw's iwr | iex failures are non-fatal to the shell — silent partial installs are common, always check the explicit success line", and "Bitnami's bncert-tool won't accept --unattended" — none of which are in any upstream README.
Other reasons it's better than raw Claude Code:
- Resumable across sessions — phased workflow + state file at
~/.open-forge/deployments/<name>.yaml. If TLS fails at 11pm, resume from thetlsphase tomorrow. - Consistent across clouds — "install Docker on Ubuntu" is written once and reused for Hetzner / DO / Lightsail / localhost. Swap clouds without re-deriving.
- Source-attributed — every install method cites the upstream URL it derives from. When upstream drifts, the link is the recovery path.
- Safer credential handling — five patterns ordered by safety (file path → env var → cloud-CLI session → secrets manager → chat paste); chat paste asks you to acknowledge the risk and reminds you to rotate after.
- Software: 2,200+ verified recipes for popular self-hostable apps — AI stack (Ollama · vLLM · Open WebUI · …), publishing (Ghost · WordPress · …), productivity (Nextcloud · Joplin · …), photos & media (Immich · Jellyfin · …), monitoring, security, networking, communication, automation. Plus curated bundles (AI homelab, privacy stack) for goal-shaped requests, and live-derived fallback for anything else with public docs (best-effort; you'll see a banner before it starts).
- Where: any cloud VM (AWS · Azure · GCP · Hetzner · DigitalOcean · Oracle Always-Free ARM · Hostinger), your own machine, Raspberry Pi, macOS VM (Lume), any Kubernetes cluster (EKS · GKE · AKS · DOKS · k3s · kind), or PaaS (Fly.io · Render · Railway · Northflank · exe.dev).
- How: Docker · Podman · Native · Kubernetes (Kustomize-first; Helm where upstream ships one).
📖 Browse the catalog: deepwiki.com/zhangqi444/open-forge — auto-generated wiki view of every recipe, infra adapter, and module. Stays current with the repo.
Or just tell Claude Code — "self-host X on Y" — and it'll match.
File an issue, don't open a PR. Issue templates cover three channels:
- Recipe feedback — the skill drafts this for you at end of deploy (sanitized; you opt in)
- Software nomination — request a recipe for an app the catalog doesn't have
- Method proposal — an upstream install method an existing recipe doesn't cover
An AI agent reads CLAUDE.md as its runbook, re-verifies every change against upstream docs, and patches the catalog. Why issues, not PRs? Central verification keeps the catalog consistent, and the skill sanitizes drafts before posting so credentials don't leak into commit history.
For how the catalog is maintained as a system (actors, data flow, state stores, quality gates), see ARCHITECTURE.md. For policy details (3-axis model, strict-doc-verification policy, two-tier coverage, sanitization rules), see CLAUDE.md. For project intent (why / who / success / non-goals), see BRD.md.
MIT — fork freely, attribution appreciated.