Production is part of development.
Telemetry and incidents belong to the development context and to the Definition of Done. Astvyr rehearses the change in a production-like Twin, releases it under policy, watches the outcome and keeps the rollback ready.
Five fidelity levels, chosen by risk, cost and data policy.
A Twin is ephemeral by construction: it has an owner, a TTL, a cost and a cleanup status from the moment it exists.
Local environment, sanitised fixtures, fastest loop.
Ephemeral preview of the service with synthetic data.
Connected dependencies and contracts, still synthetic data.
Production-shaped data, sanitised, with TTL and verifiable deletion.
Real traffic replayed with side effects suppressed; differential assertions.
- Environment lifecycle: create, pause, resume, clone, destroy, with cost, owner, TTL and health in view.
- Traffic replay suppresses side effects and compares schema, status, latency, side effects and downstream calls.
- Every copy carries a TTL, encryption and verifiable deletion. Sensitive tenants can forbid snapshots entirely.
- Auto-destroy and automatic cleanup, with an orphan scanner running independently of the scheduler.
Thirty-six capabilities, from infrastructure discovery to the restore drill.
The delivery surface is discovered and explained before a change is allowed to move: builds, artifacts, environments, configuration, migrations and privileged operations.
Infrastructure discovery
Dockerfiles, Compose, Kubernetes manifests, Helm, Terraform, Pulumi, Ansible and cloud configs are detected.
Delivery inventory
Services, runtimes, dependencies, environments, pipelines and gaps appear in one inventory.
Service map and drift
A service map and environment drift across local, preview, staging and production.
Golden path validation
Infrastructure is validated against organisation golden paths, policies and supported modules.
Infrastructure explanation
Infrastructure changes are explained in natural language with resource and cost impact.
Reviewable delivery changes
Infrastructure and pipeline changes pass diff, validation, policy and rollback planning.
Build plans
Reproducible, cached, isolated and architecture-aware.
Artifact chain
Content-addressed digests and immutable promotion.
SBOM
Generated for product and platform artifacts, in an exportable format.
Signing
Organisation-controlled identities and key management.
Provenance
Build inputs, runner, steps and attestation are linked to the release.
Artifact policy
Unsigned, vulnerable, unapproved or stale artifacts are blocked.
Build reproducibility
Containerisation, buildpacks and reproducible builds produce attestations, SBOM, signed artifacts and a repeatable result.
CI/CD and GitOps integration
Status is imported and approved workflows run without bypassing existing controls.
Environment manager
Ephemeral environments are created, paused, resumed, cloned and destroyed.
Environment services
DNS, certificates, databases, queues, feature flags and seeded data are orchestrated with the environment.
Environment inventory
Cost, owner, TTL, health and last activity are shown in one inventory.
Quota and cleanup
Quota is held by team or project; cleanup is automatic, with exceptions for investigations.
Configuration promotion
Configuration carries a version, owner, schema, target scope and audit; secrets are never stored in plaintext.
IaC gates
Plan and apply are separated; a destructive change needs an explicit gate and a recovery plan.
Adapter coverage
Cloud, Kubernetes, VPS and serverless adapters pass a capability matrix, and an unsupported action is explained.
Multi-cloud abstraction
A common workflow, without hiding dangerous provider-specific differences: those are surfaced and need an explicit decision.
Drift remediation
Drift is tied to a source of truth and opens a remediation Mission.
Migration analysis
Schema and data migration analysis with ownership and dependency mapping.
Expand, migrate, contract
An expand/contract plan with a compatibility window and deployment ordering.
Lock and duration estimation
Estimated against representative data before the migration is scheduled.
Migration rehearsal
A backup and restore check, an apply rehearsal, and a rollback or forward-fix strategy.
Migration state
Tied to the application release and its observation window.
Database release compatibility
The release plan prevents incompatibility between the old and the new version and includes a cleanup gate.
Cloud and Kubernetes operations
Managed cloud APIs and customer-hosted runners: Kubernetes covers workloads, policies, rollout, events, logs and health; cloud covers identity, compute, networking, storage, databases and cost.
Plan, review, apply
The default path is plan, review and apply, not direct chat-to-production.
Safe runbooks
Versioned, bounded and dry-run capable, requiring policy approvals and writing audit.
Secret broker and workload identity
An agent receives a short-lived scoped credential; the secret value never reaches a prompt, a log or evidence.
Cost impact
A plan shows the monthly delta range, its assumptions and the high-cost resources.
Backup and restore verification
A scheduled restore drill produces evidence of RPO/RTO and integrity, rather than only the presence of a backup.
Privileged operations
No unrestricted root automation: a privileged operation needs an approved identity, a scoped action and full audit.
Seven checks stand between a plan and production.
The preflight reads the target environment rather than the intention: health, telemetry, verified backups, approved identity, capacity, quota and runbooks.
Health checks
Health checks exist for the services the change touches and can be read while the rollout proceeds.
Observability
Telemetry is in place, so metric gates and post-deploy verification can be evaluated during the rollout.
Backups
Backup and restore are verified rather than assumed: a restore drill produces evidence of RPO/RTO and integrity.
Security
Privileged operations run under an approved identity and a scoped action, with full audit.
Scaling
Capacity and scaling behaviour are assessed for the target environment before the change is deployed.
Quotas
Quota headroom for the target environment and its team or project is confirmed before deployment.
Runbooks
A versioned, bounded and dry-run capable runbook with policy approval covers the operation.
Seven strategies, one gate model.
Rollout is driven by metrics and policy, not by optimism.
CANARY STAGES
Traffic moves to the next stage only when the metric gates pass. On error growth the controller pauses, keeps telemetry, rolls back on pre-approved thresholds and moves the Mission to REWORK. The agent does not “try again” in production.
- Rollback is designed before the release, not during the incident.
- If rollback is unsafe, the plan is a forward fix or a dual-write compatibility window.
- Automatic rollback applies only to pre-authorised release classes with explicit metric conditions.
- On error growth the Release Controller pauses, keeps telemetry, rolls back on pre-approved thresholds and moves the Mission to REWORK. The agent does not “try again” in production.
- Destructive data actions, large traffic shifts and account-level cloud changes require emergency approval or a signed runbook.
Every strategy names the controls it needs.
What has to exist for the seven strategies above to be safe — from rolling and blue-green to canary, flags, shadow, rings and platform channels.
Rolling
Health checks, surge and unavailable policy, and abort.
Blue-green
Preview, switch, validation and rapid revert.
Canary
Traffic stages, cohort selection, metric analysis and automatic rollback.
Feature flag
Progressive exposure that is independent of the binary deployment.
Shadow
Duplicate traffic, suppress side effects, compare behaviour.
Ring-based
Internal, then beta, then regional, then global rollout.
Mobile and desktop
Phased channels, crash and telemetry gates, and update rollback where the platform supports it.
Five gate groups compare, decide, and can hand the call to a human.
Technical, business, security and comparison gates run against control and baseline; the decision gate promotes, pauses, rolls back or asks for judgment.
Technical
Error rate, latency, saturation, crashes, queue lag and resource use.
Business
Conversion, payment success, workflow completion and support signals.
Security
New alerts, permission anomalies and policy violations.
Comparisons
Canary against control, current against baseline, segment against global.
Decision
Promote, pause, rollback, request human judgment or continue observation.
An exhausted error budget is a release decision.
Availability is not a dashboard number. When the budget for a service is spent, policy can tighten the gates or stop the release outright.
Live incident timeline
Human, agent, deployment and alert events land on one timeline, so the sequence of an incident is reconstructed rather than remembered.
Error budget gating
SLO and error budget are assessed alongside release risk. When a budget is exhausted, policy can tighten the gates or stop the release.
Six pre-checks decide whether a rollback is available at all.
Availability, configuration, database and feature-flag state are checked before the window opens.
- Rollback is designed before the release, not during it.
- Availability of the previous artifact is checked.
- Configuration compatibility between the two versions is checked.
- Database constraints are checked.
- Feature flag state is checked.
- If rollback is unsafe, the release plan uses a forward fix or a dual-write compatibility strategy.
A release starts only inside a window policy allows.
Windows, freezes, holidays, blackouts and conflicts are resolved before the change is scheduled.
Maintenance windows
Windows in which a change may proceed. Policy checks the calendar, and a release does not start in a disallowed window.
Freezes
Periods in which normal releases are held; the emergency path is the route through them.
Regional holidays
Holidays are held per region, so a window acceptable in one region is not assumed for another.
Customer blackout periods
Periods declared by the customer in which no change reaches their services.
Dependent release conflicts
Conflicts between dependent service releases are detected before the change is scheduled.
Migration conflicts
Conflicts between migrations are detected in the same pass as release conflicts.
Emergency override
Requires a documented reason, a time limit, heightened logging and an after-action review.
Fourteen states, each naming the next move.
A release can always be traced to the condition that moved it forward, paused it or sent it into recovery.
A candidate change set is selected. Next: ASSEMBLING.
Artifacts, evidence and config are assembled. Next: READY_FOR_APPROVAL or BLOCKED.
All machine gates have passed. Next: APPROVED or REJECTED.
The required approvals are in place. Next: SCHEDULED or DEPLOYING.
Waiting for the change window. Next: DEPLOYING or EXPIRED.
The first rollout stage has started. Next: VERIFYING, PAUSED or ROLLING_BACK.
Stage health is evaluated. Next: PROMOTING, PAUSED or ROLLING_BACK.
Traffic and exposure increase. Next: VERIFYING or OBSERVING.
Full rollout with active observation. Next: SUCCEEDED or ROLLING_BACK.
The recovery plan is running. Next: ROLLED_BACK or FAILED.
The outcome held through the window. Next: CLOSED.
The previous version is restored. Next: CLOSED plus a corrective Mission.
Incident coordination is required. Next: an incident and manual recovery.
The release record is immutable. Only linked follow-up remains.
Vendor-neutral telemetry and a lens from symbol to outcome.
Astvyr does not require you to copy all telemetry. Queries can run on your side.
Vendor-neutral telemetry
OpenTelemetry semantics. Queries can run customer-side; Astvyr does not require copying all telemetry.
Production Lens
From a symbol or a trace to the service, the commit, the Mission, the evidence and the rollout stage.
Incident lifecycle
Detect, triage, contain, fix, recover, learn — an incident does not close until every corrective action has an owner.
Safe automation
AI-assisted triage is read-only by default. Write access requires a runbook or policy, with a blast-radius estimate and an abort path.
Ten states, and no quiet closure.
An incident does not close until every mandatory corrective action has an owner, a due date and closure evidence.
DETECTED → TRIAGED → DECLARED → MITIGATING → STABILIZED → RECOVERING → MONITORING → RESOLVED → REVIEWED → ACTIONS_VERIFIED
SEVERITY MODEL
- SEV-0Confirmed active compromise or unsafe global release controlMinutes; executive, security, legal and comms; risky actions frozen
- SEV-1Major regional outage, data isolation risk, release controller unavailableAcknowledged within 15 minutes; incident commander; continuous updates
- SEV-2Material degradation or a subset of capability unavailableAcknowledged within 30 minutes; service owner and support
- SEV-3Limited defect with a workaroundBusiness-hours objective, standard ticket
- SEV-4Cosmetic issue, request or documentation gapBacklog or SLA by plan
SUPPORT TIERS
- CommunityDocs, forum, public issue routes. Best effort, with knowledge and transparent status.
- TeamTicket and email, in-product support, business hours by region, response targets with diagnostics.
- BusinessPriority ticket and chat, extended regional coverage, faster response, onboarding, usage review.
- EnterpriseDedicated escalation and a technical account manager, 24x7 for critical, architecture review, incident reports.
- StrategicJoint success and an engineering channel, contract-specific, with capacity and rollout planning.
Rollback is designed before the release, not during the incident.
If rollback is unsafe, the plan is a forward fix or a dual-write compatibility window — decided in advance, recorded in the evidence bundle.