Choose the folder you intend to publish
For a static site, include the entry HTML file, styles, JavaScript, and the assets those files reference. For a framework project, let the agent identify the expected build output and the build modes your account permits. Do not guess an output directory or upload your entire home folder.
Keep private files out of the upload
Your published website should contain only the files needed to serve it. Keep private documents, development credentials, and local environment files out of public output. Configure supported environment variables through build.host’s existing secure setup rather than embedding secret values in frontend code.
Connect your agent to build.host
Use Proto’s built-in hosting integration. For another coding agent, install or refresh the build.host skill and follow its current account connection instructions. Then ask: “Deploy this folder to build.host as my-site. Use the existing project if it already exists.” The agent can determine what is supported for the current account and submit the folder through the upload flow.
curl -fsSL build.host/api/install | bashCheck files and routes on the live address
Open the returned build.host URL. Follow internal links and confirm fonts, images, scripts, and styles load. Test the page at a phone-sized viewport. Relative asset paths that work locally can still fail when the wrong directory was published.
Deploy changes without changing the address
Continue working in your local folder and ask the agent to update the existing build.host project. Use the project’s deployment history and available rollback capability if a change regresses. Add GitHub later if you want a source-control collaboration workflow; folder deployment remains a separate supported route.