Files
second-brain/06_Decisions/Remote Access V1 Proposal.md
2026-03-09 18:28:03 +00:00

3.6 KiB

Remote Access V1 Proposal

Goal

Create a simple, production-sane remote access model that is easy to understand, easy to operate, and does not depend on four overlapping paths.

Current problem

Remote access is currently spread across:

  • Tailscale
  • ZeroTier
  • Pangolin
  • Cloudflare reverse proxy / Zero Trust tunnel

This creates overlap, unclear defaults, and more failure modes than necessary.

V1 recommendation

Use two lanes only:

  1. Admin / maintenance lane: Tailscale
  2. User / app access lane: one public reverse-proxy path, preferably Cloudflare tunnel for now

What to do with the current tools

  • Keep Tailscale as the default admin path
  • Deprecate ZeroTier unless a concrete need appears that Tailscale cannot solve
  • Do not make Pangolin the primary edge yet
  • Keep Cloudflare tunnel / reverse proxy as the primary app-access layer for V1

Why this is the right V1

  • Tailscale is strong for operator access, SSH, dashboards, and maintenance
  • Cloudflare is strong for controlled public exposure and gradual publishing of apps
  • Pangolin may still be interesting later, but using it now as both edge and auth adds moving parts before the platform is stable
  • ZeroTier is redundant unless it solves a specific problem better than Tailscale in your setup

V1 policy

Lane 1 — admin / maintenance

Use Tailscale for:

  • SSH / terminal access
  • Grafana
  • OpenClaw admin access
  • internal dashboards
  • Proxmox management
  • Home Assistant admin
  • anything that should not be publicly exposed

Lane 2 — app access

Use Cloudflare tunnel / reverse proxy for:

  • selected apps intended for normal browser access
  • family / friend access later
  • controlled public-facing entrypoints

Lane 3 — not part of V1

  • Pangolin as primary platform edge
  • ZeroTier as parallel mesh

These should stay out of the critical path for now.

Identity recommendation

Do not introduce Authentik as a broad central dependency yet. First simplify access paths. Then, once the app map is stable, decide whether Authentik should sit behind Cloudflare, alongside it, or only protect selected internal apps.

Backup / off-site implication

The parents' Synology NAS is a strong future off-site backup target. That is strategically more valuable right now than adding another access product.

Suggested architecture

flowchart LR
    Admin[Claudio admin access] --> TS[Tailscale]
    Users[Claudio / family / friends app access] --> CF[Cloudflare tunnel / reverse proxy]

    TS --> PMX[Proxmox host and internal services]
    TS --> DELL[Debian backup / Home Assistant host]
    TS --> NAS[Synology production services]
    TS --> VPS[Netcup VPS]

    CF --> NAS
    CF --> PMX
    CF --> VPS

    NAS -. backups later .-> PNAS[Parents' Synology NAS]
    DELL -. backup orchestration .-> PNAS

Concrete V1 rules

  • Every service must have one primary access path
  • If a service is admin-only, it should default to Tailscale-only
  • If a service is user-facing, expose it through Cloudflare only if there is a clear reason
  • Avoid exposing the same app through multiple remote-access products unless documented
  • Record every published service in the architecture notes

First implementation steps

  1. Create a service inventory with one owner host and one primary access path per service
  2. Decide which current services are strictly internal/admin vs user-facing
  3. Remove ZeroTier from the default plan and treat Pangolin as experimental only

Opinion

The cleanest V1 is not the fanciest one. It is the one you can explain on one page and recover under stress.