Build & deploy an app

You describe what you want in plain language. Your bot turns that into a plan, builds it through code sessions, and ships it to a URL. This page walks the whole arc — idea to live app — and shows what infrastructure GATE can stand up for you along the way.

Prerequisites

Before a build can run, an org owner needs a few things in place:

• A GitHub repo connected to the org that will own the app. A project must point at a repo before it can deploy.
• The GATE GitHub App installed on the org (slug gate-projects). Without it, your bot can't clone the repo when it starts a project — setup fails at the git-clone step (Error 400: Git clone failed).
• The GATE OAuth App approved by the org owner, if the org enforces OAuth App access restrictions. Without it, user-attributed git pushes return a 403 / "OAuth App access restrictions" error.

The two GitHub switches are independent — a fresh org usually needs both, and both are installed by an org owner.

Steps

1. Describe your goal to your bot. Pitch what you want in chat: "build me a booking app for my studio." Your bot reads the build router first, matches your pitch to a scenario (new product to a live URL, a big feature in an existing project, a landing page), and pulls the right chain of steps. You do not pick the path; the router does.

2. The bot creates a plan. It walks you through a conversation and writes a MASTER-PLAN.md (the what — vision, flows, data model, hosting, verification rules) plus a CLAUDE.md (the how — stack, conventions, guardrails). The plan has to clear a build-readiness gate before any code is written: measurable verification rules, guardrails, a ranked feature list, and a resolved stack must all be present. The bot will not guess a stack to keep moving — unresolved items surface as open questions for you to answer.

3. The bot builds via code sessions. Once the plan is ready, the bot registers the project and runs a build loop. Each slice of work becomes a GitHub issue, then a branch in its own worktree, then a pull request that the bot reviews and merges. The build is autonomous — it builds, tests, verifies, finds gaps, and iterates. You are never pinged; you read PROGRESS.md when you want a status, and you say "halt" when you want it to stop. See sessions for how chat and code sessions divide the work.

4. Choose where it runs. GATE separates two worlds — the workshop and the factory floor:

   Target	Best for	Who pays
   GATE-hosted	Development, previews, internal tools	GATE (dev only)
   Hetzner (your own box)	Production apps you ship to real users	You (your account, your bill)

   On GATE-hosted projects you declare infrastructure in a gate.json file and GATE generates all the Docker, Caddy, DNS, and TLS plumbing — you write app code plus gate.json and nothing else. Supported primitives:

   • Services (backend / frontend), on the bun, node, or php runtimes
   • Database: Postgres (with version pinning, the vector extension, and init scripts), MySQL, or Mongo
   • Cache: Redis
   • Object storage: S3-compatible buckets via MinIO (public or private)
   • Custom domains: per-service FQDNs, with Cloudflare DNS and Caddy routes provisioned automatically
   • Dev email capture via Mailpit (smtp: "capture") — for development only, never production

   For production, your bot provisions and operates a server on your own Hetzner Cloud account (default recommendation ~CPX31, ~€13/mo). It runs a Caddy + Docker Compose stack, hardens the box, and points DNS at it. See the gate.json reference for the full schema.

   GATE does not host customer production apps on its own infrastructure for free. GATE is the development environment; your own Hetzner box is where production lives. If you ask the bot to "just host it on your server," the answer is no unless you have a paid arrangement.

5. Deploy, and turn on push-to-live. On GATE-hosted projects, a deploy generates the infra from gate.json, builds the containers, runs migrations, and serves the app. With the GitHub App installed, a push-to-deploy webhook is wired automatically when the repo is added to the project. From then on, every push to the deploy branch deploys — merging a PR counts, since the merge lands as a push. There is no mode to pick; pushes to other branches are recorded but don't deploy. On a Hetzner box, autodeploy uses a small webhook receiver on the server that validates the request and runs git pull plus your deploy command. Either way, the bot finishes by confirming the URL actually serves a real, working page — not just that the deploy "succeeded."

What's supported today — honestly

• Greenfield products and big features are the proven paths. Building a brand-new tool inside GATE, one-off fixes with no build loop, and hosting an existing app on a customer box are coming soon — the steps are sketched but not yet battle-tested.
• Hetzner push-to-live is the shipped template going forward, but it's the newer path and hasn't been run in production yet, so expect some rough edges.
• App URLs follow {service}.{org}.<your GATE base domain>. The base domain is set per GATE deployment, so a service lands at something like myapp.acme.example.com.

Going deeper

See Projects & hosting for how projects, deploys, and the two hosting worlds fit together, Sessions for the chat-vs-code-session model behind the build loop, and the gate.json reference for every infrastructure key you can declare.