GATE's hosting runs your app from one gate.json file in its repository: Bun, Node 20, PHP 8.2 or your own Dockerfile, with PostgreSQL 16 to 18, MySQL or MongoDB, Redis, S3-compatible storage and your own domains with HTTPS. Every push to the deploy branch goes live, migrations first, and is stored as a signed release on servers in Germany and Finland. No GitHub account? GATE keeps the code in a private repository for you.
No servers to rent, no pipeline to build and no certificates to chase. You bring the code and one config file, and GATE runs everything under it.
Point GATE at your GitHub repository, approved once by an owner of your GitHub organisation, or have GATE create a private repository for you. That one can move to your own GitHub later.
A gate.json in the repo names your services and what they run on, Bun, Node or PHP, or your own Dockerfile, and whether you want a database, a cache, file storage or your own domains.
Containers, ports, routes and HTTPS certificates are generated from that file and kept outside your repo, so they never drift from your code.
Every push to your deploy branch ships: the code is pulled, migrations run before the service starts, and the deploy is stored as a signed release, logged with its commit and how long it took.
Every service gets a health check on its own port, and one that fails it twice in a row is restarted automatically.
Everything that runs is generated from your repository, so the live system can't drift away from your code.
Whoever pushes, a person or your agent.
A word or two in gate.json for each, wired into your services automatically.
PostgreSQL 16, 17 or 18, with vector search when you need it, or your own image such as TimescaleDB. Its data sits on disk beside the site, never open to the internet.
Declare a cache and every service gets its address, with nothing to paste.
Public or private buckets, created on every deploy and kept as plain files beside the database, with the keys injected into your services.
List a domain on a service and GATE routes it with a certificate, or give every customer a subdomain of their own. Take a domain out of the file and its route comes down.
One line gives your app a mail catcher: the emails it sends land in an inbox you open in the browser, not in real people's.
A frontend and a backend in separate repositories deploy as one system, sharing one database and one cache.
Three ways to get an app online, side by side.
| What you compare | A server of your own | A managed hosting platform | GATE's hosting |
|---|---|---|---|
| Setup | Install and patch everything yourself | Connect a repo and configure the platform | One gate.json in the repo, which your agent can write |
| Database | You install and run it | Often a separate service to connect | Declared in gate.json, credentials filled in |
| Deploys | Scripts you write and keep working | On push, set up per platform | Every push to the deploy branch, migrations first |
| Who runs it | You | You, through the platform's dashboard | Your agent sets it up, deploys and reads the logs |
| Where it runs | Wherever you rent | The platform's regions | GATE's servers in Germany and Finland |
Tell your agent what the app needs and where it should live. It writes the gate.json, sets the site up and deploys it, and when a deploy fails it's the one reading the logs.
Meet your agentsNo. With GATE, a company connects a repository, or lets GATE keep one, and describes what the app needs in a gate.json file. Servers, the database, networking and HTTPS certificates are GATE's side of the line, on GATE's servers in Germany and Finland, and the generated infrastructure lives outside the repository and is rebuilt from it on every deploy.
No. A company without GitHub gets a private repository that GATE creates in its own GitHub organisation, with access to that one repository and nothing else. Deploys work the same as for any other repository. When the company wants the code under its own GitHub account, the repository is transferred there and GATE points the site at its new place.
Every push to the deploy branch deploys, merged pull requests included. GATE checks GitHub's signature on the push, pulls the code, runs migrations before the service starts, rebuilds the containers, stores the deploy as a signed release and logs its commit and how long it took. A tampered or unsigned release is refused before anything starts.
By default, revert the commit and push: everything that runs on GATE is generated from the repository, so moving the repository back moves the app back. A site set to GATE's stable track can also roll back to the newest stable release with one command, unless a migration in between is marked irreversible; then the fix goes forward instead.
GATE generates the image for Bun, the default, Node 20 or PHP 8.2 with Apache, serving Vite, Next.js, Remix or a plain server, with extra system packages or PHP extensions when the app needs them. Any other stack runs from the repository's own Dockerfile and gets the same domains, HTTPS, health checks and site secrets as a generated image.
PostgreSQL, MySQL or MongoDB. On GATE, PostgreSQL defaults to version 16 and can be pinned to 17 or 18, carry the vector extension for AI features or run from a custom image such as TimescaleDB. A Redis cache and S3-compatible file storage with public or private buckets are declared the same way, and GATE fills in the connection details for every service.
Every service on GATE gets a health check on its own port, and a service that fails it twice in a row is restarted automatically. The check can point at a path such as /healthz or be switched off for a service that does not speak HTTP, and the company's agent can read the service's logs when something goes wrong.
GATE's hosting does not spin up a preview environment for each pull request or add copies of a service under load: each service runs as one container from the deploy branch. File storage has no web console, so objects are managed with any S3 client. Outside keys, such as a payment provider's, are entered by a person, because only the company has them.
GATE is invite only while GATE Intelligence onboards a small number of businesses at a time. After the invite, a company asks its agent to put the app online: the agent creates the site from an existing repository or a new private one, writes the gate.json and deploys. A new business website starts from mockups the company has approved first.
Invite only while we onboard a small number of businesses.