惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

WordPress大学
WordPress大学
Last Week in AI
Last Week in AI
U
Unit 42
aimingoo的专栏
aimingoo的专栏
Engineering at Meta
Engineering at Meta
博客园 - 聂微东
小众软件
小众软件
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Recent Announcements
Recent Announcements
罗磊的独立博客
MongoDB | Blog
MongoDB | Blog
Stack Overflow Blog
Stack Overflow Blog
博客园_首页
M
MIT News - Artificial intelligence
博客园 - 司徒正美
T
The Blog of Author Tim Ferriss
D
DataBreaches.Net
IT之家
IT之家
C
Check Point Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
T
Tailwind CSS Blog
D
Docker
Microsoft Security Blog
Microsoft Security Blog
Google DeepMind News
Google DeepMind News

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Building My Own Self-Hosted VPN Infrastructure
Samay Kumar · 2026-05-16 · via DEV Community

A few weeks ago I started setting up my own small cloud infrastructure instead of just deploying random projects on platforms like Vercel or Render. Those platforms are genuinely great for getting started, but after a point I wanted something I could completely control myself.

Not just deploying apps, but actually managing the infrastructure behind them.

I wanted my own VPN, reverse proxy, hosted services, proper HTTPS and eventually a fully automated infrastructure stack that I could rebuild from scratch whenever I wanted.

So I rented a small VM on Oracle Cloud Infrastructure and started experimenting.

I picked OCI mostly because I didn’t want to spend real money while learning. Their free compute instances are honestly good enough to start understanding how all these systems fit together. Eventually I also want to move parts of this setup onto my own home server.

What started as:

“Let me setup a VPN”

very quickly turned into learning Linux networking, Docker, DNS, HTTPS, reverse proxies, cloud firewalls, WireGuard internals and a lot of debugging.

This post is mostly about that process.


Starting Small

The VM itself was tiny — just 1 GB RAM and a pretty low-end CPU — which immediately forced me to think carefully about what I was running instead of blindly deploying every tool I found online.

At that point I already had a few Dockerized services running, including my portfolio deployment setup and some personal tooling I’ll probably write about later. I wanted the VPN to become part of a larger self-hosted ecosystem instead of being an isolated side project.

After researching a bit, I found wg-easy. It handled most of the annoying parts of managing WireGuard for me — peer management, QR code generation, mobile configuration and repetitive setup work — which meant I could focus more on understanding networking itself instead of manually editing configuration files all day.

Around the same time I also decided to move away from NGINX. Earlier I was using it for reverse proxying my services and while it worked perfectly fine, I constantly found myself manually handling certificates, creating separate config files and repeating the same setup process for every service.

I wanted something simpler and easier to automate.

That’s when I switched to Caddy.

Automatic HTTPS, simpler configs and easier reverse proxying made the entire infrastructure feel significantly cleaner. I setup subdomain routing, HTTPS for all services and eventually exposed the VPN dashboard through:

vpn.samay15jan.com

Enter fullscreen mode Exit fullscreen mode

At that point the setup finally started feeling like actual infrastructure instead of random containers running on a server.


The Networking Chaos

The part I underestimated the most was networking itself.

TCP vs UDP, OCI security lists, UFW rules, Docker networking, port forwarding — suddenly everything felt like separate layers fighting each other. I had never really worked with real infrastructure networking before, so debugging all of this at once became overwhelming very quickly.

Then came the worst part.

The VPN connected from my phone…

…but there was no internet access.

At first I thought the issue had to be something complicated — NAT problems, Docker networking, IP forwarding, WireGuard routes or firewall rules. I kept jumping between layers trying to figure out where the packets were disappearing.

I spent hours checking:

  • iptables
  • sysctl configs
  • Docker host networking
  • OCI firewall settings
  • WireGuard peer configs

and none of it seemed to explain the issue.

The actual bug turned out to be much simpler.


The Bug That Broke Everything

The issue was Cloudflare.

My VPN subdomain was still proxied through Cloudflare, which meant:

vpn.samay15jan.com

Enter fullscreen mode Exit fullscreen mode

was resolving to Cloudflare IPs instead of my actual OCI server.

Since WireGuard uses UDP instead of traditional HTTP reverse proxying, the VPN traffic never actually reached my machine.

The biggest clue came from running:

sudo wg

Enter fullscreen mode Exit fullscreen mode

There was no handshake. No transfer stats. Nothing.

That immediately told me the server wasn’t even hearing from the client.

After comparing DNS resolution, public IPs and Cloudflare settings, I realized the DNS record was still orange-cloud proxied. The moment I switched it to:

DNS only

Enter fullscreen mode Exit fullscreen mode

everything suddenly started working.

Seeing:

latest handshake: 25 seconds ago

Enter fullscreen mode Exit fullscreen mode

felt weirdly satisfying after spending hours debugging networking layers I barely understood a few days earlier.

That moment also changed how I think about debugging infrastructure problems. Most of the time the issue is not some deep magical failure. It’s usually a wrong assumption somewhere between systems interacting with each other.


The Monitoring Rabbit Hole

Once the VPN finally worked, I immediately went into the observability rabbit hole.

I started experimenting with dashboards, exporters and monitoring stacks using Prometheus, Grafana and eventually Netdata.

And honestly, it looked really cool.

For a while I had graphs, metrics and dashboards for everything running on the server.

Then my tiny 1 GB VM started struggling.

That became another important lesson:
just because you can deploy something doesn’t mean you should.

The monitoring stack itself was slowly becoming heavier than the actual services I cared about. So I removed most of it and decided to keep monitoring lightweight for now.

That decision probably taught me more than successfully running the stack would have.

Infrastructure is mostly about tradeoffs. Complexity vs simplicity, features vs operational cost, experimentation vs practicality — every additional tool changes the operational burden of the system.


What This Project Became

At this point this is no longer “just a VPN project”.

Over time it slowly started becoming the foundation for a much larger self-hosted ecosystem involving automated deployments, infrastructure as code, observability and eventually maybe even multi-node orchestration.

But I also realized I don’t want to jump directly into complexity just because it sounds impressive.

Right now I’m more interested in understanding networking properly, building systems slowly, documenting failures and learning how infrastructure actually behaves instead of blindly following tutorials.

Eventually I want this entire setup to become:

  • reproducible
  • automated
  • version controlled
  • reinstallable from scratch

using tools like Terraform, GitHub Actions and eventually Kubernetes when the infrastructure actually grows large enough to justify it.


Open Source & Repository

I’m also planning to open-source the entire setup including:

  • Docker compose files
  • scripts
  • deployment notes
  • troubleshooting steps
  • infrastructure documentation

The blog itself focuses more on the story and learning process, while the GitHub repository will contain the actual implementation details and technical setup guides.

Repository: infra-101 GitHub Repository

I also want to eventually add:

  • one-step installers
  • automated provisioning
  • detailed wiki documentation
  • explanations for every major configuration file

so the entire setup becomes easy to reproduce for anyone trying to learn similar things.


Final Thoughts

This project taught me far more than I expected.

Not because I memorized commands.

But because I had to debug real networking problems, understand cloud infrastructure, deal with DNS behavior, think about security, manage limited resources and make actual architectural decisions.

The infrastructure itself is still small.

But for the first time it feels like I’m building my own online ecosystem instead of just deploying applications onto someone else’s platform.