Governed deployments across every cloud you ship on
Launch your app without configuring every service yourself. LaunchOps coordinates Stripe, GitHub, Cloudflare, Vercel, Supabase, and AWS from one place: it proposes each change, you approve it, and it applies and re-checks the result. Under the hood sits one declarative tenant manifest and a plan, approve, apply, verify flow across six adapters, each labeled below with its real validation status.
# 1. Plan all vendors against your manifest
enterprise-skills launch plan
# 2. Approve risky actions interactively
enterprise-skills launch approve <action-id>
# 3. Apply and verify across every adapter
enterprise-skills launch apply <plan-id>
# 4. Watch for drift
enterprise-skills launch watch --interval 15m
Multi-cloud deployment, with a governance harness around it
Every service change follows the same path: proposed, approved, applied, re-checked. LaunchOps brings the Enterprise Skills governance approach to the deployment layer.
- 01
Declarative tenant manifests
Describe Stripe products, GitHub repo settings, Cloudflare DNS, Vercel projects, and Supabase posture in one YAML manifest. Vendor overrides keep edge cases first-class.
- 02
Plan → approve → apply → verify
Every adapter computes a typed diff, waits for human approval on risky actions, applies through governed APIs, and verifies the live state. No more 'did it deploy?' guesswork.
- 03
Drift-aware Launch Reports
Continuous drift detection produces dated HTML/PDF Launch Reports your auditors can review. Every change is hash-fingerprinted into an append-only audit log, scoped, and re-runnable.
First-party adapters
Six first-party adapters, each labeled with its real validation status; nothing is marked beyond what has run against live infrastructure. The pluggable adapter contract makes the next vendor straightforward.
Vercel
Projects, env vars, domains
Cloudflare
Zones, DNS records, WAF baseline
Stripe
Products, prices, webhooks
GitHub
Repo settings, branch protection, encrypted secrets
Supabase
Project posture scan: read-only by declaration; apply actions are refused
AWS
Deployed ECS task-definition env keys and IAM effective allow-set: read-only by declaration. Apply actions are refused, and this adapter offers no AWS writes
How a launch flows
Four phases, the same shape across every adapter, every environment.
01
Author a tenant manifest
One YAML file describes the desired state across vendors. Templates ship for SaaS, marketplace, and internal-tool launches.
02
Plan the launch
enterprise-skills launch plan computes a typed diff per vendor and surfaces risky actions for approval, and refuses to plan from vendors it could not read. Secrets resolve at apply time from your environment; values never land in the manifest.
03
Approve and apply
Reviewers approve specific actions in the CLI. Adapters apply via governed APIs and stream evidence to the audit log.
04
Verify and watch
Each adapter re-reads the live state to confirm convergence. The drift watcher flags out-of-band changes and produces a fresh Launch Report.
Built for review, not for risk
LaunchOps was designed so that adopting it does not enlarge your attack surface or pull customer secrets through a third party. The hard parts are by-default.
- Your vendor tokens stay in your environment and CI secrets. LaunchOps runs where you run it, and no central service custodies credentials. (A hosted control plane with BYO-dataplane is a designed v2, not shipped.)
- Every action is bounded: scoped tokens, rate-limited adapters, and per-tenant quotas.
- Hash-fingerprinted Launch Reports, an append-only audit log, and reproducible plans give procurement and SOC 2 reviewers what they need.
Bring your stack. Keep your governance.
LaunchOps Agent ships as part of the Enterprise Skills harness. Get early access and we will help you wire up your first manifest end-to-end.