How to host a Bolt.new app on your own VPS

You built something in Bolt.new, it works in the preview, and now the hard part is not the app — it is turning that preview into a real website people can visit.

Short version: To host a Bolt.new app on your own server, you export or connect the generated code, run it with the right app runtime, place it behind a web server, point your domain to it, and add HTTPS. The main risks are choosing the wrong build/run setup, exposing the wrong port, breaking the app during updates, or forgetting how everything was wired together later.

What are you actually hosting from Bolt.new?

A Bolt.new app is usually a normal web app that Bolt helped you create. Think of Bolt.new as the workshop where the furniture was built. Your server is the room where that furniture needs to live, be cleaned, be reachable, and not fall over when guests arrive.

Depending on what you made, the app may be a static site, a React/Vite app, a Next.js app, or something with a backend. That matters because each type has a different “serve me” shape.

A static site is like a stack of printed flyers. Once built, the server only needs to hand out files.

A full web app is more like a small café. It needs a process running in the background, listening for requests, talking to any database or external service it depends on, and restarting if something goes wrong.

So the first question is not “how do I upload Bolt.new?” It is: what kind of app did Bolt.new generate, and what does that app need to stay alive?

What do you need before the app can go live?

You need four plain pieces.

First, you need the app code outside Bolt.new. That usually means a Git repository or a downloaded project. Git is a version history tool; imagine it as a notebook that records every serious change so you can go back if a new edit breaks the site.

Second, you need a server with enough room to run the app. Small apps do not need much, but build tools and JavaScript runtimes can be hungry for memory. If the build freezes, the app randomly stops, or pages feel slow, the issue may be size rather than code. Our plain-English sizing guide can help: what size server do you need.

Third, you need a domain name pointed at the server. The domain is the street address; the server is the building. Until those match, visitors will not know where to go. If that part feels fuzzy, read how to point a domain at your server.

Fourth, you need HTTPS. That is the padlock in the browser. Without it, visitors see warnings, some browser features may fail, and login or payment flows look untrustworthy. Here is the beginner version: how to get free HTTPS on your own server.

How does the deployment flow work?

The usual path has five stages.

You move the Bolt.new app code to a repository or your server. Then the server installs the app’s dependencies, which are the outside packages the project relies on. After that, it builds the production version of the app if the framework needs one.

Then the server runs the app, or serves the built files. Finally, a web server such as nginx sits in front of it and sends real visitor traffic to the right place.

The metaphor is a restaurant kitchen. Your app process is the cook. nginx is the host at the front door. Visitors do not walk into the kitchen; the host routes them to the right table.

This front-door layer is where many first deployments fail. If nginx sends traffic to the wrong port, you may see the literal error string “502 Bad Gateway.” That usually means the front door is open, but the cook is missing, crashed, or standing in a different room.

Another common failure is environment variables. These are private settings like API keys, database URLs, or service tokens. Bolt.new may have used them in preview, but your server needs its own copy. If they are missing, the site may load a blank page, fail login, or throw errors only when a visitor tries a specific feature.

If your app uses containers, Docker can make the setup easier to repeat. Docker is a way to package the app with the software it needs, like putting the kitchen tools in the same crate as the recipe. If that is new territory, start with Docker on a server for beginners.

What usually breaks after launch?

The first problem is the app not staying online. A web app needs a process manager or container setup that brings it back if it crashes or the server restarts. Otherwise, it works after launch day and disappears after the first reboot.

The second problem is a domain or HTTPS mismatch. The app is fine, but the browser complains because the certificate is wrong, expired, or issued for a different name. To a visitor, that still looks like your site is broken.

The third problem is updates. You change the Bolt.new project, redeploy, and suddenly an older working version is gone. Without a clear rollback path, every update feels like crossing a bridge while removing the planks behind you.

The fourth problem is memory during builds. Some JavaScript apps build comfortably on your laptop but run out of memory on a small server. The symptom may be a failed deployment, a killed process, or a server that becomes slow for every site on it.

The fifth problem is forgetting the setup. Three months later, you need to renew something, move the app, or add a second site — and the server feels like a drawer full of unlabeled cables.

FAQ

Can I host a Bolt.new app on my own server? Yes. Bolt.new generates a normal web project, and that project can be hosted on your own server if the runtime, domain, HTTPS, and app process are set up correctly.

Do I need Docker for a Bolt.new app? Not always. Docker helps when you want a repeatable setup, but a simple static or small JavaScript app can run without it.

Why does my Bolt.new app show “502 Bad Gateway”? Usually nginx or another front-door web server cannot reach the app process. The app may be stopped, listening on the wrong port, or failing at startup.

Can I host more than one Bolt.new app on one server? Yes, but each app needs a clear domain, port, HTTPS certificate, and process boundary so one project does not trip over another.

The shortcut

Server Manager helps by keeping the moving parts visible: the app, the domain, HTTPS, and the running service do not become a mystery pile of notes. The outcome is less time guessing whether the failure is DNS, a wrong certificate, a stopped process, or an app that was never wired to the right address.

It also helps when you come back later. A Bolt.new app that made sense on launch day can become confusing after a few updates, a second project, or one urgent fix. The real benefit is that the setup stays legible, so you can see what belongs to this app and what does not.

That means fewer fragile handoffs between preview, deployment, and maintenance — and less chance that one project breaking, an expired certificate, or a forgotten port takes the whole evening.

What is the win?

Hosting a Bolt.new app on your own server is not about becoming a full-time system administrator. It is about giving your generated app a stable home.

Once the code, runtime, domain, HTTPS, and restart behavior are clear, the website stops feeling like a lucky preview and starts feeling like something you can keep. You know where it lives, what keeps it running, and what to check when something goes wrong.