Deploying

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 — 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 — visitors are switched 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.