Architecture as an operating document, not a slide deck.

The external edge is the boundary between the public internet and WitzOps infrastructure. It is intentionally narrow. Cloudflare sits at this edge and handles public DNS, TLS termination, and traffic policy for the public-facing surfaces.

Public pages and private operational access are treated as separate concerns. Public content is served through a standard edge pipeline. Private access follows a different path with independent controls. Exposure is never accidental. Every ingress path is the result of a deliberate decision.

An internal application gateway provides a single place for routing, access decisions, and request policy. The gateway pattern avoids the sprawl that comes from giving every internal service its own exposure logic.

Nginx is used as the internal gateway. It handles TLS within the internal boundary, routes requests to the appropriate service, and enforces access rules. This keeps the service layer simpler and makes the internal network topology easier to reason about.

Internal services follow a *.lan naming convention. The convention serves a practical purpose: it makes internal resources identifiable and the lab navigable. Naming is treated as a first-class architectural concern because it shapes how operators and automation discover and reason about the platform.

A structured naming scheme reduces cognitive overhead during troubleshooting and keeps configuration predictable. Service discovery and internal routing both depend on names being stable and meaningful.

Observability is an emerging layer. The goal is not to build a dashboard collection but to answer a set of operational questions that matter for day-to-day platform work:

• What is running and where?
• What is healthy and what is not?
• What changed, when, and why?
• What is exposed to the network?
• What needs attention right now?

Dashboards should support operational decisions, not monitoring theatre. The layer will be built incrementally and wired into the existing platform as questions arise in practice, not as a separate system assembled in isolation.

Infrastructure as Code is a roadmap item, not a fully implemented claim. The direction is toward reproducibility, reviewable change, and reducing the amount of infrastructure folklore carried in heads and shell histories.

Ansible, OpenTofu, and Docker Compose are all candidates for different layers of the stack. The approach is incremental: automate what hurts first, keep the surface area manageable, and avoid the trap of overbuilding automation for problems that do not yet exist at this scale. Each piece of automation should solve a real operational friction point before the next is introduced.

The architecture is evolving. Current priorities for the near term:

• Solidify the observability pipeline with metrics, logs, and alerting wired to real operational needs.
• Begin formalizing IaC for the layers where manual configuration creates the most friction.
• Refine the internal gateway configuration into a documented, version-controlled pattern.
• Build the internal operations portal as the authoritative home for runbooks and private topology.

Each item will be written up as it progresses. The architecture page will be updated to reflect what was learned and what changed.