Deployment

Web and backend artifacts have distinct output directories. The web route manifest describes rendering requirements and records its build identity. The backend manifest records the matching identity. Local preview refuses incompatible artifacts.

Static hosting

fuzor build --deployment github-pages

Upload .fuzor/web/dist/ to a static host. This validates that no route needs request-time HTML. Use --deployment static for generic static hosting. An incompatible route produces an error explaining how to pre-render it or choose a rendering host.

SPAs may call an independently deployed remote backend. Backend endpoints remain separately deployed and must have appropriate URLs, authentication and cross-origin policy. Static-only hosting cannot run SSR or regenerate files on incoming requests. Regeneration is an external rebuild and publication process.

Node and VPS hosting

fuzor build --deployment node
fuzor preview

A server-backed project emits .fuzor/dist-backend/entry.mjs, exporting handler and manifest, alongside .fuzor/web/dist/. The handler uses Fetch Request/Response contracts. Serve the web assets and forward SSR and backend endpoint requests to that handler. Static routes remain compiled documents, not per-request component execution.

A reverse proxy may serve static files from one host and forward runtime routes to a separately deployed backend. DNS resolves hostnames; HTTP routing handles the path split.

Server dependencies

By default, the generated server entry leaves fuzor and effect as imports. Install both beside the deployment, or configure which packages the host already supplies:

fuzorPlugin({ serverExternal: ["effect"] })

This bundles Fuzor's server runtime into entry.mjs while leaving effect for the host. serverExternal: [] bundles both. This controls server packaging; it does not change browser component registration or add a package installer.

Cloudflare

fuzor build --adapter cloudflare
fuzor deploy --adapter cloudflare --dry-run

The adapter emits a Worker entry and wrangler.jsonc under .fuzor/dist-backend/. Its asset directory references the matching web output. API, data, server-component and SSR paths run the Worker first; other paths use static assets. Both trailing-slash forms and dynamic SSR prefixes are routed to the runtime.

The generated combined Worker configuration is an optional deployment convenience. Independently hosted clients and backend deployments remain possible with a routing gateway. No Alchemy integration is required to build or run these artifacts.

The generated compatibility date is pinned to the qualified runtime rather than automatically advanced to the current day. Vercel and Netlify are not qualified adapters yet; they must not be advertised as supported merely because a provider can host functions.

Deployment automation

Vite builds the runtime-specific modules. Fuzor owns route manifests, packaging and target validation. Alchemy can later be an optional provisioning/deployment integration behind those contracts; it is not installed in the browser or required in the application runtime. No new Alchemy deployment command is implemented yet.