Publish Workflow
Tapistry handles build, security, and promotion so you can focus on delivering great APIs. This guide summarizes the publish pipeline and the guardrails that keep every release safe.
1. Build, test, publish
Start new APIs with the CLI scaffolds, iterate locally, and publish to the edge channel when you are ready:
tapi init --template python-fastapi --name my-awesome-api
cd my-awesome-api
# edit handlers, write tests
tapi test
tapi publish --channel edge
tapi status my-awesome-api
2. Automated security gates
Every publish runs a suite of checks before code reaches the edge environment:
- Image scanning: signature verification, SBOM generation, and vulnerability scanning (cosign, Grype).
- Code analysis: dependency scanning, static analysis, license compliance, and minimum test coverage (90%).
- Runtime guardrails: egress allowlists, tool credential policies (PMK, DMK, UBYOK), rate limiting, and PII redaction.
3. Dependency impact review
Tapistry tracks relationships between APIs so downstream consumers are protected:
# Inspect dependents before publishing a breaking change
tapi deps --api my-awesome-api --show-dependents
- Dependent owners receive email, Slack, and dashboard notifications when you publish.
- Contract and integration test suites run automatically to detect incompatibilities.
4. Channel promotion
Ship iteratively on edge, then promote to stable once all policies pass:
tapi promote my-awesome-api --from edge --to stable --version v1.2.3
tapi promote-status my-awesome-api
Promotion requires green security gates, successful dependent tests, and human approval from the API owner.
5. Rollback strategies
Automated monitors trigger emergency rollbacks when error rate, latency, or dependency tests regress. You can also initiate a manual rollback:
tapi rollback my-awesome-api --to-version v1.2.2
# or perform a canary rollback
tapi rollback my-awesome-api --to-version v1.2.2 --strategy canary --percentage 50
Channel summary
Channel | Purpose | Policies | Availability |
---|---|---|---|
Edge | Development and QA | Lenient (warnings only) | 99.0% SLA |
Stable | Production traffic | Strict (blocks on violations) | 99.9% SLA |
Archive | Deprecated versions | Read-only access | 99.0% SLA |
Best practices
- Publish to edge first, monitor metrics, then promote once integration tests pass.
- Pin dependencies and prefer minimal base images to reduce attack surface.
- Define specific egress allowlists and keep tool credentials scoped to the minimum privileges required.
Need a deeper dive? Start with the Creator Quickstart for a CLI-focused walkthrough, then review the full publish flow guide.