Create a workspace
Define workspace boundaries, environments, teams, service ownership, and initial access roles.
Read concept →Documentation preview
Design your production change control workflow.
Explore the concepts, connection patterns, policy models, release stages, rollback plans, and evidence structures behind ReleaseAtlas.
Product documentation is a prototype and will expand with verified implementation details.Get started
Move from context collection to controlled releases.
Use this documentation architecture to plan an implementation. Exact configuration steps and API contracts will be added as product capabilities become available.
Connect change sources
Plan least-privilege access for GitHub, AWS CloudTrail, Terraform, databases, and observability.
Read concept →Define release policy
Model approval, timing, risk, monitoring, and rollback requirements for production changes.
Read concept →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
Public API, webhook, and SDK contracts are not yet published. Future documentation should include authentication, scopes, versioning, idempotency, pagination, rate limits, error models, event signing, retries, and deprecation policy before integrations depend on them.
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.