Español
English
Català
FrançaisBolt.new already offers publishing from its own workspace, plus documented GitHub and Netlify options. If Bolt Cloud meets your app’s needs, there may be no reason to move it. If cost is the reason, compare current Bolt Cloud plans with the destination’s price and limits, including database, authentication and storage. This guide is for projects that need to run on different infrastructure, use your team’s deployment workflow, or separate hosting from the services Bolt created.
If you are still choosing where to publish an AI-built site, start by identifying what the project needs to run. If your project is still on your computer without a public URL, use the localhost-to-Internet guide first.
1. Secure the source and the latest change
Connect the project to GitHub, or confirm the connected repository contains the latest changes. Bolt’s GitHub documentation explains how to keep code in a repository and publish with another service. Check the active branch, latest commit and completed sync. A downloaded source folder is not a backup of production data.
Before changing hosts, create an identifiable commit and a recoverable copy of any data you need. Do not add .env files, private keys or credentials to the repository. Keep the working deployment available until the replacement has passed testing.
2. Check what the destination must run
Review package.json, build and start commands, configuration files and application routes. Run the build locally or in the target environment and confirm which output folder it creates (dist, build or another). A static output folder may serve a frontend; it will not run an API, persistent jobs or server functions by itself.
Bolt can host projects and connect GitHub to external services. Its hosting documentation and Netlify publishing guide describe those options. If the app uses server routes or Bolt Cloud functions, identify a compatible alternative before changing DNS.
3. Move dependencies that Git does not contain
The repository does not automatically transfer databases, users, files, secrets or email. Bolt Cloud can include a database, file storage, authentication and server functions. If the project uses Supabase, check its connection and Bolt’s integration guide; an external database still needs its own migration plan.
List every variable used by the backend, login callback URL, allowed domain and integration. Move data using tools compatible with both database engines; verify the schema, permissions, extensions and files with a test copy. Do not run destructive restores against the active database. Keep private keys in the new environment’s secret settings, never in code sent to the browser.
4. Choose a destination that fits the requirements
Hostbrid Projects can deploy from Git and run Docker services within plan limits. Dev is for static sites; persistent services need a paid plan. Before ordering, review plans and limits and confirm the runtime, memory, storage, ports and processes you need.
If you need root access, operating-system control or services outside Projects, consider a VPS, which you will administer. For WordPress and other managed PHP services, see Sites. Do not choose a VPS just because Bolt generated a JavaScript project.
5. Test the replacement before moving the domain
Publish first to a temporary URL. Check direct routes, forms, data reads and writes, file uploads, sign-in and recovery, callbacks and email. Confirm the frontend calls the new API and no secret appears in browser code. If the app depends on Node or Docker, follow the service port and health checklist too.
Change DNS only after these checks and HTTPS pass on the new host. Keep a clear way to return to the old service. For PostgreSQL, our guide to migrating and verifying data covers moving records between compatible databases.
If you are unsure whether the app is static or depends on Bolt Cloud, tell us its framework and dependencies; never send passwords or keys. Moving the source does not guarantee a lower bill or automatically transfer all connected services.