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.
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 are not guaranteed to 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, the platform is Cloudflare Pages: the site's Pages Functions are bundled into one Worker, which renders every page at the edge and handles routing and headers. KV stores every article and the indexes the listings read, and R2 holds the images of the articles published through the site's API (the few articles kept in the repository ship their images with the site). Since October 2026 the site is bilingual: German pages live under /de/, German articles under their own KV keys. The site uses no D1 and no Durable Objects: a content site of this size needs neither. No origin server to patch, scale, or worry about at 02:00.
One detail matters for both caching and cost. The site's middleware runs on every page, feed and machine-readable file, so one piece of code sets the security headers, the redirects and the machine-readable Link headers on every answer. The CSS, JavaScript, images, fonts and icons skip it: a _routes.json file sends them straight to Cloudflare's static asset server, so they invoke no Functions. HTML pages are rendered on each request and carry an ETag, so a returning browser gets a short 304 answer instead of the whole page. The RSS and JSON feeds and llms-full.txt are kept in Cloudflare's edge cache, and the CSS and JavaScript carry a content hash in their address, so browsers keep them for a year.
Cloudflare Pages can build a site on every push to a Git repository. KONDEVS switched that off on purpose: every release is built from the repository, deployed first to a preview address and checked there, then deployed to production with one Wrangler command and checked again on the live site. Pages Functions (Workers) add the dynamic behaviour (server-side rendering, custom headers, redirects, the publishing API) and attach storage through 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, and deliberate enough that nothing reaches production by accident. One build, a preview, one production deploy command and a live check handle that.
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 published by 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 Cloudflare's network absorbs network-layer DDoS attacks before they reach the site. HTTP requests that pass its filters run the site's own code, which adds the rest: strict security headers (CSP, HSTS) on every response, rate limits on its APIs and sanitisation of every published article. AI crawlers and agents are allowed on purpose, because the site is built to be read by them. The site doesn't need a separate security appliance, a CDN contract, and a hosting provider. One platform handles request filtering, caching, and delivery.
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.
kondevs.com shows the trade-off. Every page view runs the site's middleware and counts as a Workers request. Static files are different: Cloudflare serves them free and without limit as long as they invoke no Functions, so the site routes its CSS, JavaScript, images, fonts and icons around the Functions with a _routes.json file. Until October 2026 they passed the middleware too, and every one of them counted as a request. A site with much more traffic would also keep more of its pages in the edge cache.
KONDEVS advises regulated enterprises on integration architecture: webMethods, Camunda, SEEBURGER, IBM Sterling, the full brownfield estate. The company's own site running on Cloudflare Pages and 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.
Pages Functions on the Workers runtime handle rendering and routing. KV holds the content, R2 the images. Cloudflare's network absorbs network-layer attacks before they reach application logic, and the code enforces its own headers and limits. 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.
