Infrastructure You Actually Own
I run my own Proxmox homelab, host my own email, manage my own Git server, and deploy client projects to Hetzner bare metal. This isn’t a side hobby. It’s how I understand infrastructure at every layer, and it’s why I can troubleshoot production issues at 2 AM without escalating to a support ticket.
Every platform I build lives on infrastructure I set up and manage. Docker containers, Nginx reverse proxies, SSL certificates, DNS routing, private networking, and monitoring. Everything automated, everything reproducible, everything on hardware the client controls.
Why Self-Hosted Over Cloud
I’ve done the math on AWS and GCP for the workloads I build. For a typical B2B platform serving thousands of daily users, self-hosted Hetzner bare metal costs 60-80% less than equivalent cloud infrastructure. And you own the hardware allocation. No surprise bills when traffic spikes.
More importantly: EU data residency by default. Hetzner runs data centers in Germany and Finland. GDPR compliance is built into the infrastructure layer, not bolted on with region configs. For the European B2B clients I work with, this matters.
The tradeoff is clear: you lose managed services and auto-scaling. For the platforms I build, that’s fine. Laravel with proper queue workers handles load elasticity at the application level. Docker containers restart automatically. The systems I deploy don’t need to scale to Netflix. They need to be reliable, fast, and affordable.
How I Deploy
Containerization
Every application I build runs in Docker containers. The same container that runs on my development machine runs in production. No “works on my machine” surprises. Docker Compose orchestrates the full stack: application, database, cache, queue workers, and reverse proxy.
For Dadooo.ai, the production stack includes PostgreSQL 17, Elasticsearch 8.15, Redis, OnlyOffice for document collaboration, and the Laravel application. All defined in compose, all reproducible from a single docker compose up.
Reverse Proxy and SSL
Nginx handles routing, SSL termination, and load distribution. Cloudflare sits in front for DNS, DDoS protection, and edge caching of static assets. SSL certificates auto-renew. I’ve never had a certificate expire in production.
Networking
Tailscale for mesh networking between servers. OPNsense virtual routers for network segmentation on more complex setups. WireGuard tunnels for site-to-site connections. Servers talk to each other over encrypted private networks. Nothing sensitive crosses the public internet unprotected.
On my own infrastructure, I run UniFi networking with VLANs, firewall rules, and NextDNS for DNS-level filtering. I apply the same principles to client infrastructure: segmented networks, least-privilege access, encrypted tunnels.
CI/CD
For Dadooo.ai, pushing to main triggers the full pipeline: tests run, containers build, and the application deploys automatically. For client projects with stricter change management requirements, I use on-demand deployment with reproducible scripts that can be triggered manually or scheduled.
I host my own Gitea instance for source control and CI. For client projects that need GitHub or GitLab, I integrate with those instead. The pipeline approach stays the same: test, build, deploy, verify.
Monitoring Stack
I don’t rely on one tool. Different layers need different visibility:
- Uptime Kuma: health checks every 60 seconds with Telegram alerts. If a service goes down, I know within a minute.
- New Relic: application performance monitoring, transaction traces, slow query detection, and synthetic monitors that simulate user flows.
- Datadog: infrastructure metrics, container stats, RUM (Real User Monitoring), and session replay. When a user reports “it’s slow,” I can see exactly what they experienced.
- Google Cloud Logging: centralized log aggregation across all services. One place to search when debugging production issues.
This layered approach means I catch infrastructure issues (Uptime Kuma), application performance problems (New Relic), and user experience degradation (Datadog) at the appropriate level. Most issues get resolved before users notice.
Security Posture
Not a deep security audit service, but every deployment gets the basics right:
- Cloudflare edge protection (rate limiting, bot management, WAF rules)
- SSH access via key-only authentication
- Docker containers running as non-root users
- Database access restricted to application containers via Docker networking
- Secrets managed through environment variables, never committed to source
- Regular updates to base images and OS packages
What Ships
A deployment where pushing code to production is boring. Containers that behave identically from dev to production. Networking that’s segmented and encrypted. Monitoring that pages me before your users complain. Documentation so your team can operate it without depending on me.
If you’re spending too much on cloud, tired of environment inconsistencies, or need EU-compliant hosting without the hyperscaler premium, let’s figure it out.
Frequently Asked Questions
Is self-hosted infrastructure reliable enough for production?
I’ve been running production systems on Hetzner bare metal for years. Uptime consistently above 99.9%. Hetzner’s hardware is enterprise-grade, their network is redundant, and their data centers are well-maintained. Combined with proper monitoring (Uptime Kuma, New Relic) and automated container restarts, self-hosted is as reliable as any cloud provider for the workloads I run. The difference is you’re paying a fraction of the cost.
What about auto-scaling? Don’t I need that?
For most B2B platforms, no. Auto-scaling solves burst traffic problems that consumer apps face (viral moments, Black Friday spikes). The platforms I build have predictable traffic patterns. Laravel queue workers handle load elasticity at the application level. If you genuinely need elastic scaling for unpredictable spikes, I’ll tell you and recommend a different approach. But I’ve never had a client’s Hetzner server struggle with their actual production load.
How do you handle backups and disaster recovery?
Automated daily backups of all databases and critical data. PostgreSQL WAL archiving for point-in-time recovery. Backups stored on separate physical servers (not the same machine). Tested restore procedures, not just backup scripts that might produce corrupt dumps. For critical systems, I maintain a documented runbook with recovery time objectives.
Can you migrate us off AWS/GCP to self-hosted?
Yes. I’ve done this multiple times. The process: audit your current usage, map services to self-hosted equivalents, set up the new infrastructure on Hetzner, migrate data, test thoroughly, then cut over DNS. Most B2B platforms use EC2/RDS/ElastiCache which map directly to Docker/PostgreSQL/Redis on bare metal. Managed services like SQS or SNS get replaced by Laravel queues and events. The migration typically pays for itself within 3-4 months through reduced hosting costs.
What happens if the server goes down at 3 AM?
Uptime Kuma sends me a Telegram alert within 60 seconds. Docker containers have restart policies, so transient failures resolve automatically. For persistent issues, I investigate and resolve. I’m the person who built the infrastructure, so I know every layer without needing to escalate. That said, this is rare. Properly configured bare metal with monitoring doesn’t go down often.