Deploying a static site

Auto-deploy from Git

Connect a GitHub, GitLab or Bitbucket repository and pick a branch. Every push to that branch triggers a new build and an atomic deploy, so visitors only ever see a fully-built version.

You can disable auto-deploy or change the branch in Settings → Build & Deploy.

Build configuration

Field	Description
build_command	Command run during build, e.g. npm run build.
publish_directory	Folder containing the built files, e.g. dist, build, public.
root_directory	Optional sub-folder used as the project root (for monorepos).

Set these in Settings → Build & Deploy, or let Runsite auto-detect them from your repo.

Redirects and headers

Drop a _redirects or _headers file at the root of your publish directory and Runsite picks it up automatically. The format is the same as Netlify’s:

# _redirects — SPA fallback
/*    /index.html   200

# _headers — per-path response headers
/*
  X-Frame-Options: DENY
/assets/*
  Cache-Control: public, max-age=31536000, immutable

No UI is needed. Commit the file with your code and the next deploy applies it.

Build process

When you trigger a deploy:

1. The selected branch is cloned.
2. Your build command runs.
3. The contents of the publish directory are uploaded.
4. The new version goes live atomically, switching visitors over only once everything is uploaded.

Build logs stream live on the Logs tab. If a build fails, the previous version keeps serving traffic.

Manual actions

The buttons in the service header:

Action	What it does
Redeploy	Build the current branch again. Use after changing build-time env vars or to retry a failed build.
Disable	Take the site offline. The latest deploy is kept and you can re-enable it any time.
Delete	Remove the site permanently.

Limits

Limit	Value
Max total size per deploy	500 MB
Max files per deploy	20,000
Max single-file size	25 MB

If a deploy exceeds any of these, the build fails with a clear error and the previous version stays live.