Channels

VibeHost doesn't know about git. Preview deploys are channels — named slots on the same app.

my-app
  ├── channel: production       ──► live deployment id #42
  ├── channel: dark-mode        ──► live deployment id #38
  └── channel: pr-138           ──► live deployment id #41

Each channel has its own alias URL. They run in parallel. A deploy in dark-mode never affects production — Hard Rule #5.

Deploy to a channel

vibehost deploy --channel production    # default channel
vibehost deploy --channel dark-mode
vibehost deploy --channel pr-138

Channels auto-create on first deploy. URLs:

• https://<app>.vibehost.space — production channel alias
• https://<app>-dark-mode.vibehost.space — preview channel alias
• https://<deploy-id>.vibehost.space — immutable per-deployment URL

The immutable URL always works — even after rollback or promote. Link to it when you need to reference a specific version (PR review comments, design handoff, demo).

Promote between channels

Once you've validated a preview, promote a specific deployment into another channel without re-uploading:

# Grab the deployment ID from `vibehost logs` output or
# `data.deployments[].id` via the API. Then:
vibehost promote <deploymentId> --to-channel production --app my-app

The artifact is launched into the target channel — same bytes, same immutableUrl, new channel alias.

This is the killer feature: the bytes you reviewed are the bytes that go live. No rebuild step in the middle that could regress.

Rollback

vibehost rollback --app my-app                    # rollback production to the previous deploy
vibehost rollback --app my-app --channel pr-138   # rollback a specific channel

Rolling back doesn't delete anything — it points the channel alias at an older immutableUrl. The current deployment keeps its URL too; you can re-promote at any time.

Common patterns

# .github/workflows/preview.yml
- run: vibehost deploy --channel pr-${{ github.event.pull_request.number }}

# 1. CI deploys every main commit to staging channel
vibehost deploy --channel staging --json
# → grab data.id (the deployment ID)

# 2. After QA approves, promote without rebuild
vibehost promote <deploymentId> --to-channel production --app my-app

vibehost deploy --channel variant-a
vibehost deploy --channel variant-b
# Send traffic via custom domains or share links per channel

List and clean up

vibehost channel list --app my-app
vibehost channel delete pr-138 --app my-app             # after PR merges

Channels are cheap — there's no per-channel runtime cost beyond the deployment they currently point to. Delete them when the PR closes to keep your dashboard tidy.

What channels are NOT

• Not git branches. VibeHost has zero git awareness. The CLI names the channel; the server stores the name.
• Not environments. "Staging" and "production" are just channel names. There's no environment-scoped config — env vars are per-app, not per-channel. Use separate apps if you need different env vars per stage.
• Not access scopes. Channels don't gate access — visibility, password, and share links do (see Grants and visibility).