React Buckets
Why buckets, concretely: the build artefact is files, and files in a declared bucket get versioning-by-deploy, path-prefix and domain rules from the gateway, and optional CDN behaviour from one flag. What teams otherwise assemble from an object store, a CDN distribution, and a rewrite rule set is a single route entry a reviewer can read.
SPA semantics are explicit in the declaration: fallback_mode: "spa" serves the app shell with a 200 for unknown paths so client routing owns them, while "not_found" returns honest 404s for estates that would rather 404 than masquerade. Canonical redirects keep the crawler-facing URL set singular either way.
The dynamic half lives one route away. React calls the project’s functions and workers on the same hostnames — same-origin fetches, platform-forwarded viewer headers for the backend, and private routes when the API should demand a key. The app stops being “the frontend, deployed elsewhere”.
CLI
Plan React Buckets, then deploy.
kernstack plan
kernstack plan
kernstack deploy Frequently asked questions
Any static output: Vite, Create React App, or a framework’s static export. The app declares its build command; output is published to the bucket on deploy.
With fallback_mode: "spa" (the default for prefix routes), unknown paths serve the app shell so the router resolves them. Pages that must truly 404 use "not_found" mode.
Prefer same-origin relative calls to declared routes — the gateway makes the frontend and API neighbours. Config that genuinely varies per environment belongs in per-environment stack overrides, not in the build.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.