Initialize second brain vault
This commit is contained in:
21
06_Decisions/Current Direction Questions.md
Normal file
21
06_Decisions/Current Direction Questions.md
Normal file
@@ -0,0 +1,21 @@
|
||||
# Current Direction Questions
|
||||
|
||||
## Situation
|
||||
As of 2026-03-09, Claudio is between jobs and using the next weeks to clarify direction.
|
||||
|
||||
## Main candidates
|
||||
1. Take a new job
|
||||
2. Form a Swiss GmbH for AI consulting / micro-SaaS
|
||||
3. Start something in robotics
|
||||
4. Start something in medical devices
|
||||
|
||||
## Decision criteria
|
||||
- personal energy
|
||||
- learning rate
|
||||
- strategic upside
|
||||
- financial runway / risk
|
||||
- speed to first traction
|
||||
- fit with Claudio's long-term goals
|
||||
|
||||
## Status
|
||||
Open. This note should be updated as options get tested or ruled out.
|
||||
22
06_Decisions/Home Lab Principles.md
Normal file
22
06_Decisions/Home Lab Principles.md
Normal file
@@ -0,0 +1,22 @@
|
||||
# Home Lab Principles
|
||||
|
||||
## Working principles
|
||||
- Start simple
|
||||
- Prefer clarity over cleverness
|
||||
- Document every meaningful architectural change
|
||||
- Production and testing should be clearly separated
|
||||
- Backups and restore confidence are first-class requirements
|
||||
- Avoid deploying many apps before the platform is understandable
|
||||
|
||||
## Near-term app focus
|
||||
1. Drive / file sync
|
||||
2. Photo app
|
||||
3. Identity / access layer
|
||||
|
||||
## Current transition direction
|
||||
- from Synology Drive to possible Nextcloud later
|
||||
- from Synology Photos to possible Immich later
|
||||
- keep current media stack running while broader architecture is clarified
|
||||
|
||||
## Notes
|
||||
This project should be managed incrementally, not as a big-bang migration.
|
||||
97
06_Decisions/Remote Access V1 Proposal.md
Normal file
97
06_Decisions/Remote Access V1 Proposal.md
Normal file
@@ -0,0 +1,97 @@
|
||||
# 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
|
||||
```mermaid
|
||||
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.
|
||||
Reference in New Issue
Block a user