The morning after I exposed my girlfriend's portfolio to the internet, I checked my Nginx logs and found dozens of requests trying to access /wp-admin, /wp-login.php, and various WordPress config files. The site wasn't built with WordPress. It was pure HTML and JavaScript. The bots didn't care, they were just hoping to get lucky.
This is the reality of self-hosting in 2026: the moment you expose something to the public internet, automated scanners start probing for vulnerabilities. But here's the thing, I wasn't surprised. I was expecting this. And that's exactly why my infrastructure is designed the way it is.
The Problem: I Want to Share Things, Not Everything
I run a home NAS (UGREEN DXP2800 with an Intel N100) that hosts several services:
- Immich for photo management and sharing
- Vaultwarden for password management
- Paperless-ngx for document organization
- Portfolio sites for my girlfriend and myself
- An arr stack for media management
Some of these need to be accessible to friends and family. Most should never see the public internet. The challenge is creating an architecture that allows selective sharing without creating attack surfaces.
The Core Principle: Login Pages Are Honeypots
After seeing those WordPress probes, one thing became crystal clear: publicly accessible login pages are magnets for automated attacks. Even if your credentials are strong, even if you have rate limiting, even if you think your software is secure, you're playing defense against an army of bots that run 24/7.
My philosophy became simple: if a service requires authentication, it stays behind Tailscale. Period.
What I Keep Private
These services are only accessible through my Tailscale VPN:
- Vaultwarden (password manager) - No way I'm exposing this publicly
- Full Immich instance - Complete photo library with all management features
- Paperless-ngx - All my documents, warranties, financial records
- Arr stack - No reason for this to be public
- NAS admin UI - I disabled UGREEN Link and any cloud features, access only through Tailscale
If someone wants access to my Immich library, I ask them to install Tailscale. Is this friction? Yes. Will non-technical people find it annoying? Absolutely. But the alternative is exposing thousands of personal photos to the public internet, and that's not a tradeoff I'm willing to make.
What I Do Expose (And How)
Public Photo Albums: The Nginx Rules Approach
For sharing specific photo albums publicly, I use a separate subdomain (share.muchagato.dev) with strict Nginx Proxy Manager rules that only allow access to:
/_app(frontend assets)/share(public share pages)/api/shared-links/api/assets/api/albums/api/timeline/api/download
Everything else returns a 403. The login page? Blocked. /api/auth? Blocked. Admin endpoints? Blocked. This means someone can view a shared album and even upload photos to it, but they can't brute-force credentials or enumerate users because those endpoints simply aren't accessible.
I keep album URLs temporary and always set expiration dates. The moment I'm done sharing, the link dies.
The Cloudflare Proxy Decision
For the portfolio sites, I use Cloudflare's proxy (orange cloud) which provides:
- DDoS protection
- IP address hiding
- Bot filtering
But here's the catch: Cloudflare's proxy has a 100MB upload limit. For Immich shared albums where I want friends to upload high-resolution photos, I use DNS-only mode (grey cloud). This means my real IP is exposed, but the tradeoff is worth it for the functionality. I mitigate this by keeping share links short-lived and never leaving them active longer than necessary.
Before settling on this approach, I tried the public Immich proxy project, but it stripped out too many features I actually wanted: uploads, photo locations, presentation mode. Sometimes the DIY solution really is better.
The Services I Almost Exposed (But Didn't)
I've been tempted to host a self-hosted file transfer service (like Erugo, a WeTransfer alternative). The problem? It requires users to log in before uploading. That's an instant disqualifier for me.
I've even considered contributing to the project to add signed temporary anonymous URLs that would allow uploads without authentication. If I ever do host it, I would absolutely block the admin panel and login pages from public access, even if the core upload functionality was exposed.
The pattern here is consistent: if it has a login page, admin panel, or authentication API, I'm extremely cautious about exposing it. And if there's no good reason for it to be public (like my arr stack), it simply stays private.
Real-World Tradeoffs
The Tailscale Onboarding Friction
Getting non-technical people to install Tailscale is unfortunately a challenge, even though it's just creating an account and downloading an app. I try to frame it as "set it and forget it" and offer to help with setup, but it's still friction. Some people just want a link that works in their browser.
This is where the Nginx rules approach for Immich albums shines. I can send someone a URL and they can view photos without installing anything. But for full access where they can create albums, manage photos, use facial recognition? Tailscale is non-negotiable.
The Portfolio Rescue
My girlfriend is a fashion designer who originally hosted her portfolio on Behance. Adobe's automated systems flagged it as nudity (it's artistic fashion photography), and suddenly no one could view it without creating a Behance account. We said screw Adobe and self-hosted it instead.
Now her portfolio is just HTML and JavaScript served through Cloudflare's proxy. I mount an isolated volume with just the image files, no access to the rest of the system. The site is fast, she has complete control, and there's no corporate platform that can arbitrarily flag it. +1 for self-hosting, +1 for programmer boyfriends.
The Document Revolution
Paperless-ngx has completely changed how I handle documents. I scan physical papers, create rules to automatically import email attachments, and save PDFs directly to it. The physical way of storing documents is dead to me now.
I can search for any warranty, find any receipt, and actually remember where I put important documents. All of this stays behind Tailscale because these are sensitive records: tax documents, medical records, financial statements. There's no universe where I'd expose this publicly.
Maintenance and Updates
One of the reasons I went with the UGREEN NAS instead of a fully custom build is the update management. The system automatically checks for updates, I get a notification, I review the changelog, and if it's not breaking, I update immediately. If I were on a fully custom setup, I'd use Watchtower for container updates.
The key is that I disabled all cloud features from UGREEN itself. No UGREEN Link, no remote access through their platform. The admin UI is only accessible through Tailscale. I trust my own security model more than any vendor's cloud service.
The Lessons
After months of running this setup, here's what I've learned:
1. Design around the assumption that bots will find you immediately. They did for me, literally the morning after going public. Have your security model ready before you expose anything.
2. Login pages are the highest-value targets. If you can avoid exposing authentication entirely, do it. Use VPNs for private services, and for public services, use restrictive reverse proxy rules that block auth endpoints.
3. Cloudflare is useful, but understand the tradeoffs. The proxy protects your IP and filters bots, but the upload limit might break your use case. Choose DNS-only when you need it, proxy when you don't.
4. Expiring links are your friend. For anything public-facing that involves user uploads or sensitive content, use temporary URLs and actually enforce expiration dates.
5. The best security is not exposing things in the first place. Before making something public, ask: does this actually need to be accessible from the internet? Most services don't.
6. User friction is a security feature. Yes, asking people to install Tailscale creates friction. That friction also means my password manager and document archive aren't sitting on the public internet.
What I'd Tell My Past Self
If I were starting this setup from scratch, I wouldn't change much. The two-volume architecture (HDD for media, NVMe for Docker) works great. The Tailscale + selective Nginx rules approach handles both privacy and sharing. The Intel N100 with Quick Sync handles Immich's machine learning models efficiently (though that's a topic for another post).
The only thing I'd emphasize more is how quickly you need to have your security model figured out. The bots don't wait. They're already scanning your IP before you've finished your first coffee.
Build for privacy first, then carve out the specific pieces you want to share. Not the other way around.
Running your own NAS? Hit me up, I'd love to hear how you're handling the private/public split.