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.