- Deploying is a git job, not an AI job. If your agent produced a repository, any host that builds from git can run it.
- Secrets such as API keys go in environment variables on the host, never in the repository.
- If the app stores anything, it needs a database. A file on the app's own disk is lost on the next deploy.
- Keep the database off the public internet, or open it only to IP addresses you name.
- Preview each change as a running site before you merge it, and keep the previous commit one deploy away.
How do you deploy an app that an 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. Set its environment variables, add a database if it stores anything, keep that database private, and point your domain at it.
Deploying is a git job, not an AI job. Your agent produced a folder of files with a package.json or a Dockerfile in it (a recipe that tells a server how to build and run the app). A developer would have produced the same thing, so every normal way to deploy is open to you. What code written faster than you can read it needs is two things put in place on purpose: knowing what the app touches, and a way to undo a bad change.
What do you need before you deploy?
Four things. You probably have three already.
- 1A git repository. If your agent worked on your machine, 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.
- 2A build that works on a clean machine. Clone the repository into a fresh folder and run the build once. An app that only builds on the laptop it was written on is the most common reason a first deploy fails.
- 3A list of the secrets it needs. Search the code for process.env or getenv and write down every name you find. These become environment variables on the host.
- 4An answer to one question: does it store anything? If the app remembers users, orders, posts or uploads, it needs a database. If it only shows pages, it does not.
Check for committed secrets before the first push
Agents sometimes write an API key straight into a config file because it makes the code run at once. Search the repository for your keys before you push, and replace any key you find committed. A public repository can be found and scanned within minutes.
On G7Cloud app hosting the build is done for you, with presets for 14 frameworks (Next.js, Astro, Nuxt, SvelteKit, Remix and more) and a Dockerfile option for anything else, including a Dockerfile in a sub-folder. You pick the repository and the branch. Once the webhook is connected, every push to that branch builds and deploys. Each app gets a free address at yourapp.apps.g7cloud.com, and you can add your own domain with a free SSL certificate.
How do you set environment variables for the app?
Environment variables are the settings and secrets your app reads when it runs, such as API keys and the address of its database. Set them on the host, not in the repository. A leaked repository then does not leak your keys, and you can change a value without changing the code.
On G7Cloud you set them for each site in the dashboard, one key at a time, and saving one key never touches the others. They reach the app when it runs, and with a framework preset they are available while it builds too. Hosting a Next.js app? Next.js hosting covers the details.
Next.js reads NEXT_PUBLIC_ values at build time
Next.js copies any variable whose name starts with NEXT_PUBLIC_ into the code it sends to the browser, and it does this while the app builds. Change one and you need to redeploy before visitors see the new value. Anyone can read a NEXT_PUBLIC_ value, so never put a secret in one.
Does your AI-built app need a database?
Yes, if it has a login, a form that saves anything, a basket, a dashboard or an admin screen. Agents often set these up with SQLite, a database kept in a single file. That works on your laptop. On a host that rebuilds the app on every deploy, as G7Cloud does, the file and everything in it is gone after the next deploy.
The same goes for uploaded files. Decide where they will live before launch, because the app's own disk does not keep them between deploys. Then pick a database engine by what the app does.
| You are storing | Use | Why |
|---|---|---|
| Users, orders, posts, anything you search or sort | PostgreSQL | The default database for apps. Every framework has a well-tested way to talk to it. |
| Sessions, a cache, a job queue, rate limits | Redis | Kept in memory, so it is fast. Losing it costs you a slow page, not a customer's order. |
| Events, logs, product analytics | ClickHouse | Built to count huge numbers of rows quickly. Wrong for orders, right for asking what happened last Tuesday. |
Most apps need the first one. Some need the first two. Very few need all three on day one.
Start with one database. An agent will wire up three if you ask, and you will then be running three things you do not yet need.
On G7Cloud you can add PostgreSQL 15, Redis 7 and ClickHouse as managed databases on any paid plan. Each runs in its own container and has scheduled backups you restore from the dashboard. When you attach one to a site, the dashboard offers to fill in the matching environment variable (DATABASE_URL, REDIS_URL or CLICKHOUSE_URL). Each database is priced on its own by the memory you give it, per GB a month with a 1 GB minimum. A live standby copy that takes over if a PostgreSQL or Redis database fails doubles that price. The pricing page has the figures.
How do you keep the database off the public internet?
Do not give the database a public address unless you need one. The quick way to reach a database is to open it to the internet and rely on the password, but a password is one mistake away from being the only thing protecting your customers' data. It turns up in a log, a screenshot or a repository your agent made public by accident. A database with no public address gives an attacker nothing to try.
Your app reaches the database privately. If you must connect from outside, allow only the IP addresses you name.
On G7Cloud a managed database has no public address until you switch one on. When you do, only the IP addresses on your allowlist can connect, and the connection is encrypted. On Pro, Studio and Agency the database can also join your private network, which only your own sites, databases and devices are on. Add your laptop to it and your local tools reach the database with no public address at all.
How do you check a change before it goes live?
Run it rather than read it. When an agent writes four hundred lines in a minute, reading every line stops being realistic. Use a preview copy instead: open a pull request, and that branch is built and deployed at its own address, apart from the live site. Click the thing the change was meant to fix, then merge.
Ask for small pull requests
An agent will write one enormous change if you let it. Ask for one change per pull request, so you can tell which change caused what.
Keep the way back open too. Each deploy is built from a commit, so going back means deploying the previous commit again. Your data sits in a separate database, so rolling back the code does not lose the orders that came in while the bad version was live.
On G7Cloud you can deploy any earlier commit from the dashboard. Deploys run one at a time for each site, and when several pushes arrive together the newest wins. Preview copies for every pull request come with Pro, Studio, Agency, Solo Plus and Solo HA, and the developer tools page shows how they work.
What will it cost when the app gets busy?
Settle this before launch, while you still do not know how the app behaves under load. Usage billing charges per request, per function call or per gigabyte sent. It is cheap while nothing is happening, and it is how a good launch, or a crawler hitting a slow page, turns into a bill nobody planned. A fixed price stays the same whatever the traffic does.
For a new app a fixed price is easier to live with, because the number you budget is the number you pay. G7Cloud hosting starts at £12/month for one app with its domain, email, DNS and daily backups. A managed database is added on top, priced per GB of memory a month. Pro, at £59/month, adds preview copies for pull requests and the private network. The price you sign up at is the price you renew at, and every plan and database price is on the pricing page.
What should you do in the week after launch?
Four things, in this order. None takes long, and each closes a gap you only notice when it is too late.
- 1Prove a backup restores. A backup nobody has restored is a guess. Restore one into a scratch copy and look at the data, so you know the steps before you need them.
- 2Turn on uptime monitoring. You want to hear the app is down from a monitor, not from a customer. Run the check from outside your own servers, because a check inside them cannot see that the outside world has lost its way in.
- 3Move every secret out of the repository. If anything is still committed, replace the key and set it as an environment variable.
- 4Write down what the app talks to: which database, which outside service, which webhook. You did not type those connections, so you do not carry them in your head. Ten minutes now saves an afternoon the first time something breaks.
The whole path, from repository to databases to what each plan includes, is on the hosting for apps built with AI agents page. G7Cloud is hosted in the UK, on servers we own and run ourselves.
Frequently asked questions
How do I deploy an app that an AI agent built?
Push the code to GitHub, GitLab or Bitbucket and connect the repository to a host that builds from git. The host installs the dependencies, runs the build and starts the app. Set its environment variables, add a database if it stores anything, keep that database private, and point your domain at it.
Where should I put API keys and other secrets?
In environment variables on the host, never in the repository. On G7Cloud you set them for each site in the dashboard, one key at a time. In a Next.js app, anything named NEXT_PUBLIC_ is visible in the browser and is read at build time, so keep secrets out of those and redeploy after changing one.
Why is SQLite a problem for a deployed app?
SQLite keeps the whole database in one file on the app's own disk. A host that rebuilds the app on every deploy, as G7Cloud does, starts each version with a fresh disk, so the file is lost. It is fine on your laptop, but anything a user creates should live in a database that runs separately from the app.
Should I let my AI agent deploy the app itself?
You can, with an API key limited to what the job needs. Do the first deploy by hand so you understand the pieces, then hand over the repetitive parts once you know the shape.
How do I roll back a bad change?
Deploy the previous commit again. Each deploy is built from git, so the earlier version is still there, and on G7Cloud you can pick it in the dashboard. Your database is separate from the code, so the data created while the bad version was live survives the rollback.
About G7Cloud Engineering
Articles written by the engineers who build and run G7Cloud: UK managed hosting and the AI Website Builder. We write about what we operate every day: containers, backups, databases, and the small-business websites that run on them.
More about G7Cloud →
