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:
- Admin / maintenance lane: Tailscale
- 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
- Create a service inventory with one owner host and one primary access path per service
- Decide which current services are strictly internal/admin vs user-facing
- 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.