TMA.sh

Product

Versioned Telegram releases from commit to production

Create preview releases for every meaningful change, approve them with your team, and promote or rollback with full release history.

Start deploying Learn More

• Preview links per release candidate

• Promotion gates for controlled launches

• Rollback to any known-good version

• Release history across app, bot, and API

Problems this solves

Manual launch coordination

Before

Teams coordinate deploy windows in chat and hope app, bot, and API updates land in the correct order.

After

Each deploy becomes a release candidate with a clear promotion step and immutable release history.

Risky production changes

Before

Teams discover integration issues only after production launch because preview and production diverge.

After

The exact reviewed candidate is promoted, keeping preview and production behavior aligned.

Slow incident response

Before

Rollback means rerunning builds or cherry-picking patches while incidents are active.

After

Rollback points are built into the release model, reducing time-to-recovery.

Capabilities

Release candidates for every change

Each deployment gets a traceable release ID and preview environment before it reaches production.

Promotion gates

Control who can approve and promote releases for safer launch governance.

Preview parity

Review the same build artifact you intend to promote, instead of rebuilding at launch time.

Rollback points

Restore a known-good release instantly when regressions appear.

Unified release timeline

Track app, bot, and API changes in one chronological release history.

Operational auditability

Keep a clear record of what changed, who approved it, and when it went live.

Implementation blueprint

Phase 1

Connect repository

Bind your Git workflow to release objects.

  1. 1. Connect GitHub repository in dashboard
  2. 2. Confirm default branch and deploy trigger
  3. 3. Run initial deployment and validate release ID

Phase 2

Adopt preview review

Move launch decisions before production.

  1. 1. Share preview links with QA and product
  2. 2. Validate app, bot, and API behavior together
  3. 3. Approve only tested release candidates

Phase 3

Standardize promotion and rollback

Operationalize safer launches.

  1. 1. Promote exact approved release candidate
  2. 2. Use rollback playbook during incidents
  3. 3. Track deployment outcomes in release history

Operational playbooks

Safe weekly launch

4 steps
  1. 1

    Run preview sanity checks for app and bot flows

    Open detail

    Use a fixed checklist for auth, payments, and critical command paths before sign-off.

  2. 2

    Collect product and QA sign-off on the candidate

    Open detail

    Record approvals against the release ID so everyone validates the same artifact.

  3. 3

    Promote the approved candidate without rebuilding

    Open detail

    Promotion should use the exact previewed artifact to avoid rebuild drift at launch.

  4. 4

    Monitor release health during the first 15 minutes

    Open detail

    Track error rate, latency, and command failures with a predefined rollback threshold.

Incident rollback

4 steps
  1. 1

    Identify the active release ID in timeline

    Open detail

    Confirm which release introduced the regression before applying remediation.

  2. 2

    Select the previous known-good candidate

    Open detail

    Pick the last stable release with passing checks and no incident markers.

  3. 3

    Execute rollback and verify critical user paths

    Open detail

    Immediately re-test login, payments, and core bot commands after rollback.

  4. 4

    Attach incident notes to the failed release

    Open detail

    Document impact, root-cause hypothesis, and follow-up tasks in release history.

Hotfix promotion

4 steps
  1. 1

    Create a hotfix candidate from targeted commit

    Open detail

    Keep scope narrow to reduce risk and shorten review time.

  2. 2

    Validate affected flow with focused smoke tests

    Open detail

    Run impacted scenarios first, then confirm baseline production-critical checks.

  3. 3

    Promote hotfix in a controlled window

    Open detail

    Assign one release owner and communicate exact rollout timing to stakeholders.

  4. 4

    Annotate timeline with cause and remediation

    Open detail

    Capture why the issue happened and what prevention change was adopted.

Reference architecture

Release model overview

A single release object captures build output and runtime changes before promotion.

  • • Teams shipping frequent Telegram product updates
  • • Products needing release audit trails
  • • Engineering orgs replacing custom deploy scripts
  • • Ops teams focused on fast rollback during incidents

Flow view

push -> build -> release_candidate#2184
release_candidate#2184 -> preview environment
approval -> promote(release_candidate#2184)
incident -> rollback(release_candidate#2183)

Resources and docs

Build Pipeline

Detailed deployment lifecycle and promotion stages.

Open resource

Preview Environments

How preview releases are generated and validated.

Open resource

First Deploy Guide

End-to-end setup from repository to first release.

Open resource

CLI Commands

Trigger and inspect deployments from CLI workflows.

Open resource

Frequently asked questions

Can I promote without rebuilding?

Yes. Promotion applies the approved release candidate artifact so launch behavior matches what you reviewed.

Is rollback version-aware?

Yes. Rollback selects a previous release object rather than rerunning ad-hoc deploy steps.

Does this cover bot and API changes too?

Yes. TMA.sh models release state across app frontend, bot workflows, and API routes.

Can teams enforce review before launch?

Yes. Promotion gates and team process can enforce preview approval before production promotion.

Ship Telegram releases with control

Use one release system across app UI, bot commands, and API routes.

Start deploying Build Pipeline Docs