The Platform Under Your AI, Run as Code
Terraform-managed infrastructure, deploys that roll back in minutes, and spend guardrails on platforms that ship without them. Cloudflare edge, AWS core: the architecture we run ourselves.
- Timeline
- 2-3 weeks (platform readiness assessment), 4-8 weeks (platform build), ongoing (managed operations)
- Team
- Platform Engineer · DevOps Lead · SRE · Security Engineer
- Typical stack
- Cloudflare (Workers, Zero Trust, WAF, R2, Terraform provider v5), AWS, Terraform, GitHub Actions or GitLab CI, OpenTelemetry, Grafana, Honeycomb, or Axiom
What you get
- Terraform-codified estate: Cloudflare zones, WAF, DNS, Access policies, and AWS resources imported from console click-ops into versioned modules with drift detection
- CI/CD pipelines with progressive delivery: canary releases, percentage traffic splitting, automated rollback, and per-PR preview environments (GitHub Actions or GitLab CI)
- Observability across edge and origin: OpenTelemetry tracing, dashboards, SLOs with error budgets, and alert runbooks wired to your on-call
- Spend guardrails: rate limits, usage circuit-breakers, per-service budgets, and anomaly alerts on platforms that have no native billing kill-switch
- Zero Trust access operations: SSO-backed policies for admin surfaces, internal apps, and CI pipelines, with quarterly access reviews
- Failure-mode design: origin fallback, graceful degradation paths, and multi-CDN options for revenue-critical routes, each one tested, not assumed
- Operations runbook and 30-day support, with an optional managed retainer for monitoring, rule lifecycle, and incident response
Outcomes
- 100% of edge and cloud configuration in version control
- Config changes ship as reviewed pull requests, not console edits
- Rollback rehearsed and timed on every critical service
- Hard spend caps and anomaly alerts where the platform offers none
- Documented, tested failure mode for every revenue-critical path
How we approach it
Hybrid: Cloudflare edge, cloud core
- When:
- You have real infrastructure in AWS or another cloud and want edge performance, security, and economics without a re-platform
- Tradeoffs:
- Two platforms to operate, which is why everything goes into one Terraform workflow. This is the default we recommend and the architecture we run ourselves.
- Best for:
- SaaS, E-commerce, Most mid-market estates
Edge-first
- When:
- New builds where latency, global reach, and per-request economics dominate; request-driven and agent workloads
- Tradeoffs:
- Best economics and simplest operations, but you inherit single-vendor risk and young primitives (10 GB database cap, no native container autoscaling). Needs tested fallbacks.
- Best for:
- Startups, APIs, Agent workloads
Multi-CDN critical path
- When:
- Revenue-critical routes where an edge outage is unacceptable
- Tradeoffs:
- Highest resilience at meaningful added complexity and cost. We scope it to the routes that earn it rather than the whole estate.
- Best for:
- Media, Ticketing, Payments
Where teams use it
Technology & SaaS
Multi-tenant SaaS on hybrid edge
Preview environments per pull request, canary deploys with tenant-aware traffic splitting, per-tenant WAF and rate-limit policies, and egress-free asset serving from R2
Retail & E-commerce
Peak-season resilience
Failure modes load-tested before Black Friday: stale-serve product pages when origin degrades, bot management tuned against scalpers and scrapers, and spend alerts on traffic surges
Media & Publishing
Delivery economics and AI crawler policy
Egress-free delivery from R2: Cloudflare's research puts egress-fee elimination at 7.5 to 27% of a typical monthly cloud bill, and Prisma's published post-mortem cut distribution costs 98% moving 250TB per month of read-heavy traffic off S3 and CloudFront. Plus a deliberate AI crawler policy: allow for answer-engine visibility, block, or charge via Pay Per Crawl
What we need from you
- Read-only access to your Cloudflare and cloud accounts for the assessment
- Existing IaC, pipeline, and repository access
- Last 3 months of platform invoices and usage data
- Incident history and current on-call setup
- Compliance constraints and change-approval requirements
Proof points
- Terraform module sample: a Cloudflare zone with WAF, cache rules, and Access policies fully as code
- Architecture diagram of our own production estate: Cloudflare edge in front of AWS origin
- Spend guardrail pattern: circuit-breaker design with alert thresholds and a kill path
- Runbook excerpt: rollback procedure with timings from a rehearsal
Built for procurement
- Change management: every configuration change as a reviewed pull request with full audit trail and rollback reference
- Access control: SSO-backed Zero Trust policies on admin surfaces, RBAC, quarterly access reviews
- Incident response: severity definitions, escalation paths, and response-time commitments in the retainer SLA
- Cost governance: budgets per service, anomaly alerts, monthly spend review with named owners
- Resilience evidence: documented failure modes with rehearsal dates and measured recovery times
- Compliance support: audit-ready change logs and access records for SOC 2 and ISO 27001 programs
Frequently asked questions
Three things in 2 to 3 weeks: configuration review (WAF coverage, cache correctness, access policies, IaC drift), spend exposure (one public post-mortem documents a $5 per month Cloudflare plan producing a $4,868 invoice in a single billing cycle from runaway database writes, refunded only after an 18-day escalation, and we check whether that class of failure is open on your estate), and resilience (what actually happens when your CDN, origin, or DNS fails). You get a prioritized fix list with effort estimates, and we install the highest-value guardrails before the engagement ends.
Not always. If you have a platform engineer with capacity, the assessment report alone may be enough: it is a prioritized fix list your own team can execute. Outside help earns its fee when configuration lives in consoles nobody has mapped, when deploys depend on one specific person being available, or when a billing or outage surprise has already happened. If the assessment says your estate is healthy, we tell you that and leave.
Three shapes, priced differently. The platform readiness assessment is a fixed fee, scoped to the size of your estate. Platform builds are scoped sprints priced after the assessment, so you buy a known backlog, not an open-ended engagement. The managed retainer is a flat monthly fee tied to estate size and response commitments. We publish the model rather than a single number because a two-zone startup and a forty-domain enterprise are not the same engagement; the assessment gives you the exact figure for yours.
Because it is where we run our own production, and because the platform outgrew its tooling. Cloudflare shipped an application platform faster than its operational ecosystem matured: Containers went GA in April 2026 and private networking into AWS is in beta, yet the v5 Terraform provider launched rough and billing still has no kill-switch. Teams adopting the platform need exactly the operational discipline this service installs. We work on AWS-only estates too; the practice is platform engineering, Cloudflare is the edge specialization.
By designing for the outage instead of pretending it won't recur. Cloudflare's own post-mortems cover its worst outage since 2019 (November 2025, roughly three hours of network-wide 5xx errors) and a February 2026 automation bug that withdrew routes for a quarter of its BYOIP customers for six hours; every major cloud has equivalents. We map your revenue-critical paths, define what each one does when the edge fails (serve stale, fall back to origin, switch CDN), and test those paths on a schedule. You keep Cloudflare's economics with failure modes you have actually rehearsed.
Yes, this is one of our most common starting points. The v5 provider was generated from Cloudflare's API schema and, by Cloudflare's own status updates at the time, shipped with issues affecting about 15% of resources; for months Cloudflare told customers there was no urgency to leave the supported v4 provider while fixes landed. We migrate v4 estates resource by resource, import unmanaged console changes, add drift detection, and pin provider versions so upgrades happen on your schedule, not the provider's.
Yes, and they should. Edge configuration that drifts separately from the infrastructure behind it is how outages start. We structure workspaces by domain (network, edge, compute, access) with shared modules, split state, and one review pipeline, so a single pull request can change a DNS record, a WAF rule, and the origin behind them together, reviewed once and promoted from staging to production.
For application access, yes. Each internal app sits behind identity-checked policies (SSO, device posture, per-app rules), so people reach the application, never the network. Rollouts run both systems side by side, moving apps in phases, and retire the VPN once every app and admin surface is covered. Two honest limits: site-to-site connectivity and some legacy protocols still need network-level tunnels, and the migration order matters more than the tooling. We sequence it so nobody loses access mid-transition.
Monitoring and alert response, WAF and bot rule lifecycle (tuning rules as your traffic and attack patterns change), upgrade and migration windows, a monthly cost and posture review, and named engineers who know your estate. It is sized for teams that need platform coverage without hiring a dedicated platform engineer.
Yes, with the same discipline we apply to infrastructure spend: route model calls through a gateway that logs every request, caches repeated prompts, enforces per-service budgets, and alerts on anomalies before the invoice arrives. Sudden spikes usually trace to a retry loop, an unbounded agent, or a silent model or pricing change; a gateway makes each of those visible the day it starts. For routing across providers, this pairs with our AI Platform & Orchestration service.
AI Infrastructure & Governance Planning covers the controls above it: model routing and budgets, guardrails, and a record of what each agent did. This assessment covers the layer underneath: infrastructure as code, deploys, observability, cloud access, spend and resilience.
Yes. Cloudflare now blocks AI crawlers by default for every new domain, and by its own count its customers already send over 1 billion HTTP 402 payment-required responses to bots and crawlers every day; its Pay Per Crawl program turns those refusals into a payment channel. We set the policy deliberately: which crawlers you allow for search and answer-engine visibility, which you block, and where paid crawling makes sense for your content. We run this configuration on our own site.