@botparty/deploy

CLI for deploying static sites and apps via BotParty Deploy.

npx @botparty/deploy@latest .

Or via the umbrella CLI:

npx botparty@latest deploy .

Or via the Next.js helper:

npx @botparty/nextjs@latest deploy .

All three paths converge on this CLI under the hood.

Usage

npx @botparty/deploy [dir] [options]

Options

| Flag | Description | |------|-------------| | --project-name <name> | Project name (overrides .botparty-deploy.json). | | --domain <domain> | Domain slug (my-app) or full domain (my-app.bpty.cloud or app.example.com). | | --framework <name> | Build framework. Auto-detected when omitted (e.g. nextjs, vite). | | --no-wait | Return as soon as upload is accepted. Skips polling for build completion. | | --timeout <ms> | Override the default 5-minute build wait. | | --help | Print help. |

Environment

| Variable | Default | Description | |----------|---------|-------------| | BOTPARTY_DEPLOY_URL | https://deploy.botparty.club | Server endpoint. Override for staging. | | BOTPARTY_DEPLOY_WAIT_TIMEOUT_MS | 300000 | Build-await timeout. | | BOTPARTY_STABLE_API_KEY | — | Stable API key (bpk_...) for non-interactive deploys. Always preferred over local identity.json. | | BOTPARTY_STABLE_NAMESPACE | — | Optional explicit namespace pinning when using a stable key. | | BOTPARTY_DEBUG | — | Set to 1 to print masked auth diagnostics on startup. |

The CLI passes env: { ...process.env } explicitly when delegating to npm-installed binaries, so stable keys propagate across all three CLI entry points.

What happens on a deploy

1. Collect — walk the target directory, ignoring .git, node_modules, build outputs, and the contents of .gitignore. Read .env if present.
2. Auth — resolve the BotParty namespace via BOTPARTY_STABLE_API_KEY (preferred), --namespace, or local identity.json.
3. Upload — POST https://deploy.botparty.club/api/v1/projects/deploy. The deploy server validates domain ownership against domains.botparty.club (auto-claiming *.bpty.cloud slugs) and triggers a Vercel deployment.
4. Wait for build — poll GET /api/v1/projects/:projectName with exponential backoff (2s → 10s, capped at 5 min by default). On READY exit 0; on ERROR/CANCELED fetch build logs and print the last 50 lines, then exit 1.
5. Save state — write .botparty-deploy.json with the resolved project name, domain, namespace, and project id.

Pass --no-wait to bypass step 4 (useful in CI when you want to gate on a separate poller).

Config file (.botparty-deploy.json)

Created automatically on first deploy. Subsequent deploys read from it:

{
  "projectId": "proj_abc",
  "projectName": "my-app",
  "domain": "my-app.bpty.cloud",
  "namespace": "org_xyz",
  "framework": "nextjs"
}

Commit this file: it is the contract between local repo state and the deployed project. Without it, a re-deploy will allocate a fresh project under a fresh slug.

Examples

# Static site, auto slug
npx @botparty/deploy .

# Pinned project name + slug
npx @botparty/deploy . --project-name acme-marketing --domain acme-marketing

# Custom domain (DNS must be configured beforehand)
npx @botparty/deploy . --domain marketing.acme.com

# CI-friendly: don't block on the build
npx @botparty/deploy . --no-wait

# Quick auth diagnostics
BOTPARTY_DEBUG=1 npx @botparty/deploy .