Deploy the build, not the workspace
bolt.new can generate a project quickly, but StaticX should receive the static output folder that browsers need.
AI builder hosting
Deploy static outputs from bolt.new projects with a workflow that works for both humans and agents.
bolt.new can generate a project quickly, but StaticX should receive the static output folder that browsers need.
Do not upload node_modules, package caches, or development-only files when publishing the final site.
Use API, CLI, or MCP instructions so future bolt.new revisions follow the same deploy path.
Build the generated project, isolate the browser-ready output, and publish it as a StaticX version.
Use the generated package scripts to produce dist, build, out, or another static output folder.
Confirm index.html, 404.html, CSS, JavaScript, and assets are present without source-only baggage.
Deploy to StaticX and review logs or API responses before considering the site live.
Generated projects often include build tooling, temporary files, and assumptions from the creation environment. StaticX only needs the static output visitors request.
Once published, the release is easy to compare, roll back, and connect to a domain while preserving the path from AI-generated code to live site.
Know which command creates the final folder before asking an agent to deploy.
Packages and caches increase storage without helping the public site load.
Agents should return failed build or deploy errors instead of retrying blindly.
Short, practical answers for using this page safely.
StaticX hosts the static build output, not the development workspace or server runtime.
Build it first, then deploy the output folder such as dist or build with index.html at the root.
Yes. The agent should build, verify required files, deploy the output root, and return logs.
Yes, if the update was published as a StaticX deployment version.