Deployment

Builder-mode work doesn't stop at "the code is written." Deployment is how it lands in front of users.

Most of Busy Bee runs in your browser. The agents do the work, the deliverables surface in the UI, you approve, done. Builder-mode work is different. When agents are shipping software, the deliverable isn't a doc, it's a running app. Deployment is the bridge between what your team built and what your users can actually use.

The two halves of deployment

Busy Bee thinks about deployment in two layers:

Preview deployments: every Builder-mode task ships its work-in-progress to a live preview URL automatically. You can click through, click around, and check the work before approving.
Production deployments: promoting a previewed change to your real environment. This is the irreversible step; it always requires an explicit human approval.

Preview is free and automatic. Production is gated.

Preview deployments

When a Builder-mode task is in flight, the agent runs the app in a sandbox attached to the task. The sandbox URL is shown inline in the task thread, click it and you're looking at the live app with the agent's changes applied. Hot reload is on; as the agent iterates, the preview updates.

Previews are scoped to a task. They live as long as the task is active, plus a short grace period after completion so you can still click through during review. After that, the preview is torn down to save resources.

📸 Screenshot: a Builder-mode task with the inline preview URL and an iframe preview of the app.

Production deployments

Promoting to production requires:

A connected target - GitHub (for code-based deploys) plus your platform of choice (Vercel, Netlify, Cloudflare Pages, AWS, your own). Configure under Settings → Deployment.
An approved PR - production deployments only fire from merged pull requests. If the PR isn't merged, nothing ships.
An explicit human approval - even with everything wired, the actual production push pauses for sign-off.

You'll see the deploy status in the task thread: queued, running, succeeded, or failed. Failed deploys surface the build logs so the agent can read them and propose a fix.

What gets deployed

By default, only changes to the configured production branch (typically main) trigger a production deploy. Feature branches and PR branches stay in preview-only mode. This matches how most teams already work and prevents accidental production pushes.

Deployment + Recurring

Combine deployment with recurring tasks and you have continuous-delivery-as-a-team. A recurring "ship the changelog" template can:

Pull the merged PRs since the last deploy.
Draft a release note.
Open a release PR.
Wait for your approval.
Trigger the production deploy.
Post the changelog to Slack.

Set it up once; ship every Friday.

What's not in scope (yet)

Today's deployment surface is built around web apps deployed through GitHub. Native mobile builds, on-prem packaging, and custom CI handoffs are on the roadmap; for now, those require a custom MCP integration. Talk to us if your stack needs that.

What's next

You've now seen the entire Busy Bee surface. Pick a starting point that matches your work, for most teams it's Get Started + the Product Hive + GitHub integration. Build from there.