DiscordDeploy automationMulti-tenantGuardrails

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.

Duration2 months
Categoryautomation
TechnologiesDiscord.js · GitHub App with per-repo permissions · SSH multiplexing · Traefik webproxy · Allowlisted Bash commands · Audit log to channel

Key results

5
Isolated teams, single bot instance
Per-team
SSH user matches team, never `deploy`
Human-in-loop
Destructive ops require explicit confirm

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