PBVex first deployment

Walk the user through one checkpoint at a time. Inspect the application repository and installed PBVex version before asking for information already available. Keep a visible checklist of completed, pending, and user-owned steps; explain each required choice briefly.

Never ask the user to paste passwords, deployment tokens, encryption keys, SMTP credentials, or provider secrets into chat. Have them place secrets in their shell, service manager, CI secret store, or restricted environment file, and verify only names/presence. Pause for approval before privileged host changes, DNS/firewall changes, certificate issuance, service restarts, or a real deployment activation.

Discover the target

Establish these facts in small batches:

• Environment name and purpose: local, staging, or production.
• Existing backend or new host; OS/container platform; PBVex version and binary source.
• Private listener, public hostname, TLS/proxy owner, and DNS readiness.
• Dedicated data directory and local or S3-compatible object storage.
• Application repository, package manager, local pbvex version, and current pbvex/pbvex.config.ts.
• Required component environment bindings, auth methods, SMTP, rate limits, backup destination, and CI deployer.

Treat one server deployment as one application. Use exactly one PBVex process for one dedicated data directory; provision a separate process, hostname, credentials, and backup lifecycle for another application. Distinguish installing/upgrading the binary from deploying an application artifact.