Serve committed files, no build step, at all

Some sites are already built: plain HTML, a docs export, a bundle you commit. The Static site toggle serves exactly what's in your repo, as-is. Sproobo never runs a build command against it.

What the toggle does

Turn on Static site when creating an app and point it at a Serve directory, a path relative to the repo root, such as dist or public, or the single literal . to serve the repo root itself. Sproobo generates a tiny image that just copies that directory into a caddy:2-alpine container and serves it on port 80, no install step, no build command, nothing executed against your source at all.

That image then goes through the exact same deploy pipeline as any other app: pushed to the registry, pulled by the agent, started alongside the old container, health-gated, and swapped in with an atomic proxy switch. The only difference is what the health gate probes: a static container has no app-level health endpoint, so it's always checked at / instead of /healthz.

Dotfile hardening, by default

Serving a whole repo root is convenient, but a repo root can contain things that were never meant to be public: a committed .env, .npmrc, or the .git history itself. The generated image guards against that automatically:

• Every dotfile path 404s, anything under a segment starting with ., except /.well-known/*, which stays reachable for ACME challenges, security.txt, and similar well-known files.
• .git is excluded from the image entirely at build time. It never even ships, dotfile rule or not.

This applies whether you serve the repo root or a narrower build-output directory.

Static toggle vs. a Dockerfile

Reach for the Static toggle when your directory is already the finished output: nothing needs to run to produce it. Reach for a Dockerfile (or let Railpack build it) instead when the framework needs a build step first:

• A plain HTML/CSS/JS site, a pre-rendered docs export, or any directory you commit already built: Static site, no build step.
• A framework that needs next build, vite build, or similar to produce its output: a real build, via a Dockerfile or Railpack, is what you want. See Apps & deploys for how that pipeline works and how build-time environment variables flow into it.

TLS and domains work the same

A static app gets the same apex-plus-www ingress and automatic certificate issuance as any other app. There's no separate TLS story for static sites. Deploys, rollback, and release retention all behave the same way too, since it's the identical blue-green pipeline underneath.

Next

• See the full deploy pipeline (build strategies, health gate, rollback) on Apps & deploys.
• Walk the full enroll-to-deploy flow on Getting started.
• Read the full trust-boundary and data-ownership model on Security model.