Keep applications inside guests
Proxmox provides virtualization. Ubuntu and Docker carry the application dependencies, with container resource limits and restricted networks. The hypervisor’s management interface is outside the public website path.
INFRASTRUCTURE / SELF HOSTING
The page you’re reading comes from my homelab. Here’s how a request reaches it, where the applications live, and what it takes to keep them running.
01 THE REQUEST PATH
Cloudflare is the public entry point. Inside the lab, requests split between the website and the Atlas services. Open either branch below to inspect its role.
Pages, maps and questions
Public HTTPS entry point
Requests travel through the tunnel.
The lab initiates the connection outward.
Nginx serves the homepage, project pages and browser simulations. It forwards the allowed Dan-O routes to the application API.
Coastal Atlas requests also enter here, then continue to the separate Atlas web service.
Dan-O API local modelApproved public facts become reviewed answers.
Support requests private inboxSubmitted details stay out of model prompts.
The Santa Clarita route reaches Atlas Nginx directly. The coastal routes reach the same service through website Nginx.
Both Atlases use a shared API and stored source data. Opening a view does not start a new collection job.
Atlas API PostgreSQL / PostGISA restricted reader accesses stored snapshots.
Source workers stored dataSeparate jobs collect and validate external feeds.
Coastal path: website Nginx Atlas Nginx. The SCV path goes straight to Atlas Nginx.
Proxmox supplies the virtual machine. The web, AI and data services shown above run in containers inside that guest.
02 THE DESIGN DECISIONS
The useful part of a homelab is understanding the boundaries, including the ones it still shares.
Proxmox provides virtualization. Ubuntu and Docker carry the application dependencies, with container resource limits and restricted networks. The hypervisor’s management interface is outside the public website path.
The local model selects from approved public facts. Validated selections become authored text in the browser. Support submissions go to a private inbox through a separate application flow.
The Atlases serve stored observations and forecasts. Background workers handle source collection, while timestamps help visitors understand the age of the data they’re seeing.
The main applications share a guest and a physical host. Containers make services easier to manage, but a host, power or home connection failure can still take the site offline.
03 MAKING A CHANGE
Recent website releases follow a deliberate sequence: capture what is running, validate the change, preserve recovery material, then check what actually shipped.
Record the deployed source, image and service state before making a change.
Preview the page, check phone and desktop layouts, and verify an isolated candidate.
Keep the previous image and configuration, then copy and verify the recovery files.
Replace the intended service. Check public routes, file hashes and the services around it.
04 RECOVERY PRACTICE
Recovery exercises are part of the build. Each one proves a specific recovery point and leaves the remaining gaps visible.
An independent copy of an early application VM backup was restored to an isolated guest and checked for matching files and working services.
The Atlas recovery set and Dan-O’s private inbox have also been restored in isolation from independent copies.
Scheduled retention, encrypted off-site copies and a full physical-host recovery rehearsal remain unfinished. These exercises are not an availability guarantee.