From Bolt to your own hosting

What do you have after Bolt, and what is still missing?

You have a project that works and a place where you can show it. Bolt.new is a product of StackBlitz, and what you have in front of you is a development environment in the browser. What you need is the same project in a place that is yours, where it keeps running without anyone touching anything in the build environment.

Alongside it runs a second list: everything that lies outside the tool and is therefore arranged for you by no one. A hosting account in your name. A domain you own. A database with a backup you have restored once. Keys that are not in the code. And a privacy statement as soon as you store an email address. That list is not heavy, it is invisible: you are not missing a feature, you just do not know what you do not know.

• What you have: a working project and a place where you can show it.
• What is missing: your own host, your own domain, data that stays, keys outside the code.
• And the legal minimums, from the first real visitor.
• Go through the list in the order you come across it, and at each step stop at the smallest version that is good enough.

How do you get your project out of Bolt?

You start with ownership: make sure the code is in a place that is yours and that you can open without the tool. In practice that is your own repository in version control, because that is the format every host can work with and the only form of ownership that is not tied to a provider.

So first create an account with a version control service yourself and set up an empty repository there, with you as the owner. Then search the Bolt documentation for version control, export and downloading to see exactly what the connection requires. Those instructions take precedence over any general explanation, including this page: a guide that describes buttons is out of date within a month.

• Your own account with a version control service, your own empty repository, you as the owner.
• The connection itself: search the Bolt documentation for version control, export and downloading.
• Run the project once on your own computer: what does not start there will not start at a host either.
• Add five lines: how do you start the project, and which values does it need.
• Search the files for keys before you share the repository; version control forgets nothing.

Where will you host, and how do you connect your domain?

Hosting is the place where your project runs when your laptop is closed. The choice hangs on one question: can your project be delivered as ready-made files, or does it need a server to do some of the thinking? As soon as there are accounts, data or payments in it, you need an environment that runs your code.

Then look at four things: can you connect your own domain, do you get HTTPS automatically, can you set environment variables without putting them in your code, and can you leave again without rebuilding everything. That last one is forgotten most often and counts the most. A host that treats your code as ordinary code is a host you can leave.

You buy the domain from a registrar in your own name, because whoever owns the domain owns your address. Then you set up an A record for the bare name and a CNAME for a subdomain such as www. Your host usually states exactly what you need to fill in, and those instructions take precedence over this explanation. Expect a change not to be visible everywhere right away, because DNS is cached.

• No login and no storage: a static host is enough. Accounts or data: choose an environment that runs code.
• Four requirements for your host: your own domain, automatic HTTPS, environment variables, and a way out.
• An A record for the bare name, a CNAME for www; choose one canonical form and redirect the other.
• Expect monthly costs instead of a one-off amount, and check what happens when a free tier fills up.

What do you do with your database and your secrets?

These are the two things a prototype keeps worst and a live project has to handle best. Data often sits in a place that disappears, keys in a place anyone can read. Both go fine until someone uses your project seriously.

For the database: everything that has to stay belongs in a real database and not in memory or in a file next to the code. A managed relational database is the safe default, because someone else does the updates and the backups and the format does not belong to a provider. Turn on the backup and actually restore from it once; a backup you have never restored is an assumption.

For the secrets one rule applies: every value someone could use to pose as you belongs in an environment variable at your host and never in the code. Whatever ends up in the browser is public, whatever it is called. And if a key has ever leaked, rotate it, because removing it from the code does not revoke the old value.

• Nothing permanent in memory or in a file next to the code.
• Choose managed, in a format you can take with you; backup on, with a real restore test.
• Schema in migrations, and store only what you use.
• .env out of version control, .env.example with only the names in it.
• A leaked key is something you rotate, not something you delete.

Which checks do you run before going live?

Before a stranger opens your project, you go through a short list. It is not about security at large scale but about the handful of things that prevent most of the trouble. Everything that comes in from outside is suspect until you have checked it, and everything that goes out should reveal no more than necessary.

Turn HTTPS on and enforce it. Validate input on the server and not only in the browser, because the browser check is convenience and not a lock. Make sure error messages reveal nothing technical. Put a limit on forms and login attempts. And check whether you can reach someone else's data by changing an id in the address bar: that is the mistake that happens most often and costs the most.

• HTTPS enforced, validation on the server, error pages without technical details.
• A limit on forms and login attempts; test that changing an id in the URL does not open someone else's data.
• One h1 per page, alt text, keyboard use, contrast, a sitemap and a canonical URL per page.
• Your identity and KVK number (your registration with the Dutch Chamber of Commerce) easy to find, a privacy statement from the first email address.

basestep has an eighteen-point health check in five areas for this. It is a list you go through and tick off yourself: the platform does not watch your site and puts nothing live for you.

The eighteen points are in the health check. The explanation per step, with the legal minimums and what comes after going live, is in the main guide from prototype to live.

What does Bolt keep doing, and what is up to you from now on?

After the move the division of roles changes, not the value of the tool. Bolt remains the place where you build and change things quickly; your own host is the place where the version people rely on runs. It saves confusion to keep those two apart and to know for each change where you make it.

What is up to you from now on is short. You own the code, so you decide when something goes to the live version. You pay for host and domain, and you are the one who notices when a payment card or a domain expires. You update dependencies at a fixed moment, because doing nothing for half a year turns every update into a renovation. And you are the point of contact for your visitors, including for what you did not write yourself.

Two things you check at the source instead of here. Prices and free tiers in AI tooling change within weeks, so check the current state on the Bolt pricing page. And Bolt.new is a product of StackBlitz: what the terms and the processing of data mean for your situation, you read in the Bolt help center itself.

• Building can stay in the tool; the live version runs on your side.
• You decide when a change goes live, and you keep an eye on host, domain and renewals.
• Update dependencies at a fixed moment; check monthly that everything still runs and the backup is still working.
• Prices, terms and data processing: read them at the source, on the day you need them.

What if your project starts earning money?

As soon as money comes in, your project changes from something you make into something you keep books for. That step is the same for everyone: a registration, invoices that meet the requirements, VAT (btw) that you report on time, and a duty to keep your records. It is not a second project, it is a rhythm you set up once. The tax explanation on this page follows Dutch law and is written for Dutch sole proprietorships (eenmanszaak).

That is where the basestep path continues. The platform takes you in four phases from prototype to business. The administration is ready as soon as you earn, with a tax engine that explains for each section of the return where an amount comes from, down to the legal reference. You file yourself and understand exactly what you are doing.

• The first euro is the starting signal for your bookkeeping, not the end of building.
• Invoices, VAT and record keeping: set up the rhythm before the quarter is over.
• The path continues in four phases from first prompt to tax return.

This is general information, not tax or legal advice. basestep calculates and explains; you file yourself.

How it works at Bolt in August 2026

The rest of this guide is written to be timeless on purpose. This section is not. Here is what is true today and may be different in a few months, checked on 30 August 2026 in Bolt's own documentation and release notes. Read it as a starting point, and check at the source before you do anything irreversible.

Pay particular attention to who wins in a conflict. The connection with version control now works both ways: Bolt commits your changes itself and fetches every half minute whatever has changed outside Bolt. But if the same line has been changed in two places, Bolt keeps its own version and overwrites the one on GitHub. If you keep working outside Bolt for a while, do not open the project there without thinking. Merging is done on GitHub in any case, because that is not possible in Bolt.

• You can download your project as a file via the menu at the project title. You need Node locally to start it afterwards. Whether this also works on a free account is not stated in so many words anywhere; do not assume it blindly.
• Since April 2026 Bolt stores project code in a new format, and as soon as your project has moved to it, the route to open it in StackBlitz disappears. A guide that points you that way is out of date.
• Only the owner of the project manages the connection with version control, and changes from collaborators only come along once the owner opens the project.
• The built-in database is on by default and runs on PostgreSQL. For a project that is not published, it goes to sleep after about six days of inactivity; since July 2026 that no longer happens with published projects.
• If you want your data under your own control, there is exactly one documented way: claiming the database to your own Supabase account, which you must own. That way only goes in one direction; there is no going back. Do this before you move, not after.
• Note that Bolt's own version history does not restore a connected Supabase database. You then restore your code but not your data.
• The Supabase connection works for projects on Vite. Projects on Next.js are not supported.
• Keys are in the database settings and only apply at runtime, for your server functions; they do not end up in the browser. Since May and June 2026 all those settings sit together under the database icon, so older click paths are no longer correct.
• The built-in hosting gives you an address on bolt.host, and updating is manual. Connecting your own domain requires a paid plan, and on a free account there is a badge on your site. Bolt only runs backends in JavaScript, so PHP or Python do not fit.

Three things we have not been able to establish, so you find those out yourself. Whether you can reach the built-in database from outside. Whether an export or backup of it can be made. And whether the file with environment values comes along in the download. No official page covers that. So assume that claiming it to your own database is the safe route.