Multi-Team Discord Deploy Bot with Human-in-the-Loop Guardrails
Profile:Internal multi-team operation across regions
Five regional teams sharing one platform, each with its own deploy cadence, environment and SSH user. Built a Discord bot that lets each team deploy from chat without touching another team's infra — and refuses to do anything destructive without a human confirmation.
Key results
The problem
Five regional teams (think: separate brand offices in different countries) shared a single deployment platform but had to stay strictly isolated from each other. The previous setup was a shared `deploy` SSH user on every server and a wiki page of commands. Predictably: someone occasionally deployed Team A's changes to Team B's environment, and rsync silently broke ownership semantics for files that needed it.
The interesting question: can each team deploy from their own Discord channel, without ever being able to touch another team's infra, and with destructive operations requiring explicit human confirmation?
The approach
A single bot instance, per-team isolation enforced at every layer.
Per-team SSH user — `SSH_DEV_DEPLOY_USER={team}`, never the shared `deploy` user. Owner-aware rsync stops corrupting permissions. Each team's SSH key is provisioned once via a setup-secrets bot built on a GitHub App.
Channel-scoped commands — the bot only accepts deploy commands from each team's dedicated channel. A wrong channel = no command. The mapping channel → team is enforced server-side, not client-side.
Allowlisted command set — `deploy`, `rollback`, `logs`, `status`, `password`, `restart`. Anything outside the list is silently ignored. No shell escape.
Human-in-the-loop on destructive ops — `rollback`, `restart` and any command touching shared infra requires a `confirm` reply within 30 seconds. The confirmation is logged with the requester's Discord user ID.
Long-running ops via SSH `nohup` — deploys that take minutes run server-side under `nohup` with the Discord channel ID as part of the lock file name. The bot can resume status reporting if the bot itself restarts mid-deploy.
Discipline on credentials — `htpasswd` and similar ad-hoc credential changes must go through the bot's `password` flow. Manual `htpasswd` is grounds for revoking SSH access.
Audit log to channel — every command, success or failure, is summarized in a dedicated audit channel. Teams see their own; the platform team sees all.
The outcome
Five teams deploying autonomously from their own channels. Zero cross-team accidents since rollout. Audit log answers "who deployed what when" in seconds. Setup-secrets bot eliminates the manual `ssh-copy-id` ceremony for new servers.
Why it matters
Most "deploy from chat" tools assume a single team and a single environment. The interesting engineering for multi-team platforms is making isolation impossible to bypass even by accident: per-team SSH users, channel-scoped commands, allowlisted commands, mandatory confirmations on destructive ops. The chat surface is just frosting on top of a deploy pipeline that already enforces the right invariants.
A similar engagement for your team?
Every Tyber.io engagement starts with the same question: which problem hurts the most, and which one is the most fixable. Get in touch with the technical lead directly — no SDR funnel, no junior handoff.
Talk to the technical lead