Hybrid Self-Hosted Infrastructure & Operations
An Ansible-managed hybrid platform combining public VPS ingress, authenticated private Tailscale transport, onsite containerized services, infrastructure monitoring, encrypted backups and tested application and data recovery.
Role
I designed, configured and now operate the hybrid environment, including its public/private network boundaries, Linux hardening, Ansible configuration management, containerized services, monitoring and recovery procedures.
Key results
- 15-minute checks
- Disk and backup health
- Private administration
- Separate Tailscale path
- Ansible-managed
- Repeatable configuration
- Restore rehearsed
- Isolated recovery target
Operational problem
I needed to operate public web services from a hybrid VPS/on-premises environment without exposing the residential network to direct public inbound traffic or exposing administrative interfaces publicly. The environment also needed repeatable configuration, observable service health and a recovery process that could be tested without modifying production data.
Architecture and trust boundaries
Public HTTP/HTTPS traffic enters through the Public VPS Edge. Authenticated, encrypted private connectivity over Tailscale connects the public edge to onsite Docker services on Debian Core, hosted by Proxmox. Public ingress and administration remain separate; a WSL-based administration workstation runs Ansible against the Public VPS Edge, Debian Core and a Linux Canary Host.
Figure 1 — Hybrid Infrastructure Architecture and Trust Boundaries
Overall runtime topology and the separate authenticated administration path.
Configuration management with Ansible
Host and service configuration is maintained as version-controlled Ansible inventory, roles, templates, handlers and focused playbooks. Relevant changes are evaluated with check mode and diffs before application. Assertions and post-change checks are used around sensitive changes such as SSH and firewall configuration, while repeated runs are used to check idempotence.
- Ran relevant Ansible changes in check mode, inspected diffs and assertions, then repeated execution to check idempotence.
- Applied SSH and firewall changes with post-change configuration, connectivity, and public-exposure checks to reduce lockout risk.
Operations and recovery
Uptime Kuma covers public availability and selected private infrastructure. Representative checks cover public websites, analytics, private operational services, reachability, disk state and backup freshness. A systemd oneshot service, triggered every 15 minutes by a timer, checks local disk and backup health; Telegram receives operational alerts.
Backup verification covers archive integrity, required content and checksum validation. An isolated restore rehearsal demonstrates recoverability of selected application and database data without replacing production data. A separate operator-triggered Restic workflow can write an encrypted secondary copy to removable storage.
Figure 2 — Configuration, Monitoring and Recovery Flow
Change validation, observability, alerting, backup verification and isolated recovery flow.
Security hardening and access model
Administrative paths remain private through Tailscale. On managed hosts where these controls apply, SSH uses key-based authentication with root login and password authentication disabled. Host firewalls apply deny-by-default inbound policies. Publicly exposed application ingress on the VPS is limited to the required HTTP/HTTPS endpoints, while administrative access remains private over Tailscale. Web administration remains private, unused administrative or legacy services were disabled, and UFW, Fail2Ban and CrowdSec provide separate controls where configured.
The private Fortress operations dashboard, built with Homepage and managed through Ansible, separates views for public services, monitoring, the Public VPS, Debian Core containers, and network infrastructure; it is reached through Tailscale Serve, and its former directly published application port is closed.
Figure 3 — Access Paths and Service Exposure
Public, private and administrative access paths with their service-exposure boundaries.
Verified operational outcomes
- Public web ingress no longer requires direct inbound exposure of the residential network, while administrative interfaces remain on the private Tailscale path.
- Check mode, diff review, assertions, post-change checks and repeated runs provide evidence for sensitive configuration changes and idempotence.
- Monitoring covers representative service reachability, infrastructure health, disk state and backup freshness.
- Application and database archives are checked before use, and recovery has been rehearsed against an isolated target without replacing production data.
- An encrypted removable secondary copy is available through an operator-triggered Restic workflow.
Current limitations
The environment is intentionally small and does not provide high availability or automatic failover. The encrypted removable secondary copy requires operator action, and current recovery verification covers application/data restoration rather than complete infrastructure reconstruction. Some resource provisioning remains outside Ansible-managed configuration.
Next improvement
Broaden declarative provisioning coverage and repeat the isolated application/data restore rehearsal on a documented schedule.
Technology
Platform
Configuration & Networking
Security
Monitoring & Recovery