One command, or one tool call
vibe deploy uploads the folder, detects Node, Python, Go or a static site (or uses your Dockerfile), builds it in the cluster and waits until the app answers. Agents get the same through the MCP server: deploy_app returns the URL, or the error with a hint and the logs, so the agent fixes and retries on its own.
$ vibe deploy # connect your agent once$ claude mcp add vibedeploy --scope user -- vibe-mcp
Data that survives the next deploy
Containers start fresh on every deploy. Apps that keep a SQLite database or uploads ask for a volume and write to /data. It stays mounted across deploys and restarts, with a hard 2 GB cap so one app cannot fill the disk.
// vibe.json{ "name": "notes", "volume": true } ==> volume: 2 GB at /data ($DATA_DIR)
Your own domain, HTTPS included
Every app is live at name.tja.nrw with a certificate from the first deploy. Add your own domain in the dashboard, point a CNAME at the app and press Verify & Activate: the certificate is issued and renewed automatically, and HTTP always redirects to HTTPS.
CNAME app.example.com -> notes.tja.nrw app.example.com Activecertificate valid until 28 Jan 2027
Isolated, capped, and easy to watch
Each app runs in its own namespace with network isolation and fixed limits: 512 MB and half a CPU per app, 3 apps per team on Free and 15 on Pro. You see what is happening without kubectl: live logs that follow restarts and deploys, CPU and memory against the limit, and the real reason a container crashed.
$ vibe status notes✗ notes CrashLoopBackOff (OOMKilled) → used more than its 512Mi memory limit RAM ███████████████████░ 97% 497 MB / 512 MB