Hosting with us is a convenience, not a lock. Each project is built to be moved, and the builder keeps working on a site after it has moved, because it works through the repository rather than through our hosting. This page describes the process as it will work when the builder opens.

What a move involves

Each repository ships with docs/MIGRATION.md, written for the specific site, and a production Dockerfile. The stack is standard: Next.js, TypeScript, a document database, object storage, and a container runtime. Moving means:

  1. Create the destination. A cloud project of your own, with a database, a storage bucket and a container platform. The migration guide lists the exact services the site uses and nothing it does not.
  2. Point the repository at it. Configuration lives outside the code; the runbook names each setting. Set them for your environment.
  3. Move the data. Export the site's named database and storage bucket and import them on your side. The guide gives the commands for the services the site was generated with.
  4. Deploy the container. Build the image from the repository and run it on your platform. The acceptance checks from the plan double as a smoke test.
  5. Switch the domain. Point DNS at your deployment. Nothing in the code refers to our hosting.

Keeping the builder after a move

The builder reads and writes the repository, so it can continue to plan and build after the move. Preview deployments and acceptance checks still run on our side against the repository; you deploy the result to your own platform, by hand or with your own pipeline. If you prefer to stop using the builder entirely, the repository, documentation and hooks remain, and nothing in them depends on us.

Maintenance from the chat

A launched site is where most of the work begins. Content updates, a new page, a changed form, a dependency bump, a new data entity: each is a request in the same conversation.

  1. Ask. Describe the change the way you described the site.
  2. Plan. The builder updates the plan, quotes the work, and asks anything it needs to know. Small changes get small plans.
  3. Build and preview. The agent implements it on the current code, runs the checks, and publishes a preview.
  4. Approve. You say go, and the change ships. Until then production is untouched.

Every step appears in site_events, so you can audit who asked for what and when.

What is yours and what is ours

Yours: the repository, its history, the documentation, the generated images and their provenance, the data in your site's database and storage, and the domain. Ours: the control service, the worker that does the building, the hosting while you use it, and the quote and ledger records that show what was charged and why.