Code from an AI
Google AI Studio app: how to host it without Cloud Run
In short
You can host a Google AI Studio app without Cloud Run: download it as a ZIP or sync it to GitHub, then publish it on any host that runs Node.js. The one rule is that the Gemini API key must live on the server in the GEMINI_API_KEY variable, not in the page code, because anything shipped to the frontend can be read by every visitor. Inside AI Studio the key is injected into the server side for you, while anywhere else you have to set it in your host settings. On Netrun that is what the Secrets tab is for, and the project is uploaded as an archive or from GitHub.
- Build mode in Google AI Studio creates a web app with a React frontend by default and a Node.js server side.
- Inside AI Studio the Gemini API key is injected only into the server side of the app and never reaches the code the browser sees.
- An AI Studio app can be downloaded as a ZIP or linked to a GitHub repository, and when it runs outside AI Studio the GEMINI_API_KEY variable is set in the host settings.
- A key injected into the frontend at build time, for example through define in vite.config, ends up as plain text in the site JS files and is visible to every visitor.
- A standard publish from AI Studio to Cloud Run requires a Google Cloud project with billing enabled, while the Starter Tier lets eligible accounts publish up to two apps without billing.
In Google AI Studio you can describe an app in plain words and get a working prototype with Gemini inside a minute later: a chat assistant, an image generator, a document processor. Everything works inside AI Studio, and then comes the question of how to put the app on an address of your own. The publish button in AI Studio leads to Cloud Run, which means a Google Cloud project with usage-based billing; without billing, eligible accounts can publish at most two apps, and that route does not suit everyone.
An AI Studio app is an ordinary React and Node.js project, and it can be published on any host that runs Node.js. There is one catch, and it is a serious one: the Gemini API key. While the app lives in AI Studio the key is hidden on the server, but during a move it is easy to hand it to every visitor by accident. Below is how to avoid that. Projects from Lovable and v0 have a similar story.
| Option | Pros | Cons |
|---|---|---|
| Cloud Run straight from AI Studio | One-click publishing, the key is on the server from the start, an address like name.ai.studio | Needs a Google Cloud project with billing and a usage-based bill; without billing, up to two apps and not for every account |
| Sharing inside AI Studio | Nothing to set up, the key stays hidden | The app lives inside AI Studio, with no address or domain of its own |
| A static-only host | Simple and often free | The server side does not run, and a key in the frontend is visible to everyone |
| Netrun | ZIP or GitHub, the Node.js server runs, the key goes in the Secrets tab, payment by Russian card | On the free plan the site sleeps with no visitors, custom domains need Pro, no automatic publish on git push |
| Your own VPS | Full control over the server | You set up Node.js, HTTPS, autostart and updates yourself |
Export the code from AI Studio#
In Build mode, download the app as a ZIP or link it to a GitHub repository: the sync works both ways, so later changes from AI Studio are easy to pull. The archive is handy if you want to publish right now, GitHub if you plan to keep working on the app. Inside you will usually find React frontend files, a Node.js server side and a package.json with the dependencies. A .env file with the key may not be in the archive at all, and you will have to set the key again anyway.
Find where the key lives in the code#
Search the project for GEMINI_API_KEY and API_KEY. If the key is read in a server file through process.env, you are fine: it stays on the server. If requests to Gemini are sent straight from React components, or the key is injected at build time through define in vite.config, it ends up as plain text in the site JS files, and anyone who opens the developer tools can read it. This shows up in projects created before AI Studio added a server side, and in code that was edited by hand.
Move Gemini requests to the server#
If the key turned out to be in the frontend, ask AI Studio itself or any other AI model: move all Gemini requests to the server side, read the key from process.env.GEMINI_API_KEY, and have the frontend call its own endpoint such as /api/generate. You end up with a small proxy server: the browser sends it the text, the server adds the key and asks Gemini. The same server can serve the built frontend files, so the whole app is a single project.
Check how the server starts#
package.json should have a start command that launches the server, and a build command if the frontend needs building. The server must listen on 0.0.0.0 and the port from the PORT variable, not on a fixed localhost port, otherwise the app will not open through the link. If in doubt, run the folder through the free Netrun check: it works without signing up and shows what the platform understood about the project.
Add the key to secrets and publish#
Upload the archive or connect the GitHub repository, and Netrun will detect Node.js and build the project. In the Secrets tab, add a GEMINI_API_KEY variable with your key: it is stored encrypted there and passed to the server as an environment variable. After editing secrets, publish again so the server picks up the key. If the key was ever exposed in public code, create a new one in AI Studio and delete the old one.
Keep an eye on key usage#
Every visitor request to Gemini goes through your key, so the limits and the bill are yours too. For a public app it is worth adding simple guards: a few requests per minute per address at most, sign-in for regular users, a sensible input length. Key usage is visible in Google AI Studio, so take a look a day or two after publishing. The server logs in your Netrun dashboard will also show if someone is sending requests in bulk.
Cloud Run is not the only way to publish a Google AI Studio app: it is an ordinary React and Node.js project, and it runs on any host that runs Node.js. The one thing you cannot skip is keeping the Gemini API key on the server rather than in the page code. On Netrun the project is uploaded as an archive or from GitHub, the key is kept in the Secrets tab, and an HTTPS link is issued right away. On the free plan the site sleeps without visitors and wakes up when opened, while running without pauses and on your own domain comes with Pro. Try Netrun.
Common questions
Can I publish a Google AI Studio app without Cloud Run?
Yes. Download it as a ZIP or link it to GitHub and publish it on any host that runs Node.js. The Gemini API key is then set in the host settings as the GEMINI_API_KEY variable. Cloud Run is just the shortest path from the AI Studio interface, not a requirement.
Why is it dangerous to keep the Gemini API key in the frontend?
Everything in the page code is downloaded to every visitor’s browser, and the key can be read in a minute with the developer tools. With your key, anyone can send requests at your expense and use up your limits. That is why the server sends the Gemini requests, and the browser only talks to the server.
What if the key has already ended up on a published site?
Treat it as stolen. Create a new key in Google AI Studio, delete the old one, move the Gemini requests to the server and put the new key in your host settings. Rebuild and republish the site so the old key is gone from its files.
Will Google sign-in work if the app uses Firebase?
Yes, Firebase stays with Google and works from any host. For sign-in with Firebase Authentication, add the new site address to the Authorized domains list in the Firebase console, otherwise the sign-in window will refuse. Do the same after connecting your own domain.
Why does the app work in AI Studio but say the key is missing on my host?
Inside AI Studio the key is injected automatically, but it is not part of the downloaded archive. On the new host, set the GEMINI_API_KEY variable in the project settings, which on Netrun is the Secrets tab, and publish the project again. The variable name has to match the one the code reads.
Where do I set tokens and other secret values?
Every project has a Secrets tab where you set the values from your code — for example the token from BotFather. We store them encrypted: you can see the variable names, but the values are shown to no one, including you.
Are my tokens and secrets safe?
Yes. Tokens, access keys and values from your code are stored encrypted and are never shown in plain text.
Does the project update itself when GitHub changes?
No — publishing a new version is your call: open the project and update it from GitHub, or upload a new archive. That way a stray commit does not go straight to your users. The link stays the same after an update, and data in persistent storage is kept.