Remove home dependency
Host the public portfolio on Cloudflare Pages so normal website availability is independent of the homelab, home power and broadband connection.
Platform Engineering Case Study
The Platform BehindThis Website
A production-style engineering platform combining an externally hosted Cloudflare Pages portfolio with a Git-managed homelab, central monitoring, security engineering and a daily AI log analyst using the OpenAI API.
Current Architecture
The website is public cloud. The homelab is the engineering platform.
The architecture deliberately separates public availability from home infrastructure while keeping the homelab as a realistic environment for infrastructure, security, observability and automation work.
Executive Summary
Turning a personal website into an operated engineering service.
The public portfolio began as another workload in the homelab. That worked, but it also meant that a power cut, broadband issue, router change or container outage at home could take the site offline.
I changed the architecture so the public Astro site is delivered by Cloudflare Pages. Git remains the source of truth for the website, and the release path is designed around repeatable build, security and post-deployment validation rather than manual editing in production.
The homelab then becomes what it is better suited to be: a controlled platform for infrastructure engineering, observability, networking, security, automation and recovery work. The same platform also feeds a daily AI log-analysis workflow through the OpenAI API so routine evidence can be condensed into a useful operational review.
The Design Decision
Do not make the portfolio depend on the lab it is describing.
A portfolio should still be available when the infrastructure behind the projects is being upgraded, rebuilt or deliberately broken for learning. External static hosting removes an unnecessary availability dependency without reducing the engineering value of the homelab.
This also creates a useful separation of concerns: Cloudflare Pages serves the public application, while the homelab focuses on compute, DNS, monitoring, cloud services, mail relay, network security and future recovery capabilities.
Project Objectives
Designed around availability, evidence and maintainability.
Make delivery repeatable
Build the Astro site from Git and move production deployment toward an auditable GitHub Actions workflow with build, security and HTTP validation gates.
Keep infrastructure authoritative
Use homelab-platform and its IaC structure as the source of truth for migrated infrastructure instead of relying on historical host names or undocumented state.
Operate with evidence
Use Prometheus, Grafana, Blackbox monitoring, system logs and service checks to show whether the platform is healthy rather than assuming it is.
Add AI-assisted review
Run a scheduled daily log analyst that sends selected operational evidence to the OpenAI API and turns it into a concise review of events, risks and follow-up actions.
Separate current from future
Document live services, planned capabilities and retired identities separately so the portfolio reflects the estate that actually exists.
Delivery Approach
Architecture evolved through evidence-led changes.
The current platform is the result of migration and reconciliation, not a greenfield diagram. Existing services were discovered, validated and then documented or moved deliberately.
Reconcile the estate
Audited the live environment, retired stale identities and documented the real workload placement across Proxmox and physical hosts.
Externalise the public website
Moved me.jrwroberts.co.uk to Cloudflare Pages so the public portfolio no longer depends on the home lab to remain available.
Establish IaC authority
Made admin-01 the normal controller and homelab-platform/IaC the authoritative path for infrastructure that has been migrated and validated.
Build operational visibility
Centralised Prometheus, Grafana, Alertmanager and Blackbox monitoring on monitor-01 and expanded health coverage across the estate.
Introduce AI-assisted analysis
Added a daily analysis path that uses the OpenAI API to turn selected logs and security evidence into a concise operational review.
Keep improving the platform
Continue work on backup and restore proof, sensor capture, central logging, network-host analytics and carefully controlled edge services.
Core Components
Each layer has a clear responsibility.
Public Web
Astro + Cloudflare Pages
The public portfolio is built as a static Astro site and hosted externally on Cloudflare Pages for fast delivery without a home-infrastructure dependency.Source & Delivery
GitHub + GitHub Actions
Git owns the application source and delivery workflow, with dependency audit, build verification, deployment and production URL validation forming the release path.Control Plane
admin-01 + Infrastructure as Code
admin-01 is the administration, SSH jump and IaC controller, with homelab-platform providing the desired-state authority for migrated services.Virtualisation
Proxmox-1 + Proxmox-2
The two-node Proxmox VE cluster hosts the virtualised DNS, monitoring, cloud, mail, security, management and home-automation workloads.Core Services
DNS, Monitoring, Cloud and Mail
The platform includes a redundant Pi-hole/Unbound resolver pair, central metrics monitoring, Nextcloud and a controlled SMTP relay.Physical Workloads
docker-01 + media-01
media-01 and docker-01 are separate physical Raspberry Pi systems outside the Proxmox cluster. They provide NFS backup/media services and BirdNET-Go respectively.Security Engineering
sensor-01 + future edge capability
The sensor VM is prepared for Suricata and Zeek capture once the dedicated NIC and SPAN path are ready, while edge-01 remains reserved for an approved future tunnel role.AI Operations
Daily Log Analyst via OpenAI API
A scheduled analysis workflow reviews selected logs and operational evidence, summarises significant events and produces a human-readable daily report for follow-up.Public Delivery Path
From change to production without a home-server dependency.
↓
↓
↓
Daily AI Log Analyst
Use AI to reduce routine log-reading, not replace engineering judgement.
The platform includes a scheduled daily analysis workflow that gathers selected operational and security evidence and submits a controlled digest to the OpenAI API for analysis.
The result is a concise report highlighting unusual activity, notable errors, security-relevant events and suggested areas for follow-up. This gives me a repeatable first-pass review without pretending that an AI summary is itself an incident response decision.
Central Loki and Alloy deployment remains a separate platform workstream; the AI analyst can evolve as the logging architecture becomes more centralised and more service-specific evidence becomes available.
Engineering Challenges
Architecture improved by correcting real weaknesses.
Public availability depended on the house
Problem
A self-hosted portfolio tied normal website availability to home power, broadband, routing and container infrastructure.
Response
Moved the static public site to Cloudflare Pages while keeping the homelab as the engineering environment behind the portfolio story.
Outcome
Visitors can reach the portfolio independently of homelab maintenance or outages.
Historical names had become architecture
Problem
Old identities such as TestServer, DietPi, ids-01 and k3s-node-01 no longer described the real estate.
Response
Reconciled current state, formalised active host roles and retained retired identities only as historical evidence.
Outcome
Architecture, runbooks and future changes now start from the same current-state model.
Logs create more data than insight
Problem
Reviewing raw operating-system, service and security logs manually is time consuming and can hide the events that actually deserve attention.
Response
Created a scheduled daily log-analysis workflow using the OpenAI API to summarise selected evidence and highlight significant events and risks.
Outcome
Routine evidence is condensed into a useful management view while human review remains responsible for action and change decisions.
Future plans could be mistaken for live services
Problem
Planned Cloudflare Tunnel, central logging, SPAN capture and backup capabilities could easily be shown as though they were already operational.
Response
Separated operational, partial, planned and retired states in both documentation and the architecture graphic.
Outcome
The portfolio demonstrates engineering judgement without overstating the maturity of unfinished capabilities.
Operational Practices
Built to be supported after the interesting deployment work is finished.
Git-managed change
Application and infrastructure changes are version controlled and reviewed before becoming the new documented state.
Validation gates
Build, service health, network reachability and production HTTP checks are used to prove outcomes after change.
Monitoring
Prometheus, Grafana, Alertmanager and Blackbox provide central health and availability evidence.
AI log review
A scheduled job uses the OpenAI API to summarise selected daily log evidence and highlight items that merit investigation.
Current-state documentation
Live architecture, future intent and historical evidence are deliberately kept separate to reduce operational ambiguity.
Recovery thinking
Backup and restore capability is treated as part of service maturity, with unproven recovery called out rather than assumed.
Operational Outcomes
A clearer separation between public service and engineering lab.
Skills Demonstrated
Platform engineering across cloud, infrastructure and operations.
Lessons Learned
Resilience sometimes means moving a workload out of the homelab.
Self-hosting is useful when it adds learning, control or operational value. It is not automatically the best answer for every workload.
Moving the public portfolio to Cloudflare Pages removed a fragile dependency while making the delivery process more cloud-native and easier to validate. The homelab became more useful because it could be changed aggressively without taking the public site with it.
The same principle applies to observability and AI operations: collect evidence first, automate the repetitive parts, and keep human judgement responsible for risk, priority and production change.
Explore the Platform
The diagram is the summary. The projects show the engineering.
Explore the other case studies to see how individual capabilities such as monitoring, security, delivery and infrastructure have been built and operated in more detail.