One command, and it is on a server.
Give GATE a GitHub repository. One command clones it, registers it, and gives it a live address. You do not rent a server, make a directory, or set a permission, and running it twice is safe.
Hosting & deploys
Your app, live and looked after.
Point GATE at a repo and your app goes live on a real URL, with the servers, database, deploys, and SSL handled for you. Describe what it needs in one config file, push to your branch, and the change is live. No DevOps to hire.
How it works
From a repo to a live URL.
No servers to rent, no deploy pipeline to build, no certificates to chase. You bring the code and the config; GATE runs everything under it.
One file, in your repo.
A single gate.json names your services and whether you want a database, a cache, or file storage. That file plus your application code is the whole of what you write.
Containers, ports, routes, certificates.
Every container definition, allocated port, DNS record, certificate and proxy route is generated from that one file and kept outside your repository. You never write them, and you cannot hand-edit them, which is why they never drift.
Every push to your default branch.
Pushing ships it. The code is pulled, your database migrations run before the service starts, the containers rebuild, and the site is live. Each deploy is recorded with its status, its commit and how long it took.
What you get
Infrastructure you never have to touch.
App code and one JSON file
Everything else, the container definitions, the ports, the proxy routes and the certificates, is generated by GATE and lives outside your repository. This is not a convention you are trusted to follow: those files are not yours to edit.
PostgreSQL, MySQL or MongoDB
One word in the config gets you a real database, with PostgreSQL pinnable to the version you want and vector search available when you need it. A cache and S3-compatible file storage are declared the same way.
Wired, generated, or asked for
Connection strings, ports and the addresses your services use to reach each other are filled in for you. Anything named like a password or a token is generated as a long random value. Only genuine outside keys, a payment provider for instance, are typed in by a person.
The infrastructure follows the repo
Because every piece of infrastructure is derived from what is in your repository, undoing a bad deploy is undoing the commit. There is no separate console where your servers have quietly drifted away from your code.
Merged into one running system
A site can span more than one repository. Their configs merge into a single system sharing one database and one cache, so a separate frontend and backend is still one deploy, with each service reachable by the others automatically.
Hosted in the EU
Sites build and run on Stockholm-hosted, EU-resident infrastructure, consistent with GDPR.
How it fits
The place your agents' work goes live.
Hosting is where the building lands. The same coding agents that open pull requests deploy here, navigate the repo with codebase maps, tune the live design through visual editing, and run on the same platform as the rest of your business.
FAQ
Straight answers.
Do I need a DevOps person or a server?
No. You connect a repository and describe what the app needs in a gate.json. The servers, database, networking and certificates are GATE's side of the line, and the generated infrastructure files sit outside your repo where nobody can hand-edit them into a state your code does not describe.
How do deploys work?
A push to your default branch deploys. The webhook is installed when the site is set up, so there is nothing to wire afterwards: the code is pulled, migrations run before the service starts, containers rebuild, and the deploy is recorded with its status, commit and duration.
How do I undo a bad deploy?
You revert the commit and push. Since every container, route and certificate is generated from what is in the repository, moving the repository back moves the running system back with it. There is no separate rollback button, because there is no separate state to roll back.
Which databases can I use?
PostgreSQL, MySQL or MongoDB, declared in one word. PostgreSQL can be pinned to a major version and can carry vector search for AI features. A Redis cache and S3-compatible file storage are declared the same way, and the connection details are injected into your services for you.
What do I actually configure?
A gate.json in your repository: your services, and whether you want a database, a cache, storage or custom domains. Remove a domain from that file and its route and DNS record are torn down on the next deploy, so the file stays the truth rather than a starting point.
What do I need before I start?
A GitHub repository, and an owner of your GitHub organisation approving GATE's access once. After that it is self-service. External API keys, a payment provider or an email service, are entered by a person rather than generated, because only you have them.
Can the AI agents deploy it for me?
Yes. The same coding agents that open pull requests can stand the site up and deploy it, so work goes from idea to live without a separate handoff to whoever owns the servers.
Get your app live without the DevOps.
Invite-only while we onboard a small number of businesses. Request an invite and we'll be in touch.