Welcome

omg turns a prompt into a real, running app — built, deployed, and live at its own URL in seconds. Every app runs fully isolated in its own sandbox, with a database, sign-in, storage, and an AI coding agent already wired in.

You can use the hosted omg.dev, or run the whole platform on your own infrastructure so your internal teams ship apps without anything leaving your network. This site shows how it works, and how to stand it up yourself.

How it fits together

The platform is the same handful of layers whether it's hosted or self-run. Here's the path a request takes — flip to omg hosted for the components we run in production, or all-in-one to collapse everything onto a single box behind a cloud load balancer:

Each layer maps to a small, proven component. This is what hosted omg.dev runs, and what provision.sh sets up on a self-hosted box:

Why run it yourself

Building this in-house means solving microVM isolation, snapshot/restore, zero-downtime deploys, and an AI coding loop — months of platform work before your first app ships. omg gives you all of it as one service:

• Hard parts, already solved. Firecracker isolation, full-rootfs snapshots, atomic versioned deploys with rollback, and litestream-replicated per-app SQLite are in the box.
• Nothing leaves your network. Code, data, and AI usage stay on your hardware. Point the coding agent at your own Claude subscription.
• One box, one script. No platform team. provision.sh stands up the whole stack; add a box when you need more capacity.

Self-host omg, end to end

Hosted omg is just one of these boxes. Run the same setup script on your own server and your internal teams build on your hardware, inside your network.

1 · Provision

Start with a fresh Ubuntu 22.04 server (virtualization enabled, a spare disk for sandbox storage). One script sets up storage, the sandbox runtime, the orchestrator, the base image, the system service, networking, and optional HTTPS:

git clone https://github.com/BennyKok/vibes /opt/vibes
cd /opt/vibes

# HTTPS via Caddy; omit DOMAIN for plain HTTP on :7070
DOMAIN=infra.your-co.internal bash apps/infra/deploy/provision.sh

The script writes its config to /etc/vibes/env and starts the orchestrator as a system service. Health-check it:

curl https://infra.your-co.internal/health

2 · Open a tunnel

Routing goes through a Cloudflare Tunnel, so the box never exposes an inbound port. provision.sh already wrote the tunnel config — finish the one-time auth:

cloudflared tunnel login
cloudflared tunnel create box-1     # paste the UUID into /etc/cloudflared/config.yml
systemctl enable --now cloudflared

3 · Mint a service token

Your dashboard authenticates to the orchestrator with a short service token. Mint it on your auth host — never over HTTP:

# on the auth host
cd /opt/vibes && bun run apps/auth/scripts/mint.ts svc:convex 31536000

4 · Point the dashboard at your box

Set three values in the dashboard backend. This sends apps to your box instead of the hosted fleet — no code changes:

VIBES_SANDBOX_PROVIDER=firecracker
VIBES_SANDBOX_URL=https://infra.your-co.internal
VIBES_INFRA_SERVICE_TOKEN=<jwt minted above>

To keep AI usage on your own Claude subscription, point the on-box LLM proxy at it in /etc/vibes/env. Need more capacity? Run provision.sh on another box with NODE_ID=box-2 — traffic routes to it automatically.

Hosted vs self-hosted

Where to start

• Architecture — the request path, edge to sandbox.
• Deploy flow — snapshot, build, go live.
• Auth — sign-in and service tokens.
• SDK overview — what your team builds on it.

For LLM agents: llms.txt indexes every page; llms-full.txt is the full docs as plain text.