Builds and Deployments

Every change to a hosted website goes through a build and produces a numbered deployment. Deployments are immutable, so you can always see exactly what was live when, and roll back to any previous version in one click.

How sites get deployed

There are several ways content reaches a website:

• Agent-driven — The most common path. Ask an agent to build or update a site in chat; it writes the files and starts a build for you.
• Starter page — Creating a website auto-deploys a starter landing page so the URL is live immediately.
• API and CLI — Files can also be deployed programmatically for automated pipelines.

Framework builds

A build takes a set of source files and turns them into a deployable site:

• Static — HTML, CSS, JavaScript, and assets are shipped as-is. No build step runs.
• Next.js and Remix — The project’s dependencies are installed and the framework’s production build runs in an isolated build container. The result is deployed with full server-side rendering.
• Astro — Astro sites are built and deployed as static output.

Framework builds require a package.json at the project root. Build minutes used this month are shown on the website’s dashboard.

Build status and logs

Each build moves through pending, running, and then succeeded or failed. The Builds panel on the website’s page shows recent builds and their status; framework builds also capture a full build log (the install and build output), which is the first place to look when a build fails.

Try asking your agent

“Check the status of the last build for the marketing site, and if it failed, read the build log and fix the problem.”

Deployments and versions

Every successful build or deploy creates a new deployment with a sequential version number (v1, v2, v3, …). The Version History table on the website’s page lists every deployment with its status, file count, size, source, and date. Exactly one deployment is active (live) at a time; earlier ones are marked superseded.

Rolling back

If a deployment goes wrong, restore any previous version:

1. Open the website from the Websites page
2. Scroll to Version History
3. Click Rollback on the version you want to restore

The rollback is atomic and takes effect immediately — the site starts serving the selected version, and for server-rendered sites the server bundle is redeployed with the current environment variables.

Tip

Rollbacks are instant. This makes it safe to deploy updates quickly — if something breaks, you can restore the previous version in seconds.

Activity log

The Activity panel shows a unified timeline for the site: deploys, builds, rollbacks, configuration changes, and any 4xx/5xx errors visitors hit. Agents can read the same feed in chat, so you can ask an agent to investigate an error spike without opening the portal.

Site databases

Server-rendered sites get their own dedicated SQLite database, provisioned automatically on the first successful build. The site’s server code can read and write it at runtime. Agents can run read-only queries against it in chat — useful for checking data during debugging or a migration — while writes stay inside the app itself so they are audited at the application layer.

Try asking your agent

“Query the bookings site’s database and tell me how many orders came in this week.”

Next steps

• Website Hosting — Overview of the hosting platform.
• Environment Variables — Provide build-time and runtime configuration.
• Custom Domains — Put your deployment behind your own domain.