GATE Documentation

A GATE project is an app built from a GitHub repo, with the infrastructure managed for you. You bring the application code and a small config file; GATE handles the parts that usually slow a build down — containers, web server, DNS, TLS, ports, and secrets.

The guiding idea for GATE-hosted projects is simple: you write app code plus a gate.json file, and GATE owns all the infrastructure. Your bot never hand-writes Dockerfiles, compose files, web-server config, or port assignments. GATE reads your config and generates and runs all of that for you.

The two ways an app can run

GATE supports two distinct hosting targets. They differ mainly in who owns and pays for the server.

	GATE-hosted	Your own Hetzner box
Who pays	GATE (development only — not for customer production)	You (your own account and bill)
Who runs the infra	GATE generates and operates everything	Your bot provisions and operates a server you own
What you provide	App code + `gate.json`	App code; the bot sets up the server
Web server / TLS	Generated by GATE	Caddy on the host, TLS via Let's Encrypt
Autodeploy	Built-in GitHub webhook	A webhook receiver running on your box

GATE-hosted

GATE runs your app inside its own development environment. You describe what the app needs in gate.json, push your code, and GATE provisions and deploys it. This is the default for new GATE products, and it is meant for development rather than customer production.

Your own Hetzner box

When you want production hosting you own, the bot can set up a server on Hetzner Cloud in your name.

You pay for it directly.

Hetzner is the default recommendation, but the server model is provider-agnostic — DigitalOcean, AWS, or an existing external box you register work the same way.

The bot provisions and hardens the box, deploys the app, and operates it long-term — but GATE itself never runs on your server.

This is the path to use when you need a production app on infrastructure you control.

`gate.json`: describe what you need

gate.json is the declarative config file in your repo. Instead of wiring infrastructure by hand, you describe what the app needs and GATE provisions it:

services — your backend and frontend apps
database — Postgres, MySQL, or Mongo
cache — Redis
storage — S3-style object storage
smtp — development mail capture
plus per-service volumes and custom domains

GATE reads this file and generates the container setup, web-server routes, DNS, ports, and environment variables from it. See the gate.json reference for the full schema.

Deploy automatically on git push

Apps can deploy automatically when you push to your deploy branch — this is called autodeploy.

On a GATE-hosted project, a built-in GitHub webhook picks up the push and runs the deploy.

On your own box, a small webhook receiver on the server does the same.

Either way, the goal is the same: push your code, and the live app updates.

Where your app's URL comes from

Each service in a GATE-hosted project gets a public URL of the form {service}.{org}.<your GATE base domain> — for example, myapp.acme.example.com using your GATE base domain. The base domain is deployment-level configuration set by whoever runs your GATE server (there is deliberately no default), so it varies per install.

Code sessions are how a bot does the actual building inside a project. See Sessions for how that work happens.

The step-by-step setup — creating the project, authoring gate.json, and shipping — lives in Build and deploy an app.