A control plane you configure by hand drifts, and drift on a delivery platform is expensive: a stale rule caches the wrong bytes, a forgotten certificate expires, a manual purge misses a region. Treating resources, rules, and certificates as code makes changes reviewable, reproducible, and reversible. This page covers the API and infrastructure-as-code model and the safety rails that keep automation from making a fast mistake.
API and infrastructure as code
Everything the console can do should also be expressible through an API, and everything you do through the API repeatedly should live in version control. The pattern:
- Declare resources, rules, certificates, and origins in code.
- Plan to see the diff between declared and live state.
- Review the diff like any other change.
- Apply through CI, not a laptop.
- Detect drift on a schedule and reconcile.
Terraform-style providers are the common implementation; a thin wrapper over the API is fine when the provider lags. Either way, the source of truth is the repository, and the console becomes a read-only view for most engineers.
Versioning resources, rules, and certificates
The unit you version is the whole delivery config, not a single setting.
- Resources and rules — keep them in the same repository as the services that depend on them, so a change to a path layout and a change to path policy land in one review.
- Certificates — store references and metadata, never private keys. Rotate on a schedule driven by automation, and let the plan surface an imminent expiry as a diff.
- Immutable names for media — version content in the path (
/clip-4821/v7/seg-003.ts) so configuration changes rarely require a purge at all. - Staged rollout — apply to a non-production hostname first, then promote. Keep a tested rollback path, because “apply again with the old file” is not always safe when state is shared.
Wiring purge and prefetch into internal workflows
Cache invalidation should be an event in your existing pipelines, not a manual chore. Two integrations pay off immediately:
- Publish pipeline → prefetch. When new media is released, warm the hot set before traffic arrives so the first viewers do not stampede origin. Prefetch deliberately — see Purge, invalidation, and prefetch.
- Takedown and rights pipeline → purge. When content is removed for consent, likeness, or legal reasons, the purge must be automatic, auditable, and immediate, and it must be idempotent so a retried job cannot leave a region stale.
Keep purge credentials scoped to purge only. A token that can purge and also rewrite TLS config is a token that turns a pipeline bug into an outage.
CI safety
Automation moves the risk from typos to pipelines, so guard the pipeline.
- Plan before apply, always. Require the plan in the pull request and fail the run if the plan is empty or unexpectedly destructive.
- Protect production state. Use separate state, credentials, and approval for production; no developer token should be able to apply to prod.
- Least privilege. Scope each CI credential to the resources and actions that pipeline actually needs.
- No secrets in state or logs. Inject tokens at runtime; redact API responses.
- Canary changes. Route a small slice first and watch byte offload and error rate before promoting.
- Freeze windows. Block applies during major live events unless an explicit override is recorded.
A useful rule: if a change cannot be described as a reviewed diff, it should not touch production delivery.
Where AdultInfra fits
AdultInfra helps teams model delivery as code, separates production credentials, and wires purge and prefetch into publish and takedown workflows so cache state tracks content state automatically. Start from the platform overview or contact us with your current tooling.