# DigiDala Production Deployment

Production is a separate runtime from the existing staging environment.
The staging environment remains:

- Mini App: `https://im-test.bktis.ru/apps/miniapp/`
- Bot: `@PixDala_bot`
- root: `/opt/pixdala`
- services: `pixdala-test-web`, `pixdala-test-api`, `pixdala-bot`

Production uses:

- Mini App: `https://digidala.ru/apps/miniapp/`
- Bot: `@DigiDala_bot`
- root: `/opt/digidala`
- services: `digidala-production-web`, `digidala-production-api`, `digidala-production-bot`

## Runtime separation

Production uses its own:

- release directory and `current` symlink;
- SQLite database: `/opt/digidala/data/digidala-production.db`;
- campaign assets: `/opt/digidala/data/campaign-assets`;
- environment file: `/opt/digidala/.env`;
- API port: `8091`;
- web port: `8082`.

The production `.env` must contain the token for `@DigiDala_bot`, a non-empty numeric
`TELEGRAM_SUPERADMIN_IDS` value, and `MINI_APP_URL=https://digidala.ru/apps/miniapp/`.

The real production `.env` is never committed to Git.

`TELEGRAM_SUPERADMIN_IDS` is consumed by the production bot at process startup to bootstrap
administrative access. If it is added or corrected after the bot has already started,
restart only `digidala-production-bot.service`; no code release or API/Web restart is required.

## First-time VPS preparation

The first production setup is intentionally separate from release deployment.
Do not stop or modify the staging services while preparing production.

1. Create `/opt/digidala`, `/opt/digidala/releases`, `/opt/digidala/data`, `/opt/digidala/data/campaign-assets`, and `/opt/digidala/logs` owned by `pixdala`.
2. Create `/opt/digidala/.env` from `.env.production.example` and enter the production bot token and superadmin ID.
3. Keep DNS unchanged until the production services respond on localhost.
4. Install the HTTP bootstrap Nginx configuration and validate `nginx -t`.
5. Point `digidala.ru` to the DigiDala VPS IPv4 (`2.26.199.25`) and, when ready, configure the matching IPv6 record.
6. Obtain the Let's Encrypt certificate for `digidala.ru`.
7. Replace the bootstrap Nginx configuration with `infra/nginx/digidala-production.conf` and reload Nginx.

The one-time production bootstrap described above was completed for `v0.4.0-alpha.50.9.13`.

## Release deployment

The release deployment script reads the Git repository used on the existing VPS by default:

```bash
PIXDALA_REPO=/opt/pixdala/repo /opt/pixdala/repo/scripts/deploy-production.sh <tag>
```

The script creates `/opt/digidala/releases/<tag>`, runs the complete release check, switches `/opt/digidala/current`, installs the three production systemd units, restarts them and performs an HTTPS smoke test.

The same Git tag that passed staging QA must be used for production. Do not rebuild, retag or
edit the source between staging QA and production deployment.

The first production deployment of `v0.4.0-alpha.50.9.13` completed successfully and the
three production services were active after deployment.

## Rollback

```bash
PIXDALA_REPO=/opt/pixdala/repo /opt/pixdala/repo/scripts/rollback-production.sh <tag>
```

Rollback only changes the production `current` symlink and production services.
The staging environment is not touched.

## Post-launch operating rules

- Staging and production keep separate SQLite databases and Telegram bots. Runtime data is never copied from staging into production as part of a normal release.
- Release code changes always pass through the full staged workflow: Windows development → local checks → commit/push/tag → staging deploy and Telegram QA → same-tag production deploy and Telegram QA.
- Content changes already supported by the production bot administration interface do not require a code release.
- The current bot administration flow supports Competitive campaign creation and queue management. Special campaigns do not yet have an equivalent bot-driven creation/queue flow.
- Existing Stars on `@PixDala_bot` remain on that bot; they are separate from the production bot balance of `@DigiDala_bot`.

## Current production verification

For the initial production launch, the following were manually verified in Telegram: bot launch, Main Mini App, Menu Button, Telegram-authenticated Sandbox cell occupation, RU/EN switching, `/admin`, Competitive campaign creation/queueing, Competitive cell occupation and a `1 Star = 1 Pix` purchase.