Code from an AI
How to deploy a Bolt.new project yourself
In short
To deploy a Bolt.new project, export the code — download it as an archive or push it to a GitHub repository — and upload it to a platform that builds the project for you. Before that, fix what only worked inside the browser sandbox: the server has to listen on the port from the PORT environment variable, API keys have to move out of the code into secrets, and the frontend has to call the server at a real address. On Netrun you upload the archive or connect the repository, and the platform detects the stack, builds the project and gives you an HTTPS link.
The project is built in Bolt.new, the preview works, and now you want it online so the link opens for anyone. This is where you find out that the browser environment quietly did four things for you: it installed the dependencies, assigned the port, kept the frontend and the server on one address, and held the API keys outside the code. Outside the sandbox none of that is there, so a project that "worked a minute ago" often greets you with a blank page.
The usual route from here is long: rent a server, install Node.js, build the frontend, run the server as a background process, put a proxy in front of it and get a certificate. With Netrun you upload the code as an archive or connect a GitHub repository, and the platform detects the stack, builds the project and gives you a public HTTPS link. Still, spend ten minutes on the code first, or the deploy will run straight into the props that are gone.
Work out what actually runs#
A Bolt.new project usually has two parts: a frontend that compiles into static files for the browser, and a small server that serves the data. Open package.json and look at the scripts: if there is a server, that is what you deploy, and it should serve the built frontend itself. If there is no server and the whole project compiles into static files, it is simply a site and things are easier. Every other step depends on this answer, so start here.
Remove the hard-coded port#
The sandbox assigned the port for you, so the code often keeps a fixed number like 3000 or 5173. On a real server this is the number one reason a link does not open: the app listens somewhere other than expected. The server has to take its port from the PORT environment variable and bind to 0.0.0.0 rather than localhost. If an AI wrote the code, ask the same AI to make this change: it is a one-sentence request.
Connect the frontend and the server by real addresses#
In the browser environment both parts answered on the same address, so data requests are often written against the sandbox address or assume a neighbour in the same tab. The simplest working option is to keep the project as one unit: the server serves the built frontend and answers data requests, so there is one address and nothing to wire up. If the parts do end up as separate projects, the frontend should receive the server address as a build-time setting instead of carrying it inside the code. Otherwise the page loads after deploy but stays empty, because it asks for data at an address that no longer exists.
Move API keys out of the code into secrets#
AI tools happily paste keys for external services straight into the code, and in a Bolt.new project they usually stay there. Take them out of the files and read them from environment variables: during setup Netrun asks for those values and passes them in encrypted, so they never sit in the archive or the repository. Check the frontend separately, because anything shipped to the browser is visible to every visitor, which means secret keys belong on the server side.
Decide where the data will live#
If the project had a database that lived inside the browser sandbox, it does not exist online and the data needs a real home. Keep the database file and anything the app writes itself in the project persistent folder /data: what goes there survives a code update and a restart, while files next to the code are recreated on every deploy. If there is a lot of data, or several parts of the project use it, run a database as a separate service next to the app with docker-compose, or use an external one.
Pack a clean archive and upload the code#
There are two ways to get the code out of Bolt.new: download it as an archive or push it to a GitHub repository. Leave node_modules and the build folder out of the archive, because the platform installs the dependencies and builds the frontend during deploy. Then upload the archive to Netrun or connect the repository, private ones included: the platform detects the stack, builds the project and issues a public HTTPS link. Build logs stream in your dashboard, so an error shows up as a reason instead of a blank page.
A Bolt.new project stops being a browser tab the moment it gets a link of its own. Almost everything that breaks during the move is a leftover of the sandbox: a port baked into the code, an address of a neighbour that no longer exists, a key in plain sight and a database with nowhere to live. Fix those four things, and the build, HTTPS and restarts on failure are handled for you. Upload your code to Netrun, or run it through the free project check first.
Common questions
Can I host a Bolt app anywhere, or only where the service suggests?
The code is yours: you can download it as an archive or push it to a GitHub repository and deploy it wherever you like. Netrun accepts both an archive and a repository, and there is no lock-in to the environment the code was written in.
Why does the project work in the Bolt preview but show a blank page after deploy?
Usually the frontend loaded fine but asks for data at an address that does not exist online, because in the sandbox both parts answered on the same address. The second common cause is a server listening on a hard-coded port instead of the one from the environment. Both show up in the deploy logs and in the browser console.
Do I need GitHub to export a Bolt project and deploy it?
No. Downloading the code as an archive and uploading it is enough, so you need neither git nor a terminal. GitHub is more convenient if you plan to keep editing the project and update it from the repository with one action in your dashboard.
What do I do with the database from a Bolt project?
If the database lived inside the browser sandbox, it does not exist online and the data has to be placed again. A small file-based database is fine in the persistent /data folder, where the contents survive code updates. For anything heavier, run a database as a separate service with docker-compose: in that kind of project the persistent storage is the volume from your own file rather than /data.
Do I have to build the frontend myself before uploading?
No, the build happens on the platform. Do not put the build folder or node_modules into the archive: they only bloat the upload, and the built version is regenerated from the sources anyway.
My API keys stopped working after the move. Why?
They were stored in the environment settings rather than in the code, so they did not travel with the archive. Set them again during project setup: the platform asks for the values and injects them into environment variables in encrypted form.
What about React, Vue, Next.js, Nuxt, Svelte or Astro?
Yes, all of them work. Upload the source code with your package.json — you do not need to build the project yourself or include the built output, the build happens on our side. If your framework can produce both static pages and a server build, either works: in server mode the app should listen on the port from the environment variable. One important detail: values baked into the built front-end are visible to any visitor, so keep real keys on the server side.
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.
How do I update the code of a project that is already published?
Open the project and upload a new version or update it from GitHub. The link stays the same, and your data is kept as long as it lives in persistent storage — the /data folder or a volume from your compose file.
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.