{"id":3704,"date":"2025-12-29T22:56:54","date_gmt":"2025-12-29T19:56:54","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/edge-logic-with-cloudflare-workers-and-bunnycdn-edge-rules\/"},"modified":"2025-12-29T22:56:54","modified_gmt":"2025-12-29T19:56:54","slug":"edge-logic-with-cloudflare-workers-and-bunnycdn-edge-rules","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/edge-logic-with-cloudflare-workers-and-bunnycdn-edge-rules\/","title":{"rendered":"Edge Logic with Cloudflare Workers and BunnyCDN Edge Rules"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>When we review client architectures at dchost.com, we still see a lot of logic living directly on the origin server: URL redirects in .htaccess, PHP scripts only used for simple rewrites, or whole frameworks bootstrapped just to set a few security headers. All of this work can be pushed much closer to your visitors. Cloudflare Workers and BunnyCDN Edge Rules let you run logic on edge nodes around the world, so decisions are made before the request even hits your <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> or <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>. The result is lower latency, less load on your origin, and a cleaner application stack.<\/p>\n<p>In this article we will focus on three practical edge use cases that you can start using today: URL rewrites and redirects, HTTP security headers, and offloading simple logic from the origin to the CDN. We will look at how Cloudflare Workers and BunnyCDN Edge Rules differ, how to choose the right one for each task, and how to design a strategy that fits a modern hosting setup on dchost.com infrastructure.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#What_Does_Running_Logic_at_the_Edge_Really_Mean\"><span class=\"toc_number toc_depth_1\">1<\/span> What Does Running Logic at the Edge Really Mean?<\/a><\/li><li><a href=\"#Cloudflare_Workers_vs_BunnyCDN_Edge_Rules_The_Mental_Model\"><span class=\"toc_number toc_depth_1\">2<\/span> Cloudflare Workers vs BunnyCDN Edge Rules: The Mental Model<\/a><ul><li><a href=\"#Cloudflare_Workers_in_Practice\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Cloudflare Workers in Practice<\/a><\/li><li><a href=\"#BunnyCDN_Edge_Rules_in_Practice\"><span class=\"toc_number toc_depth_2\">2.2<\/span> BunnyCDN Edge Rules in Practice<\/a><\/li><\/ul><\/li><li><a href=\"#URL_Rewrites_and_Redirects_at_the_Edge\"><span class=\"toc_number toc_depth_1\">3<\/span> URL Rewrites and Redirects at the Edge<\/a><ul><li><a href=\"#Common_Rewrite_and_Redirect_Scenarios\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Common Rewrite and Redirect Scenarios<\/a><\/li><li><a href=\"#URL_Rewrite_Example_with_Cloudflare_Workers\"><span class=\"toc_number toc_depth_2\">3.2<\/span> URL Rewrite Example with Cloudflare Workers<\/a><\/li><li><a href=\"#URL_Rewrite_Examples_with_BunnyCDN_Edge_Rules\"><span class=\"toc_number toc_depth_2\">3.3<\/span> URL Rewrite Examples with BunnyCDN Edge Rules<\/a><\/li><\/ul><\/li><li><a href=\"#Security_Headers_from_the_Edge_Instead_of_the_Origin\"><span class=\"toc_number toc_depth_1\">4<\/span> Security Headers from the Edge Instead of the Origin<\/a><ul><li><a href=\"#Which_Headers_Make_Sense_at_the_Edge\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Which Headers Make Sense at the Edge?<\/a><\/li><li><a href=\"#Setting_Security_Headers_with_a_Cloudflare_Worker\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Setting Security Headers with a Cloudflare Worker<\/a><\/li><li><a href=\"#Setting_Security_Headers_with_BunnyCDN_Edge_Rules\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Setting Security Headers with BunnyCDN Edge Rules<\/a><\/li><\/ul><\/li><li><a href=\"#Offloading_Simple_Logic_from_Your_Origin_Server\"><span class=\"toc_number toc_depth_1\">5<\/span> Offloading Simple Logic from Your Origin Server<\/a><ul><li><a href=\"#Edge-Friendly_Logic_Examples\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Edge-Friendly Logic Examples<\/a><\/li><li><a href=\"#Maintenance_Mode_with_Cloudflare_Workers\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Maintenance Mode with Cloudflare Workers<\/a><\/li><li><a href=\"#Geolocation-Based_Redirects_with_BunnyCDN_Edge_Rules\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Geolocation-Based Redirects with BunnyCDN Edge Rules<\/a><\/li><li><a href=\"#What_Should_Stay_on_the_Origin\"><span class=\"toc_number toc_depth_2\">5.4<\/span> What Should Stay on the Origin?<\/a><\/li><\/ul><\/li><li><a href=\"#Designing_an_Edge_Logic_Strategy_for_a_Site_Hosted_on_dchostcom\"><span class=\"toc_number toc_depth_1\">6<\/span> Designing an Edge Logic Strategy for a Site Hosted on dchost.com<\/a><ul><li><a href=\"#Step-by-Step_Rollout_Plan\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Step-by-Step Rollout Plan<\/a><\/li><\/ul><\/li><li><a href=\"#When_Not_to_Use_Edge_Logic_Pitfalls_and_Limits\"><span class=\"toc_number toc_depth_1\">7<\/span> When Not to Use Edge Logic: Pitfalls and Limits<\/a><\/li><li><a href=\"#Summary_Building_a_Clean_Edge_Layer_on_Top_of_dchostcom_Hosting\"><span class=\"toc_number toc_depth_1\">8<\/span> Summary: Building a Clean Edge Layer on Top of dchost.com Hosting<\/a><\/li><\/ul><\/div>\n<h2><span id=\"What_Does_Running_Logic_at_the_Edge_Really_Mean\">What Does Running Logic at the Edge Really Mean?<\/span><\/h2>\n<p>&#8220;The edge&#8221; simply means servers that are geographically close to your visitors. A CDN like Cloudflare or BunnyCDN operates many PoPs (points of presence) worldwide. Traditionally, these PoPs only cached and served static files. Today, they can also <strong>execute logic<\/strong> before forwarding a request to your origin or before sending a response back to the browser.<\/p>\n<p>Instead of asking your PHP application or Nginx\/Apache to handle every redirect, header, or micro-decision, you can move that logic to the CDN. The benefits are clear:<\/p>\n<ul>\n<li><strong>Lower latency:<\/strong> Redirects and rewrites complete at the nearest edge node, not on a distant origin.<\/li>\n<li><strong>Less origin load:<\/strong> Fewer hits reach your VPS or dedicated server, which means more capacity for real application work.<\/li>\n<li><strong>Simpler application code:<\/strong> Old rewrite rules and small glue scripts disappear from the codebase.<\/li>\n<li><strong>Central control:<\/strong> Rules live in one edge layer instead of being duplicated across multiple app servers.<\/li>\n<\/ul>\n<p>If you are already using a CDN for caching, edge logic is the natural next step. It sits nicely beside the kind of caching strategies we discuss in our <a href=\"https:\/\/www.dchost.com\/blog\/en\/cdn-onbellekleme-cache-control-ve-edge-kurallari-wordpress-ve-woocommercede-tam-isabet-ayarlar\/\">CDN caching playbook for WordPress and WooCommerce<\/a>, but works even for fully dynamic applications.<\/p>\n<h2><span id=\"Cloudflare_Workers_vs_BunnyCDN_Edge_Rules_The_Mental_Model\">Cloudflare Workers vs BunnyCDN Edge Rules: The Mental Model<\/span><\/h2>\n<p>Cloudflare Workers and BunnyCDN Edge Rules both live at the edge, but they occupy different layers of complexity.<\/p>\n<ul>\n<li><strong>Cloudflare Workers:<\/strong> A programmable JavaScript runtime that can inspect, modify, or generate requests and responses. Think of it as a tiny, globally distributed serverless function.<\/li>\n<li><strong>BunnyCDN Edge Rules:<\/strong> A rule engine with conditions (URL, country, header, etc.) and actions (redirect, rewrite, set header, cache control). Think of it as a powerful GUI for common policies.<\/li>\n<\/ul>\n<h3><span id=\"Cloudflare_Workers_in_Practice\">Cloudflare Workers in Practice<\/span><\/h3>\n<p>Workers are event-driven scripts that handle HTTP requests. A minimal Worker looks like this:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">addEventListener(&quot;fetch&quot;, event =&gt; {\n  event.respondWith(handleRequest(event.request));\n});\n\nasync function handleRequest(request) {\n  const url = new URL(request.url);\n\n  \/\/ Simple rewrite example\n  if (url.pathname.startsWith(&quot;\/blog&quot;)) {\n    url.pathname = url.pathname.replace(&quot;\/blog&quot;, &quot;\/articles&quot;);\n    return fetch(url.toString(), request);\n  }\n\n  \/\/ Pass through if no special handling\n  return fetch(request);\n}\n<\/code><\/pre>\n<p>With this model, you can:<\/p>\n<ul>\n<li>Rewrite URLs or route requests based on cookies, headers, or geo-IP.<\/li>\n<li>Generate responses entirely at the edge (for example, a maintenance page).<\/li>\n<li>Inject or modify headers on both the request and response.<\/li>\n<li>Implement lightweight authentication or feature flags without touching your origin.<\/li>\n<\/ul>\n<h3><span id=\"BunnyCDN_Edge_Rules_in_Practice\">BunnyCDN Edge Rules in Practice<\/span><\/h3>\n<p>BunnyCDN Edge Rules are configured in the dashboard. Instead of code, you define conditions and actions through a UI. Some typical conditions:<\/p>\n<ul>\n<li>URL path matches <code>\/blog\/*<\/code><\/li>\n<li>Country is not one of [US, DE, TR]<\/li>\n<li>HTTP header <code>User-Agent<\/code> contains <code>bot<\/code><\/li>\n<li>File extension is one of <code>.jpg, .png, .webp<\/code><\/li>\n<\/ul>\n<p>And actions might include:<\/p>\n<ul>\n<li>Redirect (301\/302) to another URL.<\/li>\n<li>Rewrite the URL path without changing what the browser sees.<\/li>\n<li>Add, override, or remove HTTP headers.<\/li>\n<li>Force HTTPS, change caching behaviour, or deny access.<\/li>\n<\/ul>\n<p>Edge Rules are ideal for teams who want strong control but prefer configuration over code. For advanced behaviour (custom logic, third-party APIs, complex routing), you step up to Cloudflare Workers.<\/p>\n<h2><span id=\"URL_Rewrites_and_Redirects_at_the_Edge\">URL Rewrites and Redirects at the Edge<\/span><\/h2>\n<p>Let us start with the most common and impactful use case: URL rewrites and redirects. These usually live in .htaccess, Nginx config, or even in application routes. Moving them to the edge gives you instant responses and keeps your origin config cleaner.<\/p>\n<h3><span id=\"Common_Rewrite_and_Redirect_Scenarios\">Common Rewrite and Redirect Scenarios<\/span><\/h3>\n<ul>\n<li><strong>HTTP to HTTPS:<\/strong> Force all visitors to use secure URLs.<\/li>\n<li><strong>www to non-www (or the opposite):<\/strong> Canonicalize hosts for SEO and simplicity.<\/li>\n<li><strong>Legacy URL migrations:<\/strong> Redirect <code>\/old-blog\/post-name<\/code> to <code>\/blog\/post-name<\/code> after a site restructure.<\/li>\n<li><strong>Language-specific paths:<\/strong> Redirect visitors from certain countries to <code>\/en\/<\/code>, <code>\/de\/<\/code>, or <code>\/tr\/<\/code> paths.<\/li>\n<li><strong>Clean URLs for SPAs:<\/strong> Rewrite <code>\/app\/*<\/code> to <code>\/app\/index.html<\/code> while keeping the original path in the browser.<\/li>\n<\/ul>\n<p>These are the kinds of rules that can sit entirely at the edge. Your origin only serves the final target URL.<\/p>\n<h3><span id=\"URL_Rewrite_Example_with_Cloudflare_Workers\">URL Rewrite Example with Cloudflare Workers<\/span><\/h3>\n<p>Here is a Worker that handles three common tasks: HTTPS enforcement, &#8220;www&#8221; canonicalization, and a legacy blog path migration.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">addEventListener(&quot;fetch&quot;, event =&gt; {\n  event.respondWith(handleRequest(event.request));\n});\n\nasync function handleRequest(request) {\n  const url = new URL(request.url);\n\n  \/\/ 1) Force HTTPS\n  if (url.protocol === &quot;http:&quot;) {\n    url.protocol = &quot;https:&quot;;\n    return Response.redirect(url.toString(), 301);\n  }\n\n  \/\/ 2) Force non-www\n  if (url.hostname.startsWith(&quot;www.&quot;)) {\n    url.hostname = url.hostname.replace(\/^www.\/, &quot;&quot;);\n    return Response.redirect(url.toString(), 301);\n  }\n\n  \/\/ 3) Legacy blog URLs: \/old-blog\/&gt; \/blog\/\n  if (url.pathname.startsWith(&quot;\/old-blog\/&quot;)) {\n    url.pathname = url.pathname.replace(&quot;\/old-blog\/&quot;, &quot;\/blog\/&quot;);\n    return Response.redirect(url.toString(), 301);\n  }\n\n  \/\/ Otherwise, just pass to origin\n  return fetch(request);\n}\n<\/code><\/pre>\n<p>Notice that the origin server does not know any of these rules exist. It receives only the final URL. That makes migrations (for example, moving from one CMS to another) easier, because the redirect logic is decoupled from the app itself.<\/p>\n<h3><span id=\"URL_Rewrite_Examples_with_BunnyCDN_Edge_Rules\">URL Rewrite Examples with BunnyCDN Edge Rules<\/span><\/h3>\n<p>With BunnyCDN Edge Rules you would configure similar behaviour in the dashboard:<\/p>\n<ol>\n<li><strong>Force HTTPS:<\/strong>\n<ul>\n<li>Condition: Protocol is HTTP.<\/li>\n<li>Action: Redirect to HTTPS (status 301).<\/li>\n<\/ul>\n<\/li>\n<li><strong>Legacy blog migration:<\/strong>\n<ul>\n<li>Condition: URL path begins with <code>\/old-blog\/<\/code>.<\/li>\n<li>Action: Redirect to <code>https:\/\/example.com\/blog\/$1<\/code> (using a path capture if needed).<\/li>\n<\/ul>\n<\/li>\n<li><strong>SPA index rewrite:<\/strong>\n<ul>\n<li>Condition: URL path begins with <code>\/app\/<\/code> and file extension is empty.<\/li>\n<li>Action: Rewrite path to <code>\/app\/index.html<\/code> while keeping the browser URL unchanged.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p>For teams that frequently adjust redirects (SEO work, marketing campaigns, language rollouts), having these rules in a single CDN layer is much nicer than juggling Nginx snippets and .htaccess fragments on every origin.<\/p>\n<h2><span id=\"Security_Headers_from_the_Edge_Instead_of_the_Origin\">Security Headers from the Edge Instead of the Origin<\/span><\/h2>\n<p>Another perfect match for edge logic is HTTP security headers. Things like HSTS, CSP, X-Frame-Options, and Referrer-Policy are sent with every response, so it is wasteful to generate them with application code. The edge can attach them after the origin responds, or even for fully cached content without hitting the origin at all.<\/p>\n<p>If you want a deep dive into what each header does, our <a href=\"https:\/\/www.dchost.com\/blog\/en\/http-guvenlik-basliklari-rehberi-hsts-csp-x-frame-options-ve-referrer-policy-dogru-nasil-kurulur\/\">HTTP security headers guide (HSTS, CSP, X-Frame-Options and Referrer-Policy)<\/a> covers the concepts in detail. Here, we will focus on how to push them to the edge.<\/p>\n<h3><span id=\"Which_Headers_Make_Sense_at_the_Edge\">Which Headers Make Sense at the Edge?<\/span><\/h3>\n<p>Most purely declarative headers are excellent candidates for edge injection:<\/p>\n<ul>\n<li><strong>Strict-Transport-Security<\/strong> (HSTS)<\/li>\n<li><strong>Content-Security-Policy<\/strong> (CSP) \u2013 for many static patterns<\/li>\n<li><strong>X-Frame-Options<\/strong><\/li>\n<li><strong>X-Content-Type-Options<\/strong><\/li>\n<li><strong>Referrer-Policy<\/strong><\/li>\n<li><strong>Permissions-Policy<\/strong><\/li>\n<\/ul>\n<p>Headers that depend on business logic (for example, different CSP for admin vs public pages, or signed cookies) might still live in the application. But you can often cover 80\u201390% of cases at the edge and only override selectively from the origin if needed.<\/p>\n<h3><span id=\"Setting_Security_Headers_with_a_Cloudflare_Worker\">Setting Security Headers with a Cloudflare Worker<\/span><\/h3>\n<p>Here is a Worker that wraps the origin response and attaches a standard set of security headers:<\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\">addEventListener(&quot;fetch&quot;, event =&gt; {\n  event.respondWith(handleRequest(event.request));\n});\n\nasync function handleRequest(request) {\n  const response = await fetch(request);\n  const newHeaders = new Headers(response.headers);\n\n  newHeaders.set(&quot;Strict-Transport-Security&quot;, &quot;max-age=31536000; includeSubDomains; preload&quot;);\n  newHeaders.set(&quot;X-Frame-Options&quot;, &quot;SAMEORIGIN&quot;);\n  newHeaders.set(&quot;X-Content-Type-Options&quot;, &quot;nosniff&quot;);\n  newHeaders.set(&quot;Referrer-Policy&quot;, &quot;strict-origin-when-cross-origin&quot;);\n  newHeaders.set(&quot;Permissions-Policy&quot;, &quot;geolocation=()&quot;,);\n\n  \/\/ Example CSP - adapt carefully to your site\n  newHeaders.set(&quot;Content-Security-Policy&quot;, &quot;default-src 'self'; img-src 'self' https: data:; script-src 'self' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline' https:&quot;);\n\n  return new Response(response.body, {\n    status: response.status,\n    statusText: response.statusText,\n    headers: newHeaders\n  });\n}\n<\/code><\/pre>\n<p>This Worker does not change the body or status code; it simply strengthens your responses with a consistent header set. You can even apply stricter policies on certain paths, for example a hardened CSP on <code>\/admin<\/code> and a more permissive one on legacy sections.<\/p>\n<p>If you are also using Cloudflare\u2019s security features, you can combine this with WAF and bot protection as described in our <a href=\"https:\/\/www.dchost.com\/blog\/en\/cloudflare-guvenlik-ayarlari-rehberi-kucuk-isletme-siteleri-icin-waf-rate-limit-ve-bot-korumasi\/\">Cloudflare security settings guide for WAF, rate limiting and bots<\/a>. The Worker handles headers, while the WAF blocks malicious traffic before it reaches your application.<\/p>\n<h3><span id=\"Setting_Security_Headers_with_BunnyCDN_Edge_Rules\">Setting Security Headers with BunnyCDN Edge Rules<\/span><\/h3>\n<p>BunnyCDN Edge Rules make header injection even simpler for straightforward setups. A common pattern:<\/p>\n<ol>\n<li>Create an Edge Rule with no path condition (apply to all URLs), or a restricted path if you prefer.<\/li>\n<li>Choose the action &#8220;Add Response Header&#8221; or &#8220;Set Response Header&#8221;.<\/li>\n<li>Define headers like:\n<ul>\n<li><code>Strict-Transport-Security: max-age=31536000; includeSubDomains; preload<\/code><\/li>\n<li><code>X-Frame-Options: SAMEORIGIN<\/code><\/li>\n<li><code>X-Content-Type-Options: nosniff<\/code><\/li>\n<li><code>Referrer-Policy: strict-origin-when-cross-origin<\/code><\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p>For CSP and Permissions-Policy you can separate them into their own rules, or keep them at the origin if you need deeper application awareness. The key benefit is that static assets and cached HTML now carry the correct headers automatically, without consuming any CPU cycles on your origin server.<\/p>\n<h2><span id=\"Offloading_Simple_Logic_from_Your_Origin_Server\">Offloading Simple Logic from Your Origin Server<\/span><\/h2>\n<p>Beyond rewrites and headers, there is a wide range of &#8220;small but useful&#8221; logic that fits naturally at the edge. Moving this code away from the origin helps you keep your VPS or dedicated server focused on running the main application and database.<\/p>\n<h3><span id=\"Edge-Friendly_Logic_Examples\">Edge-Friendly Logic Examples<\/span><\/h3>\n<ul>\n<li><strong>Maintenance pages:<\/strong> Serve a static &#8220;We will be back soon&#8221; page entirely from the edge while you work on the origin.<\/li>\n<li><strong>Geolocation-based routing:<\/strong> Route users from certain regions to \/eu\/ or \/us\/ versions, or to region-specific backends.<\/li>\n<li><strong>Simple A\/B testing:<\/strong> Randomly send a fraction of visitors to \/variant-b\/ and label them with a cookie, without extra load on your app.<\/li>\n<li><strong>Static API responses:<\/strong> For configuration endpoints that rarely change, respond directly from a Worker instead of hitting PHP\/Node.js.<\/li>\n<li><strong>Referrer-based blocking:<\/strong> Deny or challenge suspicious referral patterns before they reach the origin.<\/li>\n<\/ul>\n<p>On Cloudflare, these are typically implemented with Workers. On BunnyCDN, some of them can be covered with Edge Rules (for example, simple country-based blocking or redirects), while others would need to remain at the origin.<\/p>\n<h3><span id=\"Maintenance_Mode_with_Cloudflare_Workers\">Maintenance Mode with Cloudflare Workers<\/span><\/h3>\n<p>A very practical pattern we use during deployments is a temporary maintenance page served at the edge:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">const MAINTENANCE = false; \/\/ flip to true during deployment\n\naddEventListener(&quot;fetch&quot;, event =&gt; {\n  event.respondWith(handleRequest(event.request));\n});\n\nasync function handleRequest(request) {\n  if (MAINTENANCE) {\n    return new Response(&quot;&lt;h1&gt;We&amp;apos;ll be back soon&lt;\/h1&gt;&quot;, {\n      status: 503,\n      headers: {\n        &quot;Content-Type&quot;: &quot;text\/html; charset=utf-8&quot;,\n        &quot;Retry-After&quot;: &quot;300&quot;\n      }\n    });\n  }\n\n  return fetch(request);\n}\n<\/code><\/pre>\n<p>Switch one flag and the entire site is in maintenance mode from the edge, while you safely deploy changes on your dchost.com VPS or dedicated server. Because it is served by the CDN, your origin can even be temporarily offline during some parts of the maintenance window.<\/p>\n<h3><span id=\"Geolocation-Based_Redirects_with_BunnyCDN_Edge_Rules\">Geolocation-Based Redirects with BunnyCDN Edge Rules<\/span><\/h3>\n<p>BunnyCDN exposes the visitor\u2019s country to Edge Rules, so you can configure simple geolocation logic without code. For example:<\/p>\n<ul>\n<li>Condition: Country is in [DE, AT, CH].<\/li>\n<li>Action: Redirect to <code>https:\/\/example.com\/de$path<\/code> with status 302.<\/li>\n<\/ul>\n<p>Or you might block traffic from certain regions from accessing an admin path:<\/p>\n<ul>\n<li>Condition: URL path begins with <code>\/admin<\/code> AND country is not in your approved list.<\/li>\n<li>Action: Return 403 Forbidden.<\/li>\n<\/ul>\n<p>For more complex geolocation logic (combining country with cookies, AB tests, or feature flags), you would typically move up to Cloudflare Workers, where you can implement arbitrary JavaScript logic.<\/p>\n<h3><span id=\"What_Should_Stay_on_the_Origin\">What Should Stay on the Origin?<\/span><\/h3>\n<p>Not everything belongs at the edge. In general, keep the following on your origin:<\/p>\n<ul>\n<li><strong>Anything that needs your database:<\/strong> Cart logic, user accounts, permissions, search, reporting.<\/li>\n<li><strong>Heavy computation:<\/strong> Image processing, video encoding, large PDF generation.<\/li>\n<li><strong>Complex business rules:<\/strong> Pricing, discounts, licensing checks, internal APIs between microservices.<\/li>\n<\/ul>\n<p>The edge is best for fast, stateless, request\/response adjustments. While Cloudflare Workers can make external API calls and even maintain durable state, that is usually a later stage of maturity. Start by extracting clearly isolated logic (rewrites, headers, simple blocks) and scale from there.<\/p>\n<h2><span id=\"Designing_an_Edge_Logic_Strategy_for_a_Site_Hosted_on_dchostcom\">Designing an Edge Logic Strategy for a Site Hosted on dchost.com<\/span><\/h2>\n<p>When clients host their origin on a dchost.com VPS, dedicated server or colocated machine, we often propose a layered architecture:<\/p>\n<ul>\n<li><strong>Layer 1 \u2013 DNS and CDN:<\/strong> Cloudflare or BunnyCDN in front, handling TLS termination, caching, and edge logic.<\/li>\n<li><strong>Layer 2 \u2013 Origin web stack:<\/strong> Nginx or Apache, PHP-FPM or Node.js, running on a tuned VPS or dedicated server.<\/li>\n<li><strong>Layer 3 \u2013 Data and background jobs:<\/strong> MariaDB\/MySQL\/PostgreSQL, Redis, and background workers.<\/li>\n<\/ul>\n<p>This aligns well with other patterns we describe, such as building a <a href=\"https:\/\/www.dchost.com\/blog\/en\/cdn-onbellekleme-cache-control-ve-edge-kurallari-wordpress-ve-woocommercede-tam-isabet-ayarlar\/\">robust CDN caching and edge rules strategy<\/a> or using <a href=\"https:\/\/www.dchost.com\/blog\/en\/geodns-ve-cok-bolgeli-hosting-mimarisi-ile-global-ziyaretcilere-yakinlasmak\/\">GeoDNS and multi-region hosting architectures for low latency<\/a>. Edge logic simply becomes part of the first layer.<\/p>\n<h3><span id=\"Step-by-Step_Rollout_Plan\">Step-by-Step Rollout Plan<\/span><\/h3>\n<ol>\n<li><strong>Inventory existing logic:<\/strong>\n<ul>\n<li>Collect redirects from .htaccess, Nginx configs, and application code.<\/li>\n<li>List all security headers currently sent by your app or server.<\/li>\n<li>Identify small PHP or Node.js scripts that mostly do &#8220;glue&#8221; work.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Classify what can move to the edge:<\/strong>\n<ul>\n<li>Redirects and host\/HTTPS canonicalization \u2013 edge-friendly.<\/li>\n<li>Static security headers \u2013 great at the edge.<\/li>\n<li>Small utility endpoints that rarely change \u2013 possible Worker candidates.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Decide on the tool per task:<\/strong>\n<ul>\n<li>Use BunnyCDN Edge Rules for straightforward redirects, header injection and access control.<\/li>\n<li>Use Cloudflare Workers when you need real logic, conditions or external calls.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Roll out gradually:<\/strong>\n<ul>\n<li>Start with non-critical paths (for example, old URL redirects).<\/li>\n<li>Monitor logs and error rates at the origin to ensure nothing breaks.<\/li>\n<li>Once stable, remove the equivalent rules from your origin configs.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Document and version control:<\/strong>\n<ul>\n<li>Keep Worker scripts in Git alongside your application.<\/li>\n<li>Export or document BunnyCDN Edge Rules so they can be recreated if needed.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p>As you clean up origin configs, you will also find that migrations become easier. When you move a site from shared hosting to a VPS (or between VPS plans at dchost.com), most of the URL and header behaviour stays at the edge, untouched by the change underneath.<\/p>\n<h2><span id=\"When_Not_to_Use_Edge_Logic_Pitfalls_and_Limits\">When Not to Use Edge Logic: Pitfalls and Limits<\/span><\/h2>\n<p>Edge logic is powerful, but there are some pitfalls to avoid:<\/p>\n<ul>\n<li><strong>Debugging complexity:<\/strong> If you split related logic between the origin and edge without clear boundaries, debugging becomes harder. Keep responsibilities well-defined.<\/li>\n<li><strong>Caching interactions:<\/strong> A Worker that dynamically changes responses needs to be aware of cache headers. Misconfigured cache rules can lead to stale or mixed content. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/tarayici-ve-cdn-onbellekleme-neden-bu-kadar-kritik\/\">HTTP Cache-Control, ETag and CDN rules for faster sites<\/a> is a helpful companion here.<\/li>\n<li><strong>Vendor lock-in:<\/strong> Deeply custom Workers (or very specific Edge Rules) can make future CDN changes more involved. Keep scripts modular and documented.<\/li>\n<li><strong>Security assumptions:<\/strong> Edge logic does not replace a WAF or proper origin hardening. Combine it with firewall rules and WAF policies as we describe in our <a href=\"https:\/\/www.dchost.com\/blog\/en\/waf-ve-bot-korumasi-cloudflare-modsecurity-ve-fail2bani-ayni-masada-baristirmanin-sicacik-hikayesi\/\">guide to WAF and bot protection with Cloudflare, ModSecurity and Fail2ban<\/a>.<\/li>\n<li><strong>Stateful logic:<\/strong> Anything that needs strong consistency across requests (transactions, user balances, etc.) should remain in your application and database, not in an edge script.<\/li>\n<\/ul>\n<p>If you are unsure whether a piece of logic belongs at the edge or origin, a good rule of thumb is: if it can be expressed purely as &#8220;if this request looks like X, then transform or block it&#8221;, it is a strong candidate for the edge. If it needs internal data or complex rules, keep it in your main stack.<\/p>\n<h2><span id=\"Summary_Building_a_Clean_Edge_Layer_on_Top_of_dchostcom_Hosting\">Summary: Building a Clean Edge Layer on Top of dchost.com Hosting<\/span><\/h2>\n<p>Moving logic to the edge is one of the simplest ways to make your hosting stack both faster and cleaner. Cloudflare Workers give you a programmable runtime for complex routing, rewrites and small services, while BunnyCDN Edge Rules cover a large percentage of real-world needs through a straightforward rule engine. Together, they can handle URL rewrites, redirects, HTTP security headers and a surprising amount of everyday glue logic before any request reaches your origin.<\/p>\n<p>On the origin side, a well-tuned dchost.com VPS, dedicated server or colocated machine can then focus on what it does best: running your PHP, Node.js, or other application code and serving the database. You cut down TTFB, free up CPU for real work, and make future migrations less painful because so much behaviour is standardized at the edge layer.<\/p>\n<p>If you want help designing this stack, our team at dchost.com works with Cloudflare and BunnyCDN setups daily. We can review your current redirects, security headers and application glue code, then propose a concrete plan to move the right pieces to the edge while keeping your core app safe and maintainable. Combine that with the right hosting plan on our infrastructure, and you get a modern, resilient architecture that feels faster to every visitor, everywhere in the world.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>When we review client architectures at dchost.com, we still see a lot of logic living directly on the origin server: URL redirects in .htaccess, PHP scripts only used for simple rewrites, or whole frameworks bootstrapped just to set a few security headers. All of this work can be pushed much closer to your visitors. Cloudflare [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3705,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3704","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3704","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3704"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3704\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3705"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3704"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3704"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3704"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}