Deployment¶
See Install for the four supported paths (pip / Docker / compose / Helm). This page covers ops concerns specific to each. For a Railway-specific walkthrough see the dedicated Railway deployment guide.
Railway / Render / Fly / Heroku¶
The repo ships with Procfile (web: python main.py) + nixpacks.toml
+ requirements.txt — every PaaS that speaks one of these picks the
app up without extra config. Set API_ENABLED=true and the platform's
injected $PORT routes to the FastAPI app. For Railway specifically,
start with the dedicated guide.
Single-holder pyrofork session¶
The pyrofork session file can be held by exactly one process at a time. That's why:
- The Helm chart uses
strategy: Recreateinstead ofRollingUpdate. replicaCount=1is the only safe default. Scaling requires external session brokering (planned for a later phase).
Sessions & persistence¶
- Mongo is the durable store. Back up
tickets,users,projects,teams,roles,macros,kb_articles,analytics_daily. - The session file (
*.session) is created next tomain.pyat first boot. Mount a volume in Docker / Helm to preserve it across restarts and avoid Telegram re-logins.
Updating¶
- Bump
image.tag. helm upgrade xtv-support …or redeploy compose.- Migrations are idempotent — Phase 3/5/6/9 bumps all carry safe
update_manybackfills. First boot after a major version should show the newSCHEMA_VERSIONindb.backfill_defaults_done.