Cloudflare mitigated 23.2 million network-layer DDoS attacks in the first half of 2026. Nine hundred and thirty-five of those exceeded 1 Tbps. That is the environment every business website operates in now, whether the team behind it thinks about security or not.
When we rebuilt www.kondevs.com, the question was not "which hosting provider is cheapest." The question was: what architecture gives a small, focused enterprise consultancy the same edge performance, security posture, and operational simplicity that a large platform team would design — without the headcount or the budget?
The answer turned out to be Cloudflare's developer platform. Not because it is fashionable, but because the architecture enforces a clean separation of concerns that makes sense for sites that need to be fast, protected, and maintainable by a team that has other things to do.
The Architecture: Stateless Edge, Purpose-Built Storage
#Cloudflare Workers run JavaScript and TypeScript on Cloudflare's global network. Requests execute near the user, not in a data center chosen at contract-signing time. Workers use the V8 engine inside lightweight isolates rather than spinning up a full container per request. That reduces startup overhead compared to traditional serverless functions, though end-to-end latency still depends on downstream calls and storage operations. Nobody should promise fixed cold-start numbers here.
The critical design principle: Workers are stateless. In-memory variables don't persist between requests. A request might hit a different instance or location next time. This is a feature, not a limitation. It forces you to think about where state actually belongs.
Cloudflare answers that with purpose-built bindings. KV for globally distributed key-value reads (configuration, cached API responses). D1 for relational data with SQLite semantics, point-in-time recovery, and optional global read replication. R2 for object storage with an S3-compatible API. Durable Objects for the rare cases where you need a globally unique, single-threaded, stateful instance — coordinated counters, session locks, real-time collaboration.
The pattern Cloudflare's own documentation recommends: a stateless Worker handles auth, validation, and routing at the edge, then delegates state to the right service via bindings. For kondevs.com, that means the Worker handles request routing and headers, KV stores configuration and cached content, and R2 holds media assets. D1 sits behind structured content. No origin server to patch, scale, or worry about at 02:00.
Deployment: Git Push, Done
#Cloudflare Pages connects directly to a Git repository. Push to main, the site builds and deploys globally. Add a Worker for dynamic behavior - custom headers, redirects, authentication logic, A/B routing - and attach storage via bindings in the configuration file. The deployment model is familiar to any developer who has used CI/CD, except the target is a global edge network rather than a single region.
For a consultancy like kondevs, this matters operationally. The people maintaining the site are enterprise integration architects, not a dedicated DevOps team. The deployment pipeline needs to be simple enough that updating content or adjusting routing logic doesn't become a project of its own. Git-based deploy handles that.
Security You Don't Have to Build
#Here is where the architecture earns its keep for business sites. Cloudflare's H1 2026 DDoS report shows that about 90% of network-layer attacks ended within 10 minutes, and nearly 97% were under 500 Mbps. Short, frequent, automated. The kind of traffic that degrades performance and inflates bandwidth costs long before anyone notices a headline-worthy incident.
A case study from Tasrie IT Services documented what happened when a Saudi mobility platform configured Cloudflare's WAF rules, bot controls, rate limiting, and DDoS protections: automated traffic reaching the origin dropped from about 38% to under 3%. Origin bandwidth fell 62%. Median time-to-first-byte improved from 380 ms to 95 ms. Those numbers are implementation-dependent — your mileage will vary based on caching strategy, origin performance, and configuration choices. But the direction is consistent: edge filtering and caching reduce origin load and improve perceived speed.
For kondevs.com, this means WAF and bot controls are active by default. The site doesn't need a separate security appliance, a CDN contract, and a hosting provider. One platform handles request filtering, caching, and delivery.
Cost: Low, Not Zero
#The phrase "zero cost" deserves scrutiny. Cloudflare's free tier is generous for low-traffic sites and personal projects. Pages deploys are free. Workers have a free allocation. R2 has free egress. But Cloudflare has usage-based billing, and costs scale with requests, storage, and product usage. A business site with moderate traffic can run for very little. A high-traffic application with heavy D1 queries and large R2 storage will not be free.
The honest framing: Cloudflare's architecture lets you design for low cost by pushing work to the edge (cached reads, static assets, lightweight Workers) and reserving paid resources (D1 writes, Durable Objects, large R2 buckets) for what actually needs them. The cost model rewards good architecture. That is a different proposition from "free," and a more useful one.
What This Means for Enterprise Sites
#kondevs advises regulated enterprises on integration architecture - webMethods, Camunda, SEEBURGER, IBM Sterling, the full brownfield estate. The company's own site running on Cloudflare Workers is not a statement about replacing enterprise middleware. It is a practical demonstration of a principle we apply everywhere: separate concerns cleanly, push logic to the right layer, and make sure someone can explain the failure mode.
Workers at the edge handle routing. KV and R2 handle reads and assets. D1 handles structured data. WAF and bot controls handle threats before they reach application logic. Each component has a defined job, a defined owner, and observable behavior. That is the same thinking behind a well-governed integration layer in a regulated enterprise - just applied to a website.
The new kondevs.com is a small proof point for a larger conviction: architecture decisions that enforce clarity at the boundary level produce systems that are faster, cheaper to operate, and harder to break. Whether the boundary sits between a Worker and a KV namespace or between an API gateway and a backend process engine, the principle holds. Clean separation is not elegance for its own sake. It is operational insurance.