Skip to main content

Deployment

This page covers the Service Desk side of the Telegram integration — the Mini App and the Service Desk Bot — which ship as two deployable components on the Console server, plus a small amount of configuration on the existing Console backend. Nothing new is required in the database or message bus — the Mini App talks to the existing Console API, and the bot is a self-contained service.

The Ops bot is deployed separately

The Ops Bot is not part of this server-side flow — it runs in Kubernetes (console-system) via the platform's GitOps pipeline, with its own OPS_TELEGRAM_BOT_TOKEN / CONSOLE_API_KEY. This page is the Service Desk bot + Mini App only.

Deployable components​

ComponentDockerfileRuns asDomain / port
Mini Appinfra/docker/telegram-miniapp/Dockerfile (+ nginx.conf)Docker (nginx serving static build)tg-console.prxm.uz
Botinfra/docker/telegram-bot/DockerfileDocker (Go binary)Same server, :8082

Mini App image​

The Mini App Dockerfile builds the React/Vite app and serves the static output with nginx. The accompanying nginx.conf inside the image handles SPA routing (try_files to index.html).

Bot image​

The bot Dockerfile builds the Go binary and runs it. The bot listens on :8082 and is reached through the public vhost under /telegram-bot/.

nginx​

The public vhost infra/deploy/nginx/tg-console.prxm.uz.conf serves both components from a single host:

  • / → the Mini App static files (/var/www/telegram-miniapp).
  • /telegram-bot/ → reverse-proxied to the bot at 127.0.0.1:8082 (this is the path Jira/JSM webhooks and Telegram updates reach).
  • TLS terminates here via Let's Encrypt certificates for tg-console.prxm.uz.

systemd​

Two units manage the containers:

  • proxima-telegram-bot.service (infra/deploy/systemd/proxima-telegram-bot.service) — runs the bot container.
  • proxima-telegram-miniapp.service (infra/deploy/systemd/proxima-telegram-miniapp.service) — runs the Mini App container.

Deploy script and CI​

Both images are built conditionally in CI — the bot image only builds when files under telegram/bot/ change, and the Mini App image only when files under telegram/miniapp/ change. scripts/deploy-dev.sh resolves the current image tags, pulls them, installs the systemd units, and restarts the two services. Because the images are conditionally built, the deploy script handles the Telegram units specially: it installs them after the main services, resolving the published tag for each.

Backend configuration​

The Telegram auth bridge lives inside the existing Console backend. It is enabled only when a bot token is configured:

VariableComponentDescription
PROXIMA_TELEGRAM_BOT_TOKENConsole backendEnables Telegram auth. The token is used to validate Telegram initData via HMAC-SHA256. When empty, the /api/v1/auth/telegram* routes are not registered at all.

This is the same bot token issued by @BotFather that the bot uses for TELEGRAM_BOT_TOKEN — both the bot and the backend need it (the bot to talk to Telegram, the backend to verify initData signatures).

Bot environment variables​

The bot's full set of environment variables is documented on the Bot page. In the standard deployment they are read from /opt/proxima/.env. The required ones are TELEGRAM_BOT_TOKEN, TELEGRAM_MINIAPP_URL, and CONSOLE_API_KEY.

Deployment checklist​

  1. Create the bot with @BotFather and note the token.
  2. Set PROXIMA_TELEGRAM_BOT_TOKEN on the Console backend (enables the auth routes) and restart it.
  3. Populate the bot's environment (/opt/proxima/.env): at minimum TELEGRAM_BOT_TOKEN, TELEGRAM_MINIAPP_URL, and CONSOLE_API_KEY.
  4. Issue/renew the Let's Encrypt certificate for tg-console.prxm.uz and install the nginx vhost.
  5. Deploy the two images via scripts/deploy-dev.sh, which installs the systemd units and starts both services.
  6. Configure the Jira/JSM webhook to POST to https://tg-console.prxm.uz/telegram-bot/webhook/jira, optionally with a shared secret matching JIRA_WEBHOOK_SECRET.
  7. Have users link their accounts (see Account Linking & Security).