Skip to content

All about domain routers

A domain router decides what happens to incoming HTTP requests for a specific domain — which node serves them, which certificate is presented, whether HTTPS is forced, and who's allowed to reach the domain at all.

This article explains where domain routers come from, what each setting controls, and the routing behaviour worth knowing.

Where to find domain routers

In Core, the top-level 'Domain Routers' page lists every domain router across your clusters. Filter by 'Domain', 'Category', 'Force SSL', or 'QUIC' to narrow the list.

Click a domain to open its detail page — each setting has its own tile or section there.

Domain routers are created automatically

You don't create a domain router by hand. Cyberfusion creates one for you, automatically, in response to whatever owns the domain:

  • A virtual host — one domain router for the primary domain, plus one for each server alias.
  • A URL redirect — same pattern: one for the primary domain, one for each server alias.
  • An n8n instance.

The 'Category' tile on the detail page tells you which kind of owner the domain router belongs to. Each domain router belongs to exactly one owner.

Per-router settings

Node

By default, the 'Node' tile shows 'All (load-balanced)' — Cyberfusion spreads requests across every node in the cluster that runs the relevant service (nginx, Apache, etc.).

Click 'Update' on the tile to pin the domain router to a specific node. Two common reasons to pin:

  • Cost — when pinned, the backing resources (FPM pool, Passenger app, etc.) only need to be active on that one node, not on every load-balanced node.
  • Reserve a specific node for specific work — see the Admin-node quirk below.

If the pinned node is unavailable, Cyberfusion fails the traffic over to another suitable node automatically.

Certificate

The 'Certificate' tile attaches the SSL certificate presented for this domain. Free Let's Encrypt certificates are managed for you via a certificate manager; paid certificates are attached here once issued.

Security.txt Policy

The 'Security.txt Policy' tile sets which security.txt file is served for this domain.

Force SSL

When 'Force SSL' is enabled, plain-HTTP requests are redirected to HTTPS. Toggle from the tile.

QUIC

'QUIC' enables HTTP/3 (QUIC transport) for this domain. Toggle from the tile.

Firewall Groups

The 'Firewall Groups' section restricts who may reach this domain router. Toggle on the firewall groups whose IP networks should be allowed.

If no groups are toggled on, all IP networks may access the domain router. The section behaves as an allow-list only once at least one group is selected.

Lock down a staging domain

A common use case for web agencies: put staging.client.example on a domain router with a 'Office IPs' firewall group toggled on. Only your team and the client can reach the staging site — search engines can't crawl it, and a leaked URL is useless to anyone outside the allow-list. Add the agency's office IPs and the client's office IPs to the group; when an IP changes, update it in one place.

For shops and SaaS the same pattern works for an admin domain — admin.shop.example reachable only from head-office IPs, the public storefront unrestricted.

Admin-node quirk

If a node has the 'Admin' group alongside load-balanced groups (such as nginx or Apache), it's excluded from default routing. That node only receives traffic for domain routers where it's explicitly set as the 'Node'.

The use case: keep one node reserved for lower-priority work — serving assets to a CDN, for example — without it being mixed into your main HTTP rotation. To direct specific traffic to that Admin node, pin the relevant domain routers to it; everything else continues to load-balance across the regular nodes.