Deploying

Three modes of deployment

Swarmz separates "what you see while you're building" from "what you ship to users." Every project has access to all three modes — you choose per project which to use.

The container preview is dynamic and ephemeral. Preview and published deployments are static snapshots backed by Cloudflare Workers — they survive container hibernation and serve at edge speeds.

Live container preview

Every project gets a development URL the moment it's created. The agent runs npm run dev inside a real container, and the dev server is exposed at a subdomain like cool-otter-9f3a.swarmz.cloud. Hot module replacement works as expected — type a change in chat, the file is written, Vite HMR updates the browser.

This URL is bound to the container's lifecycle. Free and Pro containers hibernate after a period of inactivity to free up cluster resources. When that happens, the URL stops responding. Visiting it (or opening the project in the editor) wakes the container back up — provisioning takes 5-15 seconds, then the dev server reattaches and the URL is live again.

Because it's a dev server, expect:

• Source maps and unminified bundles
• No SEO metadata injected
• Whatever framework dev features you've enabled (React Refresh, Tailwind JIT, etc.)

Don't share this URL with end users. It's for you and your collaborators while building.

Preview deployments

A preview deployment freezes the current state of your project into a static build and hosts it at a permanent URL. Unlike the container preview, it doesn't go away when the container hibernates and doesn't reflect later changes.

POST /v1/projects/{id}/previews

Behind the scenes, Swarmz runs npm run build inside the container, uploads the resulting dist/ to Cloudflare Workers Static Assets, and binds a Worker that serves the bundle with SPA fallback (404s rewrite to /index.html).

Preview URLs are immutable — every time you create one, you get a new permanent link. Use them to:

• Share a checkpoint with a client without giving them editor access
• A/B compare two iterations side-by-side
• Pin a "known good" build before a risky refactor

Preview deployments use the same build pipeline as production publishing, so if a preview builds cleanly, your publish will too.

Publishing to production

Publishing promotes a build to your project's public production URL.

POST /v1/projects/{id}/publish

The default URL is <your-slug>.swarmz.cloud, where <your-slug> is derived from the project name (lowercased, hyphenated, alphanumeric only — My App! becomes my-app). You can override the slug at publish time. Reserved subdomains like www, api, auth, cdn are blocked.

You can optionally pin a specific preview_id to publish — useful if your latest commit is broken and you want to ship the previous green snapshot instead of rebuilding from scratch.

The publish flow returns a 202 immediately with a jobId; the actual build, upload, and Worker deploy run in the background. The dashboard polls publish_jobs and surfaces status (running → completed or failed). A typical publish takes 30-90 seconds depending on bundle size.

A few things happen at publish time that don't happen for previews:

• SEO metadata (<title>, <meta description>, OG tags) is injected into index.html
• A "Made on Swarmz" badge is embedded (Pro and above can hide it)
• The published commit SHA is recorded so you can correlate deployments to git history

Custom domains

Custom domains require a Pro plan or higher. Add a domain in Settings > Domains:

1. Enter your hostname (apex like acme.com or subdomain like app.acme.com)
2. Swarmz returns DNS instructions
3. Add the records at your DNS provider
4. SSL is provisioned automatically once DNS resolves (typically 1-5 minutes)

Both apex and subdomain hostnames use a CNAME record pointing at cdn.swarmz.cloud. You'll also add a TXT record for ownership verification. Cloudflare for SaaS handles certificate issuance and renewal — there's nothing to install or rotate.

If verification stalls, the dashboard surfaces the underlying Cloudflare error (failure_reason). The status cron polls every 60 seconds; the Verify now button forces an immediate re-check (rate-limited to one call every 5 seconds per domain).

GitHub-driven deploys

Once you've connected GitHub via the GitHub integration, every project can be linked to a repository. Push commits to the tracked branch and Swarmz pulls them into your container automatically.

The flow:

1. Webhook fires from GitHub on push to your tracked branch (default: main)
2. Swarmz fetches a fresh installation token, updates the container's git remote, and runs git pull origin <branch>
3. The container's dev server picks up the changes via HMR (or restarts if config changed)
4. Total time from push to live: ~60 seconds

For published deployments, you still need to call publish explicitly — pushing to GitHub updates the live container preview, not the production URL. This separation is intentional: you don't want every commit to ship to your users.

If your container is hibernated when the webhook fires, the pull is skipped (the next time you open the project, you'll need to pull manually or push again). This avoids spinning up containers just to apply changes nobody is watching.

Deploying to Vercel, Netlify, or your own infra

Swarmz projects are standard Node toolchain — Vite, Next.js, whatever the agent scaffolded. Nothing about your code is locked to Swarmz infrastructure. Two paths to take it elsewhere:

Option 1: GitHub-driven. Link the project to a repo, then connect that repo to Vercel or Netlify the normal way. Pushes from Swarmz flow through GitHub into the platform of your choice. See the Vercel integration and Netlify integration for the platform-side setup.

Option 2: Tarball export. From the project menu, Export workspace downloads a .tar.gz of your /workspace directory (sans node_modules). Run npm install, npm run build, and ship the dist/ to wherever — S3 + CloudFront, Fly.io, your own Kubernetes cluster.

Both paths assume you'll handle DNS, SSL, and CI yourself once you leave Swarmz infrastructure. Custom domains added in Swarmz only route traffic to Swarmz-published deployments.

Rollback

Every published deployment is preserved as an immutable snapshot. Open Settings > Deployments to see the full history — timestamp, commit SHA (when GitHub-linked), and slug. Pick an older entry and hit Roll back to re-bind the production URL to that snapshot.

Rollback is instant: no rebuild, since the static assets and Worker script are still in Cloudflare's storage. The previous "current" deployment isn't deleted, so you can re-promote it later. Custom domain bindings follow the production URL, so rolling back also routes your custom domain traffic to the old build.