From Home Lab to Internet-Grade Architecture: Lessons from Hosting a Personal Site the Enterprise Way

February 05, 2026

I deliberately scoped it as an end-to-end exercise, starting from a true baseline state: a blank page. The target state, however, was intentional: to design and host a personal website the enterprise way, while minimizing effort, time, and cost. The objective was not simply to get a website online, but to make architectural decisions under real constraints and follow them through to implementation.

Enterprise architecture breaks down when architects lose touch with how things actually run.

As I worked through the transition from baseline to target state, the solution evolved iteratively. Each design decision surfaced new constraints, some imposed by the environment, others deliberately introduced to make this a meaningful, end-to-end learning exercise. The architecture was refined multiple times until it converged on a solution that was both viable and defensible.

Constraints and design considerations

I deliberately introduced a small set of constraints upfront:

No spending on web hosting
No spending on software

In addition, the operating environment imposed its own limitations:

No public IP address, as the site would be hosted behind a residential internet connection
No option to purchase a static IP from the ISP for residential service

To ensure the solution remained production-minded rather than purely experimental, a few non-negotiable requirements were also added:

Support for multiple domains with a clear canonical identity
HTTPS by default
A security posture appropriate for internet-facing systems

Architecture decisions and options considered

With the problem space and constraints clearly defined, the next step was to make a set of deliberate architecture decisions. Rather than optimizing for convenience, I used a simple decision framework to evaluate each major component of the solution, weighing trade-offs against the stated objectives. The goal was consistency, every choice needed to reinforce the same principles: minimal cost, meaningful learning, and enterprise-grade thinking.

Hosting Model

Option	Pros	Cons	Decision Rationale
Traditional Hosting	Simple, familiar	Limited learning value	Not aligned with the learning objective
VPS	High control	Ongoing cost, operational overhead	Overkill for the problem
Home Hosting with Port Forwarding	Simple to implement	ISP restrictions, security concerns	Not viable in this environment
Home Hosting with Cloudflare Tunnel	Secure, modern, no public IP required	Steeper learning curve	Chosen

This decision was pivotal. Cloudflare Tunnel provided a secure ingress model without requiring a public IP or inbound firewall rules, while still exposing the system to real-world internet traffic. The added complexity was intentional and aligned with the goal of hands-on architectural learning.

Hardware Platform

Option	Pros	Cons	Decision Rationale
Dedicated computer	Full control	Higher cost, power usage	Overkill for the workload
Raspberry Pi	Low cost, low power, sufficient performance	Requires careful configuration	Chosen

The Raspberry Pi offered a constrained but capable environment, forcing thoughtful decisions around resource usage while remaining powerful enough for the intended workload.

Website Implementation Approach

Option	Pros	Cons	Decision Rationale
CMS	Rich feature set, extensibility	Unnecessary complexity	Overkill for current needs
Static HTML and CSS	Simple, predictable, minimal attack surface	More initial groundwork	Chosen

A static site aligned well with both the security posture and the learning objectives. It reduced operational complexity while keeping the focus on infrastructure and architecture rather than content management.

Operating System

Option	Decision Rationale
Linux (Raspberry Pi OS)	Open source, stable, well-supported

The choice of operating system was straightforward. An open-source Linux distribution provided transparency, flexibility, and alignment with enterprise infrastructure patterns.

Web Server

Option	Decision Rationale
NGINX	Lightweight, open source, well-suited for reverse proxying and integration with Cloudflare Tunnel

NGINX offered a clean configuration model and mapped well to the responsibilities of the origin server in this architecture, especially when paired with an edge-based security and delivery platform.

Target-State Architecture Overview

The target-state architecture was designed around a clear separation of responsibilities between the edge and the origin, with security and simplicity as primary design drivers. Rather than treating the personal website as a standalone artifact, it was approached as an internet-facing system with defined trust boundaries, ingress controls, and a single canonical identity.

Edge Layer (Cloudflare)

Cloudflare serves as the edge layer of the architecture and represents the public-facing boundary of the system. All inbound traffic is terminated at the Cloudflare edge, where DNS resolution, TLS negotiation, and edge-level security controls are applied.

This layer is responsible for:

DNS and global traffic routing
TLS termination and certificate management
Canonical domain enforcement using redirect rules
Enforcing HTTPS through HSTS
Security controls (WAF, rate limiting, headers)

By centralizing these concerns at the edge, the origin environment remains shielded from direct internet exposure, reducing both attack surface and operational complexity.

Secure Ingress Model

Instead of exposing the origin through inbound firewall rules or port forwarding, secure ingress is established using an outbound-initiated tunnel from the origin to the edge. This reverses the traditional trust model which is the origin never accepts unsolicited inbound connections from the internet.

This approach provides several advantages:

No requirement for a public or static IP address
No inbound ports exposed on the local network
A security posture aligned with zero-trust principles

From an architectural perspective, the tunnel becomes a controlled ingress path rather than a network shortcut. This mirrors patterns increasingly used to expose internal services without expanding the network attack surface

Origin Layer (Raspberry Pi)

The origin environment consists of a Raspberry Pi running a minimal Linux distribution and a lightweight web server. Its responsibilities are intentionally narrow and well-defined.

The origin is responsible for:

NGINX serving only the canonical site
No redirect logic
Minimal configuration surface
Application-focused responsibility

Notably, the origin has no direct knowledge of the internet at large. All traffic reaching the web server has already traversed the edge layer and ingress controls, allowing the origin to remain simple, predictable, and easier to secure.

By pushing redirect and canonicalization logic to the Edge, the origin remains intentionally unaware of non-canonical domains, reducing configuration complexity and eliminating unnecessary request processing.

TLS Termination and Trust Boundaries

TLS is terminated at the edge, where certificates are automatically managed and rotated. Communication between the edge and the origin occurs over the secure tunnel, removing the need for local certificate management or complex TLS configurations on the origin.

This design establishes a clear trust boundary:

The edge is responsible for transport security and client trust
The origin operates within a trusted, private context

This separation mirrors patterns commonly used in enterprise environments, where edge platforms absorb complexity on behalf of downstream systems.

Canonical Domain Strategy

Multiple domains are supported, but the architecture enforces a single canonical identity. One domain is designated as the authoritative endpoint, while all others exist solely to redirect traffic to it.

This strategy ensures:

A consistent public identity
Predictable SEO behavior
Reduced ambiguity in certificate and security policy application

From an architectural standpoint, this avoids the complexity of treating each domain as a separate system while still accommodating multiple entry points.

Redirect Model

Redirect behavior is implemented at the Edge layer using explicit and deterministic redirect rules. All non-canonical domains and variants are permanently redirected before requests are forwarded toward the origin.

By enforcing canonicalization at the edge, non-canonical traffic never reaches the origin, reducing unnecessary processing and eliminating redirect logic from the application tier. This ensures consistent behavior for clients and search engines while keeping the origin intentionally unaware of alternate domain identities.

Architectural Summary

At a high level, the target-state architecture can be summarized as:

A hardened, globally accessible edge
A secure, outbound-only ingress model
A minimal and controlled origin
Clear ownership of security, identity, and traffic flow

Although the system itself is small, the architectural principles applied are intentionally aligned with patterns commonly used in enterprise-scale systems.

Traffic Flow and Request Lifecycle

Understanding how a request traverses the system is critical to validating both the architecture and its security posture. In this target state, the request lifecycle is intentionally simple, observable, and constrained by design.

DNS resolution

A client resolves the requested domain using public DNS, which is managed at the Edge. All entry domains which are canonical and non-canonical, resolve to the edge platform rather than directly to the origin. This ensures that traffic is consistently subject to centralized control before progressing further into the system.
TLS negotiation at the edge

HTTPS connections are established at the Edge, where TLS certificates are centrally managed and automatically rotated. This provides consistent transport security across all supported domains while eliminating certificate management complexity at the origin.
Edge-level policy enforcement

Before any request is forwarded, Edge-level policies are applied, including:
- HTTPS enforcement
- Canonical domain validation
- Permanent redirects for non-canonical domains
- Basic protocol and request sanity checks
Requests targeting non-canonical domains are redirected at the Edge and never traverse the secure tunnel.

Only requests compliant with the defined canonical and security policies are allowed to proceed further.
Secure tunnel traversal

Validated requests are forwarded through an outbound-initiated secure tunnel to the origin. Because the tunnel is established from the origin outward, no inbound connectivity to the local environment is required, and the origin remains unreachable from the public internet.
Origin processing

The web server at the origin operates under a deliberately narrow responsibility:
- It serves content only for the canonical domain
- No redirect or public-facing routing logic exists
- Application-level security headers are applied where appropriate
This constrained role reduces configuration complexity and minimizes the attack surface.
Response propagation

Responses are returned through the secure tunnel to the Edge and delivered to the client over the existing encrypted connection.

Architectural Reinforcement

This lifecycle reinforces a key architectural principle: “every request is validated and constrained before it reaches the origin”, and the origin itself remains intentionally unaware of the broader internet context.

Real-World Applications of the Pattern

Although implemented here for a personal website, the architectural pattern demonstrated maps cleanly to a range of enterprise and public-sector use cases.

Remote offices

Remote or branch offices often operate behind restrictive networks with limited inbound connectivity. An outbound-only ingress model allows centrally managed services to be exposed securely without introducing complex firewall configurations or public IP dependencies.

Secure vendor access

Third-party vendors frequently require controlled access to internal systems. This pattern enables selective exposure of services without granting broad network access, reducing risk while maintaining operational flexibility.

Legacy system exposure

Many organizations struggle to modernize legacy applications that were never designed for internet exposure. Wrapping these systems behind a secure edge and tunnel-based ingress provides a pragmatic path to modernization without immediate refactoring.

Public sector modernization

Public-sector environments are often constrained by procurement, security policies, and legacy infrastructure. This architecture supports incremental modernization by introducing modern security and access patterns without wholesale platform replacement.

Zero Trust transitions

At its core, this pattern aligns with zero-trust principles: no implicit network trust, explicit ingress paths, and centralized enforcement of security policies. It serves as a practical stepping stone for organizations moving away from perimeter-based security models.

While the implementation discussed here operates at a small scale, the architectural principles applied are intentionally scalable. The same separation of concerns, trust boundaries, and ingress controls remain valid as systems grow in complexity and criticality.

Good architecture, after all, should scale both up and down without losing its integrity.

This architecture is not hypothetical. It's the one serving this site.