Marcin Żelasko

Turned a manual, per-API Cloudflare setup into one step in every team's deploy pipeline.

Problem

Dozens of backend APIs sat behind Cloudflare, but only a handful had schema validation, each uploaded by hand: the OpenAPI file, every endpoint, the action for invalid requests. It did not scale, it went stale as soon as an API changed, and an outdated schema risked blocking legitimate traffic to new endpoints.

Approach

I built a small Python tool that product teams call from their own CircleCI pipelines, passing in the OpenAPI file they already maintain. Before a deploy, it switches the service to log-only, so routes that are about to change are not blocked mid-rollout. After the deploy, it replaces the schema for that service and environment, registers every operation with endpoint management and turns enforcement back on. API calls retry on transient errors and page through every operation, so a large API or a flaky response does not leave it half-configured.

Result

About 80 APIs onboarded without teams touching the Cloudflare dashboard. Every deploy keeps the schema in step with the code that is actually running, removed endpoints drop out on their own, and enforcement only tightens once the new version is live. Schema validation now regularly stops invalid requests at the edge, before they reach the services.

Every pull request got its own running copy of the whole application, so developers could see a change working with all the other services before merging it.

Problem

The application was 10+ microservices on ECS, talking to each other and to a database, with two environments: beta and prod. Developers wanted to see their change running before a pull request was merged, but the first place a change could run alongside every other service was beta, after the merge.

Approach

Opening a pull request on GitHub started a pipeline in AWS CodePipeline, with CodeBuild and Terraform, that created a dedicated ECS cluster named after the service and the PR number. Every other service was deployed at its latest beta version, next to the pull request's version of the changed one, and all of them used the beta database, so there was nothing to copy or seed. Once every service was healthy, the pipeline posted the address as a comment on the pull request. Merging the pull request removed the environment.

Result

Developers used it all the time: any pull request could be tried in a complete copy of the application before review, from a link right on the pull request, and environments cleaned up after themselves. The trade-off was start-up time. The services were big, and the link only went out once every one of them was healthy, so a preview took a while to come up.

Shared Cloudflare DNS tokens that had never been rotated now get a new value every week, without any team changing its pipelines.

Problem

Infrastructure pipelines in many AWS accounts create DNS records in Cloudflare through Terraform and CloudFormation. They shared seven Cloudflare API tokens, already handed out through Secrets Manager, but the tokens never changed: a leaked one would keep working indefinitely. Any rotation had to happen without asking each team to update anything.

Approach

A Python Lambda, started weekly for each token by EventBridge, rolls the token through the Cloudflare API with a separate management token and publishes the new value as the current version of its secret. Terraform defines the rest: the token-to-secret mapping, the schedules, secret and key policies for cross-account reads, customer managed KMS keys and replicas in a second region. Every run reports to Slack, and GitHub Actions deploys the Lambda through OIDC, with no long-lived AWS keys. Pipelines already fetched the secret on every run and kept no copy between runs, so rotation could live in one place.

Result

Seven tokens that had never been rotated now rotate weekly, readable from 49 AWS accounts, with three of them replicated to a second region. No team changed a thing: the next pipeline run simply picks up the new value. Replication taught me the most. Reading a secret, decrypting it and replicating it are separate permissions, and a replica is encrypted with a key in its own region. The fix was giving the rotation role both regional keys and adding data-key generation to the shared key policy.

This site runs the way I run production: everything as code, reviewed before it ships, locked down by default.

Problem

A portfolio is a small static page, but it is also a public sample of how I work. Set up the usual way, its DNS, redirects and email would be clicked together in dashboards, deploys would skip review, and security headers would be an afterthought.

Approach

Terraform manages DNS, the custom domain, the www redirect, email routing and TLS settings, with state in Cloudflare R2. The page is prerendered and served by Cloudflare Workers, only on its own domain. Every pull request runs the tests, the build, a Wrangler dry run and a Terraform plan posted as a comment; merging deploys, applies and smoke-tests production. A strict Content Security Policy allows the one inline script by its hash.

Result

A change is live about a minute after merging, checked by a smoke test against production. Lighthouse scores 98 to 100 across performance, accessibility, best practices and SEO. The headers below are the real ones, read from the same file Cloudflare serves.

$ curl -sI https://marcinzelasko.comcontent-security-policy: default-src 'self';script-src 'self' 'sha256-flGvizFYDdITDPWeoYbtMujI0araP3UO5e7/nYLzc2I=' https://static.cloudflareinsights.com;style-src 'self';font-src 'self';img-src 'self' data:;connect-src 'self' https://cloudflareinsights.com;frame-ancestors 'none';base-uri 'self';form-action 'none'strict-transport-security: max-age=63072000;includeSubDomains;preloadx-content-type-options: nosniffreferrer-policy: strict-origin-when-cross-originpermissions-policy: camera=(), microphone=(), geolocation=()