# Homelab Todo List

Curated list of open homelab work across task history, memory, and second-brain notes. Last updated: 2026-04-15.

## Current operating priorities

1. **Backup foundation first**
2. **Simplify hosting and homelab boundaries**
3. **Stabilize access and edge architecture**
4. **Migrate or delete deliberately, not ad hoc**
5. **Document every meaningful infra change**

## Now

### 1. Define and implement the backup foundation
- [ ] Define the backup policy for each critical system: Synology, Proxmox, VPS, Gitea, Joplin, Immich, Paperless, config files
  - Next action: create one backup matrix with source, method, frequency, retention, restore target, and off-site destination
- [ ] Set up Proxmox backup server
  - Candidate target: **goodolddell**
  - Next action: decide whether goodolddell should host Proxmox Backup Server or remain a generic restic/utility host
- [ ] Decide where Proxmox backups should land first
  - Options currently implied by notes: goodolddell, Synology, or both
  - Next action: choose primary landing zone and secondary/off-site path
- [ ] Set up lab-wide backup strategy following 3-2-1
  - Next action: map current copies vs missing copies for each critical service
- [ ] Add backup verification, not just backup jobs
  - Next action: define one monthly restore drill and one automated verification check
- [ ] Write a backup test script / restore validation workflow
  - Next action: start with one service, likely Gitea or Immich
- [ ] Buy a 4-bay NAS for backup at parents' place
  - Blocker: hardware purchase decision
- [ ] Define regular backup flow to parents' NAS
  - Depends on: backup matrix + parents' NAS target design
- [ ] Set up Kopia/Time Machine backup for Claudio's and Alena's machines
  - Next action: choose destination and retention policy

### 2. Simplify the homelab and hosting architecture
- [ ] Simplify hosting and homelab structure because too many things are mixed together
  - Goal: each service should have one clear host, one clear access path, one clear backup path, and one clear reason to exist where it is
  - Next action: create a service inventory table with columns: service, host, purpose, audience, access path, backup path, migration status
- [ ] Decide what belongs on VPS vs Proxmox vs Synology vs goodolddell
  - Next action: classify each service as edge/public, production internal, backup/infra, or experimental
- [ ] Review whether Proxmox should become the central app platform
  - Existing concern: avoid turning it into an unclear catch-all host
- [ ] Keep the VPS minimal
  - Existing note direction: public edge and only truly necessary public components
- [ ] Keep goodolddell focused
  - Candidate role: backup and always-on infra, not random leftover app host
- [ ] Give Orik passwordless access to its own machine only
  - Goal: Orik should be able to operate its own host without interactive password prompts
  - Constraint: do **not** grant write-capable access to other machines on the network
  - Next action: design a least-privilege access model for the local host vs all remote hosts before changing SSH/sudo setup
- [ ] Ensure Orik does not have write access to other machines on the network
  - Next action: separate local-machine automation privileges from remote-machine credentials and confirm remote access should be read-only or absent by default

### 3. Finish the remote access simplification
- [ ] Adopt one default admin lane
  - Recommended target from existing notes: **Tailscale**
  - Next action: confirm Tailscale is the default admin path and mark ZeroTier as deprecated unless proven needed
- [ ] Adopt one default user/app access lane
  - Recommended target from existing notes: **Cloudflare Tunnel / reverse proxy**
  - Next action: list which services are user-facing vs admin-only
- [ ] Evaluate Pangolin + Authentik vs Cloudflare Access free tier
  - Next action: write down what problem Authentik is solving today that Cloudflare alone does not
- [ ] Remove overlapping access paths from the critical path
  - Next action: document one primary access path per service
- [ ] Invite family/friends only after service access model is clear
  - Depends on: service inventory + access policy

### 4. Stabilize the VPS and edge stack
- [ ] Check whether VPS network traffic is limited or throttled
  - Next action: inspect Netcup plan limits and current usage
- [ ] Decide whether a second VPS is actually needed
  - Next action: answer only after traffic/memory constraints are measured
- [ ] Clean up the VPS reverse-proxy sprawl
  - Goal: converge from multiple overlapping edge tools to one proven stack
  - Next action: inventory all currently running proxy/edge/auth components on the VPS
- [ ] Version-control VPS setup
  - Next action: put docker compose files, env templates, and key config under git
- [ ] Add swap to VPS to reduce OOM risk
  - Source: Immich public outage incident on 2026-04-03
- [ ] Add memory monitoring and alerting on VPS
  - Source: Immich public outage incident on 2026-04-03
- [ ] Consider Traefik health-check / config-refresh resilience measure
  - Source: Immich public outage incident on 2026-04-03
- [ ] Fix SSH key sprawl
  - Next action: reduce to one primary key or a very small set
- [ ] Set up `info@frusetik.com` + SMTP for self-hosted apps
  - Next action: decide provider and which apps should send mail first

## Next

### 5. Migrate or remove services deliberately
- [ ] Move Gitea from VPS to Proxmox
  - Preconditions: backup, restore plan, target host decision, access path
- [ ] Move Joplin from VPS to Proxmox
  - Preconditions: backup, restore plan, target host decision, access path
- [ ] Delete Immich from **goodolddell**
  - Intent: remove outdated or misplaced deployment from the Dell machine
  - Preconditions: confirm no required data or active path still depends on it
  - Next action: verify whether Immich on goodolddell is unused/stale, then remove container, volumes, and residual config deliberately
- [ ] Review whether Cloudflare Tunnel management should move off VPS
  - Next action: decide if VPS remains public edge only, or if edge shifts elsewhere

### 6. Validate Immich before declaring it production
- [ ] Test automatic phone backup on Claudio's iPhone
- [ ] Test Immich library + database backup and restore
- [ ] Test public sharing guest experience
- [ ] Run a 1-week stability check
- [ ] Keep Immich **not protected by Pangolin auth** if mobile app backup depends on direct access
- [ ] Verify off-site destination for Immich backups
  - Likely target: parents' NAS or equivalent off-site storage

### 7. Cover the missing app backup gaps
- [ ] Paperless backup
  - Next action: document data path, DB path, and restore steps
- [ ] Decide Paperless public access policy
  - Next action: determine whether it should be public at all or Tailscale-only
- [ ] Define backup rotation for PostgreSQL-backed services
  - Existing note source: Self-Hosting backup section
- [ ] Define config-file backup for infrastructure
  - Includes compose files, tunnel/proxy config, auth config, DNS-related config

## Later

### 8. Monitoring, maintenance, and observability
- [ ] Set up Uptime Kuma or similar monitoring tool
  - Requirement from Claudio: add **read access for Orik**
  - Next action: choose tool and hosting location, then define how Orik should access it safely
- [ ] Build a single service status page
  - Candidate: Glance or Uptime Kuma
- [ ] Add automated health checks + alerts
- [ ] Build the monthly maintenance checklist
- [ ] Set the monthly maintenance reminder
- [ ] Keep maintenance under 1 hour/month through automation where possible

### 9. Network architecture cleanup
- [ ] Define IP ranges properly
- [ ] Set up VLANs for prod, dev/staging, IoT, and guests
- [ ] Document VLAN/subnet map
- [ ] Add inter-VLAN firewall rules with default deny and explicit allow

### 10. Environment clarity
- [ ] Define what is production, testing, and staging today
- [ ] Keep dev/staging separate from production
- [ ] Establish naming conventions for hosts, services, and environments

### 11. Documentation discipline
- [ ] Document everything hosted
- [ ] Keep service inventory current with host, access path, backup method, and owner
- [ ] Record architecture changes in the second brain as they happen

## Suggested sequencing

### Phase A, make the platform safe
- backup matrix
- decide where Proxmox Backup Server lives
- Proxmox backup
- VPS stabilization (swap, monitoring, proxy inventory)
- one primary access path per service

### Phase B, reduce ambiguity
- service inventory with host + purpose + access path + backup path
- confirm Tailscale for admin
- confirm Cloudflare for user-facing apps
- deprecate ZeroTier unless needed
- decide Pangolin/Auth vs Cloudflare role clearly
- decide what goodolddell is for, and remove misplaced services

### Phase C, migrate deliberately
- Gitea migration
- Joplin migration
- Immich production validation
- Paperless backup/access decision
- monitoring deployment

### Phase D, operational polish
- status page
- maintenance checklist and reminder
- VLAN and firewall cleanup
- full documentation coverage

## Open decisions Claudio still needs to make
- Should **goodolddell** become the Proxmox Backup Server, or stay a simpler backup/restic host?
- Which backup target should be primary for Proxmox and service backups: goodolddell, Synology, or both?
- Buy the parents' 4-bay NAS now or later?
- Is Proxmox meant to be the main long-term app host, or mainly test/transition infrastructure?
- Does Authentik stay in the near-term critical path, or should Cloudflare carry more of the access burden for now?
- Is a second VPS actually needed, or is the current VPS just under-instrumented?
- Where should Uptime Kuma live, and what exact read-only access should Orik have?

## Source consolidation notes
This list was curated from:
- `TASKS.md` homelab task state
- `02_Projects/Home Lab.md`
- `02_Projects/Home Lab Plan.md`
- `04_Topics/Self-Hosting.md`
- `05_Resources/Home Lab Architecture.md`
- `05_Resources/Home Lab Inventory.md`
- `05_Resources/Home Lab Incidents.md`
- `06_Decisions/Home Lab Principles.md`
- `06_Decisions/Remote Access V1 Proposal.md`
- `02_Projects/Immich Testing Plan.md`
- workspace memory notes referencing homelab follow-ups
- Claudio additions on 2026-04-15: delete Immich from goodolddell, set up Proxmox Backup Server, set up Uptime Kuma or equivalent with read access for Orik, simplify hosting/homelab boundaries