CloudOnFire runs from a residential internet connection with an address that can change. The trick is not pretending that a home connection behaves like a data centre. It is designing the public edge, DNS updates and origin server so that a routine address change becomes boring—and so that publishing the architecture does not publish an attack map.
The architecture in one paragraph
A small web server lives inside an isolated virtualised environment on the home network. The domain’s authoritative DNS is managed at the cloud edge and public requests are proxied before reaching the origin. A tiny Dynamic DNS updater checks the residential public address and changes one designated DNS record only when necessary.
That is the complete public description. Internal addresses, container identifiers, usernames, management paths and exact firewall configuration remain private because none of them would make this article more useful.
Dynamic DNS should have one small job
The updater needs permission to modify the relevant DNS record—not the entire account. The credential should be scoped to one zone and the minimum required DNS-edit capability. It belongs in protected configuration, never in a script pasted into a post, a screenshot, a shell-history tutorial or a public repository.
The update interval does not need to be frantic. The client can compare the current public address with the existing DNS value, update only after a genuine change and log success without printing secrets.
The safest automation is boring, narrowly authorised and almost invisible.
The proxy is helpful, not magical
Proxying through Cloudflare keeps normal visitors away from a direct origin connection and provides TLS termination, caching and traffic filtering. It does not automatically secure the machine behind it. If the origin still accepts arbitrary traffic from the entire internet, discovering the residential address can allow someone to bypass many edge protections.
A stronger design limits web traffic at the origin to trusted proxy networks where practical, keeps the firewall explicit and exposes only what the public site actually needs. The hypervisor, database, SSH and container-management interfaces never belong on the public web.
TLS all the way to the origin
The browser-to-edge connection is only half of the journey. The edge-to-origin connection should also use valid TLS with strict certificate validation. “Flexible” encryption may look convenient, but it leaves the final leg unencrypted and can create confusing redirects. Full strict validation is the goal.
WordPress is part of the security boundary
The network can be beautifully designed and still be undermined by an abandoned plugin or weak administrator account. Themes and plugins stay updated, unused components are removed or disabled, administrator accounts are kept to a minimum and authentication is protected with MFA or a strong identity provider.
The database is reachable only from the application environment. Backups are stored separately and restoration is tested rather than assumed. A backup that has never been restored is merely a theory.
What I deliberately do not publish
- The current or historical public IP address
- Internal subnets, hostnames or container IDs
- Router, hypervisor or operating-system fingerprints
- Exact port-forwarding and management rules
- API tokens, client secrets or screenshots containing them
- The location of administration interfaces
- Backup destinations and recovery credentials
The lessons worth sharing
Use narrowly scoped credentials. Separate public services from management. Encrypt both sides of the proxy. Assume addresses change. Keep the origin patched. Test recovery. Document the principles publicly and the implementation details privately.
A changing home IP is not the interesting problem. The interesting problem is building a system in which change does not tempt you to weaken everything else.
This article intentionally describes a general security pattern, not a reproducible map of the live CloudOnFire network. Configuration should be adapted to your own threat model and verified against current vendor documentation.
Leave a Reply