{"id":23203,"date":"2026-06-16T10:58:18","date_gmt":"2026-06-16T08:58:18","guid":{"rendered":"https:\/\/www.transparentedge.eu\/en\/blog\/"},"modified":"2026-06-16T10:58:19","modified_gmt":"2026-06-16T08:58:19","slug":"multi-origin-without-modifying-dns","status":"publish","type":"post","link":"https:\/\/www.transparentedge.eu\/en\/blog\/multi-origin-without-modifying-dns\/","title":{"rendered":"Multi-origin without modifying DNS"},"content":{"rendered":"\n

Deploy a new version without any downtime. Migrate services gradually. Test in production with a real subset of users. All of this can be done from the CDN, without modifying the DNS, without waiting for TTL propagation, and without the stress of coordinating emergency plans between teams.<\/p>\n\n\n\n

Transparent Edge’s multi-origin configuration allows you to assign different backends based on any element of the HTTP request: the URL, a cookie, a header. The VCL enables highly precise routing rule tuning, deploys in seconds, and can be rolled back just as quickly.<\/p>\n\n\n\n

What is multi-origin and how does it work<\/h2>\n\n\n\n

In a standard configuration, a domain points to a single backend. In multi-origin, the CDN decides which backend to send each request to before it reaches the origin. This decision can depend on any visible element in the request: the route, a content negotiation header, a session cookie, the user’s country, the client version, and more.<\/p>\n\n\n\n

The mechanism is straightforward: in ‘vcl_recv<\/code>‘, ‘req.backend_hint<\/code>‘ is set with the target backend. The necessary backends are declared in the dashboard and referenced from the VCL.<\/p>\n\n\n\n

sub vcl_recv {\n  # Default backend\n  set req.backend_hint = c83_monolito.backend();\n\n  # The blog points to a different server.\n  if (req.url ~ \"^\/blog\") {\n    set req.backend_hint = c83_blog.backend();\n  }\n}\n<\/code><\/pre>\n\n\n\n
The request reaches the CDN, the VCL evaluates it and forwards it to the correct backend. DNS is not involved in this process. The change is applied in seconds.
<\/p>\n\n\n\n
Migrate the monolith route by route via URL<\/h2>\n\n\n\n
The most common scenario in architectures undergoing transition is as follows: there’s a monolith managing everything, and a team is gradually extracting services. The new microservice is ready, but production validation requires real traffic. With a DNS change, that’s risky; with multi-origin architecture, it’s safe.<\/p>\n\n\n\n
The new service is configured as a backend in Transparent Edge and routed to it using a URL prefix:<\/p>\n\n\n\n
sub vcl_recv {\n  set req.backend_hint = c83_monolito.backend();\n\n  # The order API routes go to the new microservice\n  if (req.url ~ \"^\/api\/orders\") {\n    set req.backend_hint = c83_orders_service.backend();\n  }\n}\n<\/code><\/pre>\n\n\n\n
The user doesn’t notice anything. The DNS doesn’t change. If something goes wrong, reverting the VCL takes minutes. The monolith continues to handle the rest of the process while the team works in parallel.<\/p>\n\n\n\n
The pattern supports a phased migration: first ‘\/api\/orders<\/code>‘, then ‘\/api\/products<\/code>‘, then ‘\/api\/users<\/code>‘. Each migrated route is validated independently before moving on to the next.<\/p>\n\n\n\n
Cookie-controlled deployments<\/h2>\n\n\n\n
The blue\/green deployment maintains two identical environments running simultaneously, one active and one on standby. Switching traffic between them, with multi-source traffic, is a VCL change. No DNS, no maintenance window.<\/p>\n\n\n\n
Canary deployment<\/a> takes this a step further, sending only a fraction of the traffic to the new environment before fully opening it. Cookies allow for precise control. Users with a specific cookie are directed to the new backend; the rest remain in the current one.<\/p>\n\n\n\n
sub vcl_recv {\n  set req.backend_hint = c83_blue.backend();\n\n  # Users with the canary cookie go to the green environment\n  if (req.http.Cookie ~ \"deployment=green\") {\n    set req.backend_hint = c83_green.backend();\n  }\n}\n<\/code><\/pre>\n\n\n\n
In practice, the QA team or beta testers receive this cookie. Production traffic is unaffected. Once validation is successful, the VCL is changed so that everyone goes to the green environment. The switchover is instantaneous.<\/p>\n\n\n\n
The same mechanism applies to phased deployments based on user segments: enterprise customers, users of a specific plan, sessions initiated on a particular date. If the information is stored in a cookie, the CDN can make the decision.<\/p>\n\n\n\n
The header as a routing signal<\/h2>\n\n\n\n
Headers provide more explicit control, especially useful when the client is an internal service, a CI\/CD pipeline, or a QA tool that can construct the request with custom headers<\/a>.
<\/p>\n\n\n\n
sub vcl_recv {\n  set req.backend_hint = c83_produccion.backend();\n\n  # Internal requests with the staging header go to the test environment\n  if (req.http.X-Target-Env == \"staging\") {\n    set req.backend_hint = c83_staging.backend();\n  }\n}\n\n<\/code><\/pre>\n\n\n\n
With this pattern, a CI pipeline can run integration tests against the actual production domain (same URL, same TLS certificate, same CDN) but routed to a test environment backend. The end user never sees these requests. The team tests against the real infrastructure, not against a parallel environment that always has some discrepancy.<\/p>\n\n\n\n
This scheme is also useful in multi-region architectures: the header indicates the client’s origin region, and the VCL selects the corresponding backend without the need for separate subdomains or additional DNS records.<\/p>\n\n\n\n
What changes in practice<\/h2>\n\n\n\n
Multi-origin turns the CDN into a routing layer that operates before requests reach any application server.<\/p>\n\n\n\n
The consequences are concrete:<\/p>\n\n\n\n