Your business owns the runtime, credentials, release approval, monitoring, support, and rollback. SwarmCraft supplies source and delivery context; it does not operate customer infrastructure.
Choose an operable stack
Choose the user surface, backend runtime, persistence boundary, and deployment target together. Prefer technology the responsible team can build, patch, observe, restore, and support. Record the decision and its constraints in the repository instead of relying on a generated recommendation alone.
Prepare the release
Before approval, identify:
- the reproducible build command and immutable artifact or image
- environment-specific configuration and the owner of each setting
- secrets supplied by the deployment platform, never committed to source
- schema migration order, compatibility window, backup, and restore procedure
- health, readiness, dependency, and functional checks
- logs, metrics, alerts, retention, and the responding operator
- release approver, rollback trigger, rollback artifact, and recovery steps
Do not deploy an unresolved placeholder, example credential, local-only endpoint, permissive development setting, or unreviewed migration.
Deploy through trusted infrastructure
- Build and validate the release artifact from the reviewed commit.
- Back up affected state and prove the restore path when persistence changes.
- Apply configuration and secrets through the target platform.
- Run migrations in the reviewed order.
- Deploy the immutable artifact through the team's normal approval path.
- Verify health and dependencies.
- Exercise the real workflow, including one important failure or recovery path.
Docker, Kubernetes, a managed application platform, or another runtime can all be valid. Use the one the accountable team already knows how to operate.
Decide whether to keep or roll back
Keep the release only when the target workflow works, data remains correct, access controls hold, and monitoring is receiving useful signals. Roll back when a defined safety, data, availability, or workflow threshold is crossed. If a migration cannot be reversed, use the reviewed forward-recovery procedure rather than improvising.
Record the deployed version, approval, functional evidence, incidents, and follow-up work. Monitor the first release closely and turn observed defects or operating gaps into new board tasks.
Success means an operator can identify what is running, verify the workflow, see failure, recover service and data, and contact the responsible support owner. The terminal outcome is source, release evidence, and an operating path controlled by your business. Return to How SwarmCraft works when planning the next release.