Hybrid Self-Hosted Infrastructure & Operations
An Ansible-managed hybrid infrastructure lab that separates public ingress from private administration across Linux and Windows systems, with Azure Arc governance, monitoring and representative recovery validation.
Role
I designed, configured and now operate this hybrid infrastructure lab, including its public/private boundaries, Linux and Windows administration, Ansible automation, host firewalls, Azure Arc integration, monitoring and recovery validation.
Key results
- Public / private split
- Ingress and administration
- Linux + Windows
- Ansible-managed configuration
- Outbound HTTPS
- Azure Arc governance
- Restore tested
- Isolated recovery evidence
Problem
Selected web workloads needed a controlled public entry point while administration remained private across local and external compute. The environment also needed repeatable Linux and Windows configuration, runtime visibility, protected backups with recovery evidence, and cross-environment governance without moving the systems into Azure.
Architecture overview
The lab spans a Public Edge VPS, an on-site Proxmox and Debian platform, and an external Windows Server environment. Tailscale carries private administration and the edge-to-application path; Git and Ansible provide version-controlled desired state and automated Linux and Windows configuration. Azure Arc adds outbound-only inventory and governance without hosting the managed systems.
Figure 1 — High-level Hybrid Infrastructure
High-level view of the hybrid infrastructure, showing public ingress, local and external compute, private configuration management, and cross-environment governance and operations.
Design decisions
- Public Edge VPS: keeps public HTTP/HTTPS ingress separate from the main application host and exposes no administrative service publicly
- Tailscale: provides encrypted private connectivity for administration and distributed system paths without opening management services to the internet
- Proxmox and the On-site Server: separate the local virtualization layer from Debian and Docker Compose application workloads
- Hybrid Windows Lab: adds practical Windows Server administration and hardening while remaining isolated from public ingress
- Git and Ansible: provide version-controlled desired state, repeatable Linux and Windows configuration, check-mode review, audits and idempotency checks
- Azure Arc: adds inventory and governance across environments without replacing Ansible, Tailscale or the underlying compute platforms
Architecture and trust boundaries
Figure 2 — Architecture and Trust Boundaries
Hybrid infrastructure deployment showing public ingress, private administration over Tailscale, and outbound Azure Arc governance.
Public application traffic
Public HTTP(S) traffic reaches the Public Edge VPS and is forwarded over the encrypted Tailscale path to restricted PROXY-protocol listeners on the On-site Server. Nginx Proxy Manager preserves the original client address before routing approved traffic to the application container.
Private management traffic
The Administration Controller reaches managed Linux systems through SSH and the Hybrid Windows Lab through WinRM over Tailscale; RDP and the private IIS site remain on the same private administration network.
Azure Arc control plane
The On-site Debian Server and Hybrid Windows Lab connect outbound over HTTPS port 443 to Azure Arc for hybrid inventory, resource visibility and Azure Resource Graph; no inbound Azure Arc management port is required.
Implementation and automation
Git stores the desired configuration and operational documentation. Ansible applies Linux configuration through SSH and Windows configuration through WinRM over Tailscale. Relevant changes are reviewed with syntax checks, check mode and diffs before application; assertions, post-change verification and repeated runs cover connectivity-sensitive firewall, SSH and RDP changes. The Administration Controller also acts as the first canary for reviewed Linux hardening changes.
Security model
The security model uses defense in depth: public ingress is separated from administration, management paths use Tailscale, and host firewalls restrict inbound access. The Public Edge VPS uses UFW and Fail2ban; the On-site Server combines UFW with a persistent Docker-aware firewall policy that limits the private web listeners to the trusted edge peer. CrowdSec consumes reverse-proxy logs with the preserved client address for detection and community threat intelligence; no active bouncer is claimed. On Windows, Microsoft Defender and Windows Firewall remain enabled, RDP requires Network Level Authentication, WinRM Basic authentication and unencrypted communication are disabled, SMBv1 is disabled, insecure SMB guest logons are blocked, and IIS remains private.
Hybrid Windows Lab and Azure Arc Governance
The separate Windows Server 2022 Datacenter environment broadens the lab beyond Linux and Docker operations. Azure Arc represents both the Hybrid Windows Lab and On-site Debian Server as connected hybrid machines through outbound HTTPS for inventory, tags and control-plane visibility. Tailscale remains the private administration path, while paid Azure extensions and Azure benefits remain disabled.
Implementation
- Tailscale provides the private administration path. Public RDP, WinRM and IIS access was tested and confirmed closed; Windows Firewall restricts RDP, WinRM and the private IIS site to the administration workstation.
- Ansible manages Windows roles and firewall state over PowerShell and WinRM with NTLM message encryption. Basic authentication and unencrypted WinRM payloads are disabled, while credentials remain in an encrypted vault outside Git.
- A dedicated hardening playbook creates the restricted RDP rule before disabling broad built-in RDP rules, verifies the resulting firewall state and connectivity, and restores the prior rules on verification failure.
- A read-only security audit checks Defender, firewall profiles, RDP with Network Level Authentication, SMB settings, local administration, TLS configuration and update state. SMBv1 server support and insecure SMB guest logons are disabled.
- Azure Arc onboarding for the On-site Debian Server and Hybrid Windows Lab, the private IIS configuration, security audit and remote-access hardening are documented as code.
This enterprise-inspired lab demonstrates practical Windows Server 2022 administration, Azure Arc onboarding for Windows and Debian, and PowerShell/WinRM automation. It is not a production Windows workload or an Azure-hosted compute environment and does not carry public application traffic.
Operations, automation and recovery
Figure 3 — Operations, Automation and Recovery
Infrastructure operations workflow covering version-controlled configuration, validation, Ansible automation, monitoring, backup integrity, and representative recovery testing.
Verification evidence
- Debian Azure Arc audit: changed=0, unreachable=0, failed=0.
- Windows security audit: no baseline violations; changed=0, unreachable=0, failed=0.
- Windows remote-access hardening idempotency check: changed=0, failed=0.
- Private IIS validation: public access remained blocked while private access over Tailscale returned HTTP 200.
- Recovery validation: SHA-256 and archive checks passed; PostgreSQL was restored to an isolated temporary container and ClickHouse filesystem extraction was verified.
Monitoring and operations
Uptime Kuma monitors internal service availability, Better Stack provides an external website check and an independent host heartbeat, Netdata provides host metrics, and CrowdSec contributes detection visibility. A recurring systemd health check covers disk state and backup freshness, with operational notifications sent through Telegram.
Figure 4 — Sanitized Operations Dashboard
Sanitized operational overview showing documented service management, security visibility, hybrid governance, and recovery validation.
Backup and recovery
The backup workflow uses fail-fast execution, locking, atomic archive publication, restricted permissions, integrity checks and SHA-256 checksum sidecars. Recovery checks go beyond backup creation: Restic repository integrity and full-data-read checks passed, PostgreSQL was restored to an isolated temporary container with 50 application tables present, and ClickHouse filesystem extraction was verified before temporary plaintext staging data was removed. This is representative application/data recovery evidence, not a completed full-infrastructure disaster-recovery test.
Backups are not treated as sufficient until recovery has been tested.
Current limitations
The environment is intentionally small and does not provide high availability or automatic failover. The external Restic copy is operator-triggered rather than scheduled, and current recovery evidence covers application and database data rather than complete infrastructure reconstruction. Some resource provisioning remains outside Ansible-managed configuration.
Next improvement
Add a second rotated or independent immutable backup destination and establish a verified recurring VPS backup.
Engineering takeaways
- Architecture diagrams are clearer when compute, connectivity, configuration management, governance and observability are shown as distinct concerns.
- Private administration reduces public attack surface, but it still requires host-level firewall and authentication controls.
- Configuration automation becomes more reliable when paired with review, read-only audits, post-change checks and idempotency verification.
- Backup integrity is incomplete until representative data has been restored and checked in isolation.
- Hybrid governance does not require centralizing every workload on one cloud platform.
Technology
Compute & operating systems
Containers & ingress
Automation & private management
Hybrid governance
Security
Monitoring & Recovery