How to Deploy an App Your AI Agent Built

Push the code to GitHub, GitLab or Bitbucket, then connect that repository to a host that builds from git. The host installs the dependencies, runs the build and starts the app. Add a database if the app stores anything, put it on a private network, and point your domain at the result.

The reason this is shorter than you expect is that deploying is a git problem, not an AI problem. Your agent produced a folder of files with a package.json or a Dockerfile in it. That is the same artefact a human developer would have produced, and every normal deployment path is open to you. Nothing downstream needs to know how the code was written.

What does change is the order you do things in. When code arrives faster than you can read it, the parts you would normally get for free through slow, careful work, knowing what the app touches and being able to undo a bad change, have to be put in deliberately. The rest of this guide is those parts.

Four things, and you probably have three of them already.

1. 1A git repository. If your agent worked locally, run git init, commit, and push to a new empty repository. If it worked in a browser tool, use that tool's export or GitHub connection.
2. 2A build that succeeds on a clean machine. Run the build once yourself from a fresh clone. An app that only builds on the laptop it was written on is the single most common reason a first deploy fails.
3. 3A list of the secrets it needs. Grep the code for process.env or getenv and write down every name you find. These become environment variables on the host, not committed files.
4. 4An answer to whether it stores anything. If the app remembers users, orders, posts or uploads, it needs a database. If it only renders pages, it does not.

On G7Cloud app hosting the build step is handled for you across 14 framework presets: Next.js, Astro, Nuxt, SvelteKit, Remix, Vite, Bun, Strapi, Medusa, Payload and more, plus a custom Docker option for anything the presets do not cover. You choose the repository and the branch, and each push builds and deploys.

If the app has a login, a form that saves anything, a shopping basket, a dashboard or an admin screen, then yes. Agents frequently scaffold these with a local SQLite file, which works beautifully on your laptop and quietly loses everything the first time the container restarts.

Pick the engine by what the app actually does rather than by what sounds impressive.

All three are available as managed database instances, each in its own container with memory and CPU you set, and each with its own backups. The connection string is handed to your app as an environment variable, so the code does not need to know where the database physically is.

Put the app and the database on the same private network, and do not give the database a public address at all. This is the single highest-value thing on this page, and it is the step most often skipped, because the quick way to make a database reachable is to open its port and rely on the password.

A password is one mistake away from being the only thing between the internet and your customers' data. It appears in a log, in a screenshot, in a committed config file, or in a repository your agent made public by accident. A database with no public route does not have that failure mode, because there is nothing to guess at.

On G7Cloud this happens as part of adding the database: attach it to a site and it joins that site's private network in the same step, on a subnet that belongs to you alone. The app connects to a private address. When you want to inspect the data yourself, you add a peer for your laptop and your local tools reach it directly.

Run it, do not read it. When an agent produces four hundred lines in a minute, line-by-line review stops being realistic. The practical substitute is to open the change as a working site and click the thing it was supposed to fix.

The mechanism is a preview environment: open a pull request and that branch gets built and deployed to its own URL, separate from production. You check the URL, and only then merge. It costs you a minute and it catches the class of problem that reads perfectly well as code.

Keep the way back open too. Because deployments are built from commits, going back means redeploying the previous commit, which is one action. Your data lives in a separate database and is untouched by a code rollback, so reverting a bad deploy does not cost you the orders that came in while it was live. Preview environments and one-action rollback are both covered in the developer tooling.

This is worth settling before launch rather than after, because the two common billing models fail in opposite directions and you are about to run an application whose behaviour under load you do not know yet.

Usage billing charges per request, per function invocation or per gigabyte transferred. It is cheap while nothing is happening, which is most of the time, and it is the model that produces the invoice nobody planned for when a launch goes well or a crawler discovers an expensive endpoint. Fixed pricing charges the same amount whatever the traffic does, so a good day and a quiet day cost the same.

For a new app the fixed price is usually the easier one to live with, because the number you budget is the number you pay while you are still learning what the thing does. G7Cloud hosting starts at £12/month for a single app with its domain, email, DNS and daily backups. Preview environments and private networking come in at £59/month. The full ladder is on the pricing page.

Four things, in this order. None of them takes long, and each one closes a gap that only becomes visible when it is too late to close.

1. 1Prove a backup restores. A backup nobody has restored is a guess. Restore one into a scratch copy and look at the data. On G7Cloud every backup is restored onto a test server overnight, so this is already being done for you, but check you can do it on demand too.
2. 2Turn on uptime monitoring. You want to hear that the app is down from a monitor, not from a customer. Checks should run from outside your own infrastructure, because a check that runs inside it cannot tell you that the outside world has lost its route in.
3. 3Move every secret out of the repository. If anything is still committed, rotate it and set it as an environment variable instead.
4. 4Write down what the app talks to. Which database, which third-party API, which webhook. This takes ten minutes now and saves an afternoon the first time something breaks and you cannot remember what depends on what.

That last one matters more with agent-written code than it does otherwise. You did not type the integrations, so you do not carry them in your head the way you would if you had. A short written list is the cheapest possible substitute for that memory.

If you want the whole path in one place, from repository through databases and private networking to what is included at each price, it is on the hosting for apps built with AI agents page. Backup behaviour in detail, including how restores are tested, is on the backups page.