Releases
Immutable versioned snapshots of your app configuration with deployment, rollback, and change history tracking.
MechaMental tracks every change to your app as a commit and lets you package any point in time as an immutable release. Releases are what you deploy to environments.
Creating a Release
Open the Releases Tab
Navigate to your app and open the Releases tab to see all existing releases and their states.
Click Create Release
Click the Create Release button to open the Create Release dialog.
Fill in Release Details
| Field | Description |
|---|---|
| Release Tag | A version identifier, e.g., v1.0.0, v2.3.1 |
| Description | A summary of what this release includes |
Click Create to snapshot your app's current configuration.
Release States
Every release moves through a defined lifecycle:
| State | Description |
|---|---|
| Ready | The release has been created and is available for deployment. It is not yet serving traffic. |
| Active | The release is deployed to one or more environments and actively serving traffic. |
| Archived | The release is no longer deployed. It remains available for reference, comparison, or re-deployment. |
Create Release → Ready → Deploy to Environment → Active
↓
(new release deployed)
↓
ArchivedDeploying a Release
To deploy a release to an environment:
- Find the release in the Releases tab
- Click Deploy to Environment
- Select the target environment (Production, Staging, or Development)
- The release is bound to the environment and begins serving traffic immediately
The deployment is atomic — the new release replaces the old one with no downtime.
Immutable Guarantees
Once created, a release cannot be modified. This guarantees that what you tested is exactly what gets deployed. Any new changes require a new release.
Rollback
If a deployed release causes issues, you can instantly revert:
- Go to the Releases tab
- Click Rollback to Previous on the active release
- The previous release is re-bound to the environment
Because every release is an immutable snapshot, rollback is instant and safe — no configuration is lost or overwritten.
Change History
The Change History view provides a unified timeline that shows three types of events:
| Event Type | What It Shows |
|---|---|
| Commits | Individual changes to pipelines, endpoints, and configuration — with field-level diffs |
| Releases | Release creation events with their tags and descriptions |
| Deployments | When a release was deployed to or removed from an environment |
The timeline lets you trace the full history of your app: what changed, when it was released, and where it was deployed.
Commit Diffs
Each commit in the Change History shows field-level diffs — you can see exactly which properties were added, modified, or removed. This includes changes to:
- Pipeline stages and steps
- Step configuration, prompts, and tool bindings
- Endpoint paths and schemas
- App settings
abc1234 Update system prompt for chat pipeline 5m ago
def5678 Add source_query step to preprocessing 2h ago
ghi9012 Configure tool timeout for external API 1d ago
─────── Release v1.2.0 created 1d ago
─────── v1.2.0 deployed to Staging 1d ago
─────── v1.2.0 deployed to Production 22h agoDraft Workspace
Your app always has a draft workspace where you make edits. This is separate from any deployed release:
- You can freely modify pipelines, endpoints, and configuration in the draft
- Changes in the draft do not affect any deployed environment
- When ready, commit your changes and create a new release
- The draft workspace continues to be mutable for your next round of changes
Safe Iteration
The separation between draft workspace and deployed releases means you can experiment freely without risk to production traffic. Nothing goes live until you explicitly create a release and deploy it.