Skip to content
Sprigr

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

Section titled “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

Section titled “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. Next.js sites also get incremental static regeneration (ISR) caching, so pages with a revalidate value are served from cache and re-rendered in the background.
  • Astro — Built and deployed as static output by default. If your astro.config declares the @astrojs/cloudflare adapter, the site is deployed with server-side rendering instead.

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

Section titled “Build status and logs”

Each build moves through pending, running, and then succeeded, failed, cancelled, or timeout. A single build may run for at most 800 seconds before it is timed out, and one build per company runs at a time; further builds queue behind it. 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.

Deployments and versions

Section titled “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

Section titled “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 takes effect immediately — the site starts serving the selected version, and for server-rendered sites the server bundle is then redeployed with the current environment variables. That rebind step is best-effort: if it fails, the pointer flip still stands and the failure is logged on the site’s Activity panel.

Activity log

Section titled “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

Section titled “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.

Next steps

Section titled “Next steps”