> Bron: https://neuralex.nl/en/showcase/cloudflare
> Publicly reachable without opening up your network: a Cloudflare Tunnel to our own hardware, Caddy behind it, workers at the edge, mail via Email Routing and Zero Trust for the admin layer.

Showcase · Cloudflare

# Publicly reachable without opening up your network

Every public subdomain runs through a **Cloudflare Tunnel** to our own hardware. On the router **not a single inbound port is open** — the tunnel establishes an outbound connection itself. Behind it, Caddy routes per subdomain; at the edge, workers do the work the origin never has to see.

[Request a demo](/en/contact) [See the comparison](#replay)

0

inbound ports open

1

outbound tunnel

2

workers at the edge

3

mail records: SPF, DKIM, DMARC

Architecture

## From visitor to service — sealed shut from the outside in

Visitors never get further than the edge. Whatever does have to come inside goes through a tunnel that was established from the inside out and ends at a reverse proxy that routes per subdomain.

Two ways

## Open a port, or turn the connection around

The same question — "how do I make my own hardware publicly reachable?" — with two very different answers. On the left the classic route, on the right what we run.

### With port forwarding

1.  Forward port 443 on the router to your own hardware
2.  Your home IP is now sitting in public DNS
3.  Every scanner on the internet knocks directly
4.  Certificates and firewall rules to maintain yourself
5.  Admin interfaces hang off that same public address

### With a tunnel

1.  The tunnel client opens an outbound connection to the edge itself
2.  Not a single inbound port open on the router
3.  Behind the tunnel, Caddy routes each subdomain to the right service
4.  Workers handle what the origin never needs to see
5.  Zero Trust sits in front of everything that should not be public

Tech in detail

## The edge does the work, the network stays shut

### A tunnel instead of port forwarding

Every public subdomain runs through a Cloudflare Tunnel to our own hardware. The connection is established from the inside out; not a single inbound port is open on the router. That removes an entire class of attack surface — the origin cannot be addressed directly.

### One entrance, many services

Behind the tunnel sits a reverse proxy (Caddy) that routes each subdomain to the right service. Publishing a new service means one extra routing rule — no new network opening, no new firewall rule.

### Workers at the edge

Whatever does not have to reach the origin happens at the edge. A router worker intercepts one specific path and passes everything else through to the origin untouched. Traffic that does not need our own hardware never gets there.

### Forms without a mail server

An intake worker handles contact forms and delivers them by email via Email Routing. No mail server of our own to maintain and no API key in the frontend — the secret stays on the edge side.

### Zero Trust in front of the admin layer

Admin interfaces that should not be public sit behind Cloudflare Access. They are reachable without being exposed on the open internet; anyone without proof of access does not get past the edge.

### DNS-as-code

DNS lives entirely on Cloudflare. Changes go through the API, with a backup of the zone beforehand. That makes a record a reviewable, revertible change instead of a click in a panel.

### Honest: the MX trap we walked into ourselves

While moving the mail DNS over, we pointed an MX record at an inbound parse service. That looks fine — the record validates, mail is accepted — but a service like that is not a mailbox. Mail came in and was delivered nowhere, **without a bounce**. Silent data loss, in other words: nobody gets an error, so nobody notices.

Fixed by moving the MX to real routing and setting up SPF, DKIM and DMARC properly after all. The lesson we have applied strictly ever since: an MX record that accepts mail is no proof that mail arrives anywhere. After every mail DNS change, test the full path all the way into the inbox.

Built with Cloudflare TunnelWorkersEmail RoutingZero TrustCaddyDNS-as-code

Edge architecture

## Want your services publicly reachable without opening ports?

This setup runs on our own hardware: tunnel, reverse proxy, edge workers, mail via Email Routing and Zero Trust for the admin layer. We can set it up for you too.

[Request a demo](/en/contact) [Our approach](/en/aanpak)

---
Volledige (opgemaakte) versie: https://neuralex.nl/en/showcase/cloudflare