Bolt can take a prompt and produce a working website or application. Once the preview looks right, the next question is usually less exciting but more consequential:
Where should this project live, and how will you maintain it after launch?
Bolt already includes a direct Publish workflow. It can also export a project as a ZIP file and connect to GitHub. For some projects, Bolt's own publication path is the correct answer. For others, the generated project is only the starting point.
This guide separates those cases.
Option 1: Publish directly from Bolt
Bolt provides a built-in Publish action. The current project can go live on a bolt.host address, and paid plans can use a custom domain.
The basic flow is:
- Open the project.
- Click Publish.
- Confirm the publication.
- Open the generated URL.
- Use Update when you want later changes to become public.
This is the shortest route when you want to keep building and operating the project inside Bolt.
Choose it when:
- Bolt is your primary workspace;
- the project uses Bolt-specific services or application features;
- you want Bolt to manage the complete release path;
- the included project controls match your needs.
There is no reason to export a project simply because export is available.
Option 2: Download the project
Bolt lets you download the project from Project title → Export → Download.
The ZIP file contains the project source. According to Bolt's current documentation, running an exported project locally generally requires Node.js and the project dependencies:
npm install
npm run dev
This route gives you direct access to the code, but it also transfers responsibility for building, testing, publishing, updates, and recovery.
Choose it when:
- a developer will maintain the code;
- the project is becoming a larger web application;
- you need a conventional repository and development workflow;
- the exported stack depends on a build process or server-side features.
Do not assume that an exported Bolt project is a single HTML file. Inspect the project before choosing a publication method.
Option 3: Connect the project to GitHub
GitHub is useful when the project needs:
- code review;
- collaboration with developers;
- branches and pull requests;
- an independent copy of the source;
- automated deployment through another platform.
This is the conventional path for a long-lived software project.
It may be excessive for a small campaign page that only needs a domain, a lead form, and occasional AI-assisted updates.
Option 4: Use Deplion for a static landing page
Deplion is relevant when the Bolt result can be delivered as static HTML, CSS, and JavaScript and the operating requirements are:
- a project URL or custom domain;
- lead collection;
- version history;
- rollback;
- maintenance by an AI assistant through MCP;
- management of several landing pages from one account.
The division of work is straightforward:
- Bolt generates the design and code.
- Your AI assistant prepares the static deliverable.
- Deplion publishes and maintains the site.
This is not the right route for every Bolt project. A full application with server-side code, private database logic, or runtime secrets should stay in an application-oriented workflow.
First, identify what Bolt generated
Before moving anything, inspect the file tree and package.json.
A static-friendly project usually has
- HTML or a front-end build output;
- CSS and browser JavaScript;
- images and fonts;
- no required server process after build;
- no secret keys in browser code;
- no private database operations.
An application project may have
- API routes;
- server actions;
- authentication;
- database migrations;
- server-only environment variables;
- background jobs;
- payment processing;
- private integrations.
A static publication workflow should never be used to expose code or keys that were designed to run on a server.
How to prepare a Bolt landing page for Deplion
Step 1: Ask Bolt for a static deliverable
Use a focused prompt:
Prepare this project as a self-contained static landing page.
Keep the current design and copy.
Remove server-only dependencies.
Use HTML, CSS, and browser JavaScript.
Preserve responsive behavior.
Do not include private API keys.
Add a contact form with name, email, and message fields.
Then review the generated files rather than assuming the conversion succeeded.
Step 2: Check external dependencies
List every dependency the page uses:
- fonts;
- icon libraries;
- analytics;
- embedded videos;
- maps;
- form scripts;
- remote images.
Decide which should remain external and which should be included with the project.
A page that only works while a temporary preview service is available is not ready.
Step 3: Connect an MCP-compatible assistant to Deplion
Add the remote MCP endpoint supported by Deplion:
https://deplion.cc/mcp/deplion
Complete authorization, then enable the connector in the conversation.
Step 4: Create and publish the project
A practical instruction to the assistant is:
Create a Deplion project for this landing page.
Upload the reviewed static files.
Check the page on desktop and mobile.
Publish it and return the public URL.
Keep the first publication as a review release. Test the site before connecting the final domain.
Step 5: Verify the lead path
For a commercial landing page, test the form end to end.
The correct question is not “Did the form submit?”
The correct questions are:
- Did the enquiry reach the project inbox?
- Are all fields stored correctly?
- Does the visitor see a clear confirmation?
- What happens when a required field is missing?
- What happens when the network request fails?
- Can the team identify which project produced the lead?
How to choose
| Requirement | Recommended path |
|---|---|
| Continue building the complete app in Bolt | Bolt Publish |
| Maintain a full codebase with developers | GitHub |
| Work locally with the exported source | Download ZIP |
| Operate a static landing page with leads and rollback | Deplion |
| Use server-side logic, private APIs, or a database | Application deployment workflow |
The decision is based on the project architecture, not on which tool generated the first version.
The maintenance question most people miss
Launching is one event. Maintenance is the recurring cost.
Ask these questions before choosing:
- Who will make the next text change?
- Who will verify that the form still works?
- Can the previous public version be restored?
- Are unpublished edits isolated from the live site?
- Can the domain move without rebuilding the page?
- Can one person manage several client projects?
- Does the workflow still make sense after the tenth update?
The fastest initial publication is not always the simplest operating model.
A safe update pattern for AI-built sites
Whether you stay in Bolt or move the static result elsewhere:
- Keep a known-good public version.
- Request small, bounded changes.
- Review the preview.
- Publish deliberately.
- Test the changed behavior.
- Restore the previous version when necessary.
Avoid prompts such as:
Make the whole site better.
Prefer:
Improve only the pricing section.
Keep the header, footer, forms, scripts, colors, and spacing outside that section unchanged.
AI edits are easier to validate when the requested scope is explicit.
The main idea
Bolt solves the generation problem and also offers its own publication path. Use that path when the whole project belongs in Bolt.
Export or connect GitHub when the project is becoming conventional software.
Use Deplion when the output is a static landing page and the ongoing job is to manage domains, leads, versions, rollback, and AI-assisted updates.