How My Family Safely Accesses Our Self-Hosted Cloud From Anywhere

Self-hosting your family’s digital life can feel a bit like building a secret base in your living room. On the surface, it’s just laptops and phones. Underneath, it’s a quiet network of services, tunnels, and certificates that keeps everything running.

Most guides stop at:

“Install Nextcloud, add a domain, done.”

And then you’re left with that uneasy question:

“Did I just put my family’s photos and documents on the internet with a password as the only lock?”

This is the story of how I turned our self-hosted setup into something that feels like magic for my family – tap an icon and it just works – while still being engineered like a professional system under the hood.

What “Accessing Our Cloud” Actually Looks Like  

From the outside, we look like any other family:

• Laptops: MacBooks on the table.
• Phones: Samsung Android devices in everyone’s pockets.

From the inside, those devices are quietly talking to a private little universe of services.

We use:

• Nextcloud app on Android and the desktop/web clients on the MacBooks for files and collaboration.
• Element as the Matrix client for messaging.
• PhotoPrism as a progressive web app installed on the phones – it sits on the home screen and behaves like a native gallery app.

Offline reality:

• At home, some things work purely on the local network: Home Assistant, direct NAS access via CIFS/SMB.
• But most services – just like Google Photos or iCloud – depend on the internet. In the van on 4G or on a campsite with weak Wi‑Fi, you notice immediately when the connection isn’t great. That’s not perfect but in no way different from major cloud services.

So the real problem to solve is:

How can my family use all of this as casually as any cloud app,
while I keep the attack surface small enough that I can sleep at night?

The Four Layers That Make It Feel Like Magic (Without Being Reckless)  

The trick is that my family never sees the hardness of the system.
They tap an icon, and four layers quietly cooperate to make that safe.

Layer 1: The Gatekeeper – One Door to the Whole Secret Base  

Every request to our services passes through one single door: a reverse proxy running at home and on a Hetzner VPS.

Imagine walking into a hotel with hundreds of rooms. You don’t get a map of all doors and keys; you talk to the receptionist. That’s what the proxy does for our services.

I use Nginx Proxy Manager as that receptionist. It:

• Routes everything cleanly:
  photos.mydomain.com → PhotoPrism,
  files.mydomain.com → Nextcloud,
  chat.mydomain.com → Matrix.
• Handles SSL certificates so everything is always HTTPS (Let’s Encrypt, auto-renewed).
• Applies basic defence: rate limiting and IP blocking before anything hits the app.

Some services live on local hardware, others on the VPS – but from the outside, it all feels like one cohesive cloud.

How It Actually Works  

User Request → Nginx Proxy Manager → Service
                     ↓
              - TLS termination
              - Rate limiting
              - Header injection (X-Frame-Options, Strict-Transport-Security)

If a bot hammers the login page, fail2ban and Wazuh block the IP before it even reaches Authentik.

Why this matters for remote access

Without this gatekeeper, we’d have a mess of exposed ports, self-managed certificates and URLs. With it, our family has one neat entry point, and attackers have exactly one heavily guarded front door instead of a whole street of unlocked back doors.

Layer 2: One Identity Across the Whole Universe (SSO with Real Policies)  

Next, I didn’t want 15 separate logins floating around. So I built one identity that all our services trust.

That identity lives in Authentik – my self-hosted “Sign in with Google”, except it runs on my hardware and follows my rules.

I deliberately split the world into two zones:

Family Zone – “It just remembers me”  

For the everyday services my family uses:

• Session length: up to 30 days. We log in roughly once a month, not once a day.
• 2FA: encouraged and available, but tuned to be tolerable.
• Access: all family members.

This covers Nextcloud, PhotoPrism, Matrix, Listmonk and more.

Every login feels normal: a familiar page, maybe a 2FA prompt, then we’re in. After that, everything just quietly trusts Authentik in the background.

Admin Zone – “This is the airlock”  

For the things that can break everything if misused:

• Session length: 1 day, so admin sessions expire fast and limit the breach window.
• 2FA: mandatory – TOTP required, no bypass.
• Access: only the admin group, no one else.

This covers Wazuh, Semaphore, Portainer, Synology DSM and other control panels.

How It Actually Works  

User opens PhotoPrism (App)
   ↓
PhotoPrism/nginx redirect to Authentik with proxy forward request
   ↓
Authentik checks:
   - Is there a valid session? (< 30 days old for family zone)
   - Is 2FA satisfied? (if policy requires it)
   - Is user in allowed group?
   ↓
Authentik returns authentication header to nginx
   ↓
nginx validates header and forwards the connection to PhotoPrism

The user sees: one redirect flash, then they’re in. Session persists across all services.

Why this split matters

My family shouldn’t need to re-authenticate every day just because I want tight admin security. If my laptop gets stolen, admin sessions expire in hours, not weeks. And with Authentik, one leaked password doesn’t cascade across services the way 15 separate logins would.

Why this matters for remote access

For my family, remote access feels like one long-lived, safe identity that moves with them from service to service: log in once, then everything works from the café, the van, or the office.
For me as the admin, remote access becomes a narrow, guarded airlock instead of “admin panels on the open web”.

Layer 3: The Invisible Badge – Client Certificates / mTLS  

Even with SSO, I didn’t want every internet-origin request to reach a login page. Some services hold data that is simply too sensitive to be “just protected by a password”.

So for those, I added what amounts to a digital badge check at the door.

Certain devices – our phones, my laptop – carry a client certificate issued by my own internal CA (smallstep). They’re like secret ID cards only our devices possess. I’m my own passport office; only devices I trust get a certificate.

When one of us opens PhotoPrism from a random Wi‑Fi:

1. Our phone automatically presents that certificate during the TLS handshake.
2. The reverse proxy checks:
   “Is this signed by my CA?”
   “Is it still valid?” (1-year validity)
3. Only then does the request get passed on to Authentik and the app.

If the check fails → HTTP 403, no explanation, not even a login prompt.

How It Actually Works  

Client TLS Handshake:
   ↓
Nginx Proxy Manager checks:
   - Does client present a certificate?
   - Is it signed by my internal CA (smallstep)?
   - Is it not expired? (1-year validity)
   ↓
If all pass → forward to Authentik
If any fail → HTTP 403 (no explanation)

Which services use mTLS:

• ✅ PhotoPrism (entire family photo archive)
• ✅ Paperless (all our scanned documents, contracts, tax records)
• ✅ Wazuh, Portainer, Semaphore (admin panels)
• ❌ Nextcloud (see trade-off below)
• ❌ Matrix (external friends need to message us)

The conscious trade-off: Nextcloud doesn’t use client certificates because we sometimes wants to share a folder link with friends. External people couldn’t access that link if a certificate were required. So Nextcloud stays on Layer 2 only (Authentik SSO + strong password + 2FA). Public-facing services get less protection, but they’re also less privileged – segmentation matters.

Why this matters for remote access

From the perspective of the wider internet, those mTLS‑protected services almost don’t exist. No certificate, no login form, no error messages hinting at what’s there.
And yet, from our devices, they’re just one tap away – even from a motel Wi‑Fi at midnight.

Layer 4: The Private Tunnel – WireGuard When We Need “Home” Far Away  

Finally, there are things I never expose, no matter how strong the authentication: raw storage shares, SSH, internal databases, van sensors.

For those, I use WireGuard as a private, encrypted tunnel.

It runs in two flavours:

• Site‑to‑site (always-on): our home router and Hetzner VPS are permanently linked, so internal services can talk without opening extra ports. The VPS backs up to the Synology NAS instance this way – securely, with no public exposure.
• Client‑to‑site (on-demand): when I’m in the van or a café, my laptop or phone can briefly join the home network.

How It Actually Works  

WireGuard Site-to-Site:
Home Router (10.20.30.0/24) ↔ Hetzner VPS (10.40.50.0/24)
              ↓
Services see each other as local network
No NAT traversal, no public ports

This is when I:

• Mount the NAS via CIFS and copy tens of gigabytes from SD cards directly.
• SSH into servers for maintenance.
• Connect Home Assistant sensors and data like van temperature or battery status.

My family barely ever touches WireGuard directly. For them, everyday remote access lives in the layers above; WireGuard is my secure backstage entrance.

Why this matters for remote access

Without WireGuard, I’d have to make trade-offs like “open SMB from the internet” or “no direct file access away from home”.
With it, I turn “only reachable from the couch” into “reachable from the van, but still private” – without widening the attack surface.

How It Feels in Everyday Life  

Scenario 1: My wife opens PhotoPrism from a café  

1. She opens photos.mydomain.com in Chrome.
2. Her phone automatically presents its client certificate – invisible to her.
3. Nginx Proxy Manager validates the certificate → forwards to Authentik.
4. Authentik checks: session still valid? (yes, logged in 2 weeks ago).
5. Authentik returns login header → PhotoPrism grants access.
6. She’s in PhotoPrism, sees all our family photos.

Total friction: Zero. She clicked once, it opened.

Scenario 2: I try to access Portainer from a coffee shop  

1. I open portainer.mydomain.com in Chrome.
2. My laptop presents its client certificate → Nginx accepts.
3. I’m redirected to Authentik login.
4. I enter password + 2FA TOTP code.
5. Authentik successfully authenticated me and logged me in for a day.
6. Connection is forwarded to Portainer and end-to-end encrypted using the client and server certificates.

Why this matters: Someone would need to steal my laptop, my password, and my 2FA tokens in order to access admin panels. And then, I still could simply revoke the certificate and their chance is gone. Layered defence.

Scenario 3: I share a Nextcloud folder link with friends  

1. I create a public share link in Nextcloud.
2. Friend opens the link – no certificate needed, no Authentik login.
3. They see only that specific folder.

This works because Nextcloud deliberately sits outside the mTLS layer. I accept this trade-off and mitigate it with strong passwords, 2FA, and rate limiting.

What This Really Buys Us – And What It Doesn’t  

We gain:

• The comfort of “our cloud works from anywhere” without sprinkling bare login forms across the open internet.
• A clear separation between family comfort and admin discipline.
• An attack surface that is small, logged and predictable instead of a random sprawl of exposed services.
• Defence against credential stuffing, brute force, bots scanning for vulnerabilities, and nosy hotel Wi‑Fi.
• The ability to use unpleasant networks (airport Wi‑Fi, campsite hotspots) with a lot less worry.

We do not gain superpowers:

• Stolen, unlocked devices are still a serious incident – certificates can be revoked remotely, but humans make mistakes.
• Zero‑day vulnerabilities in Nextcloud, Authentik, or Nginx are still possible – I monitor security advisories and auto-update where possible.
• A fully compromised VPS would hurt – segmentation and Wazuh intrusion detection help, but it’s still part of the system.
• Misconfiguration is still a risk – that’s why I use Ansible and treat infrastructure as code, not click‑through wizards.

Security isn’t a force field. It’s a set of layers that make bad things harder, noisier and easier to notice.

This Looks Complex – Because It Is (And That’s Okay)  

Let me be honest: this setup took me months to build incrementally. I didn’t wake up one day and deploy all four layers at once.

It started simple (Nginx + password) and grew as I learned:

• Authentik took a weekend to configure properly (OAuth2 flows, policy debugging).
• Smallstep CA took another weekend (certificate issuance, renewal automation).
• WireGuard was surprisingly easy (30 minutes), but the site-to-site routing took debugging and still occasionally gets me into trouble.
• The policy split (family vs. admin) came after we got annoyed with 2FA on photos.

But here’s the thing: It’s reproducible. Every piece is well-documented open-source software with no vendor lock-in:

• Nginx Proxy Manager (GUI-based, no manual nginx configs)
• Authentik (extensive docs, OAuth2/OIDC/SAML support)
• Smallstep CA (one Docker container, automated via API possible)
• WireGuard (built into the Linux kernel, cross-platform clients)

The “magic” isn’t that I invented something new. It’s how these pieces are arranged so that:

• My family experiences simplicity.
• The internet sees as little as possible.
• I keep enough control to sleep peacefully and still tinker.

Why I’m Sharing This (And What You Can Do With It)  

If you’re reading this and thinking:

“I’d love my own family cloud that feels this seamless –
but I don’t want to spend months debugging TLS and VPN configs.”

Then you’re exactly the kind of person I have in mind for this series.

In the next parts, I’ll break down:

• The hardware behind all of this – NAS, Proxmox host, VPS, and why each service lives where it does.
• How to gradually adopt layers like these yourself instead of trying to build everything in one big leap – with actual configs and the gotchas I learned.

And if you’re already running some services and want help turning them into a setup that feels both professional and a little bit like magic:
I’m happy to help you bridge that gap – from “just a homelab” to “a family cloud you can trust.” The easiest way to reach me is via info@nextlevel-blog.de

This is part of a series on running your family’s digital life on your own infrastructure. See Part 1: The Service Overview for an impression of what we’re self-hosting.