Cloud & Edge
Infrastructure as code and automation for cloud, edge, and network operations.
We turn repeated manual work into controlled, observable workflows across cloud, edge, and network platforms: Terraform baselines, Python and API integrations, serverless functions, and reports built from platform APIs. Everything is versioned, documented, and handed over, so your team can run it after the engagement ends.
Platforms
- Terraform
Who this is for
Teams that make the same change across many accounts, zones, or devices by hand, fight configuration drift, keep security data in disconnected tools, or maintain reporting in spreadsheets. It also suits teams that need a small internal tool and want it built on a secure foundation instead of a shared script on someone’s laptop.
Your engineers should solve problems, not repeat checklists
Manual change at scale produces drift: two zones that should match and do not, a rule that exists in one account only, an alert nobody configured. Each repeated task is a place where a typo reaches production. Automation fixes that only if it is itself controlled: reviewed, tested, permission-scoped, and easy to roll back. A script that nobody understands is another source of drift.
We build small, purposeful systems that connect platform APIs, policy, and operational knowledge, so the work becomes easier to verify and maintain.
What you get
01
A workflow assessment and a bounded plan. One repeated process with a measurable acceptance criterion, such as “every zone matches the baseline” or “a weekly report reaches the owners”, and a build scoped around it.
02
Terraform baselines. Existing configuration brought under Terraform, reviewed, and applied from one baseline across accounts, zones, or environments: on Cloudflare with cf-terraforming, and on AWS, Microsoft Azure, and Google Cloud with Terraform import blocks. The provider version is pinned, state is kept remotely, a plan is reviewed before every apply, and Git history is the rollback.
03
Python, serverless, and API integrations: scheduled jobs, controlled configuration rollout, notifications, and small internal services, built on Cloudflare Workers or your cloud’s serverless platform.
04
Reporting and alerting. Scripts collect configuration and analytics from platform APIs, for example zone settings, rulesets, DNS, and access configuration plus traffic and security analytics from Cloudflare’s GraphQL Analytics API. Templates render an HTML report for engineers and a workbook for the people who own remediation, and the same data can feed alerts.
05
Versioned configuration, deployment notes, and runbooks, with a handover session.
How it works
Architecture
Choose the process; define inputs, outputs, permissions, and failure behavior; and agree how success is measured.
Onboarding
Set up the repository, remote state, least-privilege API tokens, and review gates. Import the current configuration and review the generated output line by line.
Migration
Roll out in stages, one environment or zone class at a time, with a reviewed plan before each apply and a tested way back. Drift is detected by comparing the live account with the code.
Support
Add reports and alerts, document how the automation is operated, transfer ownership to your team, and review the automation after real use.
Limits
Commands, resource names, and provider behavior change between versions, so each deliverable records the versions it was checked against and the date. Automation is scoped to a process that can be verified, and a task that is cheaper to do by hand is left by hand. Secrets stay out of code. Terraform state can contain sensitive values, so it is stored remotely with access controls. Automation also needs a maintenance owner after handover; that role is named in the runbook, and alerts only help if someone receives them, so notification routes are part of the design.
Questions
How do you bring an existing Cloudflare account under Terraform?
Use cf-terraforming to generate Terraform configuration and import blocks from the live account, review the output, then apply one baseline across zones. Pin the provider version, keep state remote, require a reviewed plan before every apply, and treat Git as the rollback. The review matters: generated code reflects the account’s history, including its mistakes.
What can Workers automate?
API integrations, scheduled reporting, controlled configuration rollout, and small internal services close to the edge. A Worker is a good fit when the logic is small, event-driven, and tied to Cloudflare data or APIs. Each one is scoped to a measurable outcome before it is built, and how it is deployed and rolled back is documented.
How do you keep automation safe?
Least-privilege API tokens, no secrets in code, state stored remotely with access controls, a reviewed plan before every apply, and logs you can read. Anything that touches authentication gets an owner and a rollback step. Changes roll out in stages, so a mistake affects one environment or zone class, not the whole estate.
Can you automate reporting from Cloudflare analytics?
Yes. Scripts query the GraphQL Analytics API for status codes, cache hit ratio, and security events by rule, then render reports for engineers and for the owners of each fix. Scheduled runs after each migration wave catch regressions early, and the same data can feed alerts that reach a named person.
Do you also automate AWS, Azure, Google Cloud, and Akamai?
Yes. The same approach applies to any platform with an API: define the process, scope permissions narrowly, keep configuration in version control, and review changes before applying them. The platform’s tooling, rate limits, and quirks are confirmed during the assessment from its current documentation rather than assumed from another vendor.
Who owns the code and the documentation?
Ownership of code and documentation is set in the engagement agreement before work starts. In every case, repositories, runbooks, and deployment notes are handed over with a walkthrough. The handover is designed so your team can operate and change the automation without help, and ideally ends with your team making one real change from the documentation alone.