Create a workspace
Define workspace boundaries, environments, teams, service ownership, and initial access roles.
Read guide →Documentation
Design your production change control workflow.
Explore the concepts, connection patterns, policy models, release stages, rollback plans, and evidence structures behind ReleaseAtlas.
Configure workspaces, connect your production systems, and control the complete release lifecycle.Get started
Move from context collection to controlled releases.
Set up your workspace, connect change sources, and configure policies for your production environment.
Connect change sources
Plan least-privilege access for GitHub, AWS CloudTrail, Terraform, databases, and observability.
Read guide →Define release policy
Model approval, timing, risk, monitoring, and rollback requirements for production changes.
Read guide →Define the operating boundary.
A ReleaseAtlas workspace represents an organization or controlled production boundary. It connects users, teams, services, environments, policies, integrations, and customer context.
- Define development, staging, and production environments.
- Associate services with owners, repositories, pipelines, and runbooks.
- Separate viewer, approver, policy administrator, and action permissions.
Connect change and health sources.
Begin with read-only collection where possible. Document credential scope, account and region coverage, event delay, ownership mapping, and revocation procedure for every connection.
Connection principle
Grant only the access required to collect or execute the exact workflow being enabled. Visibility does not require general production write access.
Build the dependency model.
Map services to APIs, databases, tables, AWS resources, repositories, pipelines, teams, customer tenants, regions, feature flags, and business metrics. Mark inferred relationships separately from verified ownership data.
Define release policies.
Policies evaluate the evidence required before and during a production release.
- Maximum acceptable risk score and warning handling
- Required approvers by service, change type, or risk level
- Change windows, freezes, and scheduling constraints
- Database compatibility, backup, and rollback requirements
- Minimum monitoring readiness and health gates
Design progressive rollout workflows.
Choose stages based on traffic, users, tenants, regions, plans, or application versions. Define entry requirements, health evaluation time, failure thresholds, and approval behavior for each stage.
Coordinate rollback workflows.
A rollback plan can include traffic routing, application version restoration, feature flag shutdown, environment restoration, cache invalidation, database safeguards, health verification, incident creation, and notifications.
Irreversible or high-impact recovery steps should pause for explicit approval rather than execute automatically.
Preserve audit evidence.
Keep source events, ownership, approvals, policies, stage results, health evidence, rollback actions, notifications, and final outcome together in one reviewable timeline.
API, webhooks, and SDKs
Use the API, webhooks, and SDKs to connect ReleaseAtlas with your internal workflows. Scope credentials to the required workspace and permissions, validate webhook signatures, and configure retries and idempotency for reliable event delivery. Contact the technical team for endpoint references and integration guidance.
Plan your implementation
Map your production systems and release policy.
Discuss the change sources, dependencies, health gates, access requirements, and recovery workflows that matter to your team.