Running it on a couple of small sites. It is exactly what the pitch says: one Go binary or one container, a single Postgres/SQLite DB, one script tag. Points worth knowing before you commit:

• The hosted version has a free tier for non-commercial sites; self-hosting is completely free, no account needed, and backup is just “dump the database”.
• Because it counts pageviews anonymously by design, there are no funnels, sessions, or referrer chains like Plausible/Matomo. It deliberately does not keep enough data for that. If you might want path analysis later, that is the one thing Goatcounter will not give you.
• Bot filtering is reasonable out of the box; on a small tech site I saw roughly 30-40% of raw hits classified as bots, which matched my nginx log estimates well.
• Self-host gotcha: behind a reverse proxy, make sure you pass the real client IP (X-Forwarded-For), or everything counts as one visitor from the proxy address.

For the “step counter” use case you describe, it is the best fit in this space. The moment you want cohort/behavior analytics is when Matomo or Plausible earn their resource cost.

Nice rebuild. Since you are more interested in development than media, I would reorder that list. Put Forgejo before Nextcloud: it is a single small container, trivially backed up (basically a directory plus a sqlite/postgres DB), and act_runner gives you CI to play with, which is a lot of fun for learning. Nextcloud is the opposite: the heaviest thing on your list and the most common cause of “why is my Pi4 swapping” posts. If what you mainly want is file sync and Obsidian notes, Syncthing plus a git repo (or Obsidian Livesync via CouchDB) covers 90% of it at a fraction of the resources.

Two practical notes for your exact setup, since both SSDs hang off one powered USB hub:

1. USB storage on the Pi4 shares bandwidth with Ethernet (everything goes through the single USB3 controller). Fine for Navidrome, but expect large Nextcloud uploads to tank your network throughput.
2. Before installing anything else, set up automated backups of both disks and actually test a restore. With everything on one hub, a hub or PSU glitch can take out both SSDs at once. Even a nightly rsync of the important directories to one of your two empty SSD slots gives you a second copy.

Keep Tailscale for SSH and expose nothing else publicly until Pi-hole and Forgejo are stable.

Running it on a couple of small sites. It is exactly what the pitch says: one Go binary or one container, a single Postgres/SQLite DB, one script tag. Points worth knowing before you commit:

• The hosted version has a free tier for non-commercial sites; self-hosting is completely free, no account needed, and backup is just “dump the database”.
• Because it counts pageviews anonymously by design, there are no funnels, sessions, or referrer chains like Plausible/Matomo. It deliberately does not keep enough data for that. If you might want path analysis later, that is the one thing Goatcounter will not give you.
• Bot filtering is reasonable out of the box; on a small tech site I saw roughly 30-40% of raw hits classified as bots, which matched my nginx log estimates well.
• Self-host gotcha: behind a reverse proxy, make sure you pass the real client IP (X-Forwarded-For), or everything counts as one visitor from the proxy address.

For the “step counter” use case you describe, it is the best fit in this space. The moment you want cohort/behavior analytics is when Matomo or Plausible earn their resource cost.

Nice rebuild. Since you are more interested in development than media, I would reorder that list. Put Forgejo before Nextcloud: it is a single small container, trivially backed up (basically a directory plus a sqlite/postgres DB), and act_runner gives you CI to play with, which is a lot of fun for learning. Nextcloud is the opposite: the heaviest thing on your list and the most common cause of “why is my Pi4 swapping” posts. If what you mainly want is file sync and Obsidian notes, Syncthing plus a git repo (or Obsidian Livesync via CouchDB) covers 90% of it at a fraction of the resources.

Two practical notes for your exact setup, since both SSDs hang off one powered USB hub:

1. USB storage on the Pi4 shares bandwidth with Ethernet (everything goes through the single USB3 controller). Fine for Navidrome, but expect large Nextcloud uploads to tank your network throughput.
2. Before installing anything else, set up automated backups of both disks and actually test a restore. With everything on one hub, a hub or PSU glitch can take out both SSDs at once. Even a nightly rsync of the important directories to one of your two empty SSD slots gives you a second copy.

Keep Tailscale for SSH and expose nothing else publicly until Pi-hole and Forgejo are stable.

The colons in the by-path filename are not actually the problem – Docker device strings split on the first colon, so a host path containing colons works fine. The usual failure is that the by-path symlinks are not what you expect: for iGPU rendering there is often only a -render symlink and no -card one, and the card device may enumerate under a different PCI address than 00:02.0 depending on platform.

Check what actually exists:

ls -l /dev/dri/by-path/

If there is no -card entry for your GPU, that is why the second line fails. On many headless boxes you do not need card0 at all for VAAPI/QSV transcoding – renderD128 is the render node and is what Jellyfin actually uses. Try mounting only the render node:

devices:
  - /dev/dri/by-path/pci-0000:00:02.0-render:/dev/dri/renderD128

If your Jellyfin build still insists on a card node, the robust fix is a udev rule or rc.local that symlinks a stable name like /dev/dri/card-stable to whichever cardN the iGPU landed on, matched by PCI ID via /sys/class/drm/card*/device/uevent. Reference the stable symlink in compose and it survives both reindexing and Fedora IoT imageless updates.

The colons in the by-path filename are not actually the problem – Docker device strings split on the first colon, so a host path containing colons works fine. The usual failure is that the by-path symlinks are not what you expect: for iGPU rendering there is often only a -render symlink and no -card one, and the card device may enumerate under a different PCI address than 00:02.0 depending on platform.

Check what actually exists:

ls -l /dev/dri/by-path/

If there is no -card entry for your GPU, that is why the second line fails. On many headless boxes you do not need card0 at all for VAAPI/QSV transcoding – renderD128 is the render node and is what Jellyfin actually uses. Try mounting only the render node:

devices:
  - /dev/dri/by-path/pci-0000:00:02.0-render:/dev/dri/renderD128

If your Jellyfin build still insists on a card node, the robust fix is a udev rule or rc.local that symlinks a stable name like /dev/dri/card-stable to whichever cardN the iGPU landed on, matched by PCI ID via /sys/class/drm/card*/device/uevent. Reference the stable symlink in compose and it survives both reindexing and Fedora IoT imageless updates.

The problem you’re describing — reconfiguring things when the IP changes — has a standard fix that costs nothing: a domain with a short-TTL A record updated automatically. Two paths, pick by how your services are consumed:

If the audience is you/family: Tailscale or plain WireGuard to a $4-5 VPS, and the IP churn stops mattering entirely — you connect to the VPS/tailnet name, which never changes, and home-IP changes become invisible. This also sidesteps CGNAT if your ISP is doing that.

If services must be publicly reachable: dynamic DNS. With a Cloudflare-hosted domain, a cron (curl the API with a scoped token, or ddclient) updating the A record every 5 minutes with a 60-120s TTL means a change propagates within minutes. What you must not do is hand-configure the IP anywhere else — certificate SANs, firewall rules, client configs — everything references the hostname only. Once everything is hostname-based, an IP change is a non-event you’ll never notice.

Two honest caveats: if your ISP changes IP while a long-lived connection is up you’ll get one brief blip mid-transfer — nothing reconfiguration can prevent anyway. And if your goal is email delivery from home, a dynamic residential IP is a deliverability problem no DDNS fixes; mail wants to go out via a VPS relay regardless.

Your instinct is right but I’d push back gently on one assumption: the Pi 5 only buys you real containment if you also assume the attacker will escape the container — and container escapes from properly configured containers (no privileged, no docker socket mounted, seccomp default) are rare in practice. What’s not rare is an attacker getting app-level access to one public service and then abusing that service’s credentials: your Nextcloud app password, its SMTP credentials, its access to the reverse proxy config.

So the segmentation that pays off most for minimal effort:

1. Move public services off the NAS box — yes, exactly as you planned. The Pi 5 handles a handful of public services fine. Even without container-escape paranoia, you’ve separated the machine that has your entire NAS/backup dataset mounted.
2. Credentials are the actual lateral path. Whatever the Pi can reach, the Pi’s compromise can reach: make its firewall allow only the specific ports it needs back into the LAN (DNS out, maybe the backup target port), and ideally have it push backups out rather than pull data in.
3. Reverse proxy on the Pi too — your public-facing reverse proxy config is itself a target (acme account, upstream definitions). Keep it with the services it fronts, not with your private infrastructure.

One extra benefit you didn’t mention: rebuilding is now cheap. If the public machine gets trashed — by an attacker, or more likely by you breaking it during an update — your NAS/VPN/DNS stack is untouched and you can redeploy the public box from a compose file in an hour. That separation-for-blast-radius argument sells itself in the first real incident.

Since you’re on Fedora + Linux only (so no TeamViewer/AnyDesk-style proprietary clients), here’s how I’d map your criteria:

For the mum’s Fedora desktop (the GUI/screen case):

• Rustdesk — open source, browser-ish clients (there’s a web client), self-hostable relay. Fedora Wayland support has matured a lot; for the locked-screen problem you need to enable autologin on the target (Wayland logind screen locks are what block most tools) or use a greeter-level unlock. If you control her machine, just setting autologin + a locked wallet/bios is the practical answer every remote tool needs anyway.
• Apache Guacamole is the true “browser-only, self-hosted” answer: it proxies VNC/RDP/SSH through a web page. On Fedora run xrdp (RDP backend) + Guacamole in Docker, and you get full desktop-in-browser even on the lock screen (RDP sessions get their own login prompt — no unlock problem at all). This directly solves your “can’t access the screen if not unlocked” complaint.

For headless servers (keep what you have):

• DWService’s real value in your setup is the out-of-band rescue path. The open equivalent people pair it with is Tailscale as the always-on layer + SSH — Tailscale’s free tier needs no open ports and works when your VPN/reverse proxy is dead because it IS the VPN, coordinating via their hosted control plane (or self-host Headscale if you want zero third party).
• Your worry about “reverse proxy/VPN crashes and I can’t reach the machines” is the right one — the standard answer is a separate out-of-band path: a cheap ESP32/Pi on the same LAN running Tailscale (or a phone hotspot + Tailscale on a USB stick), so the rescue path shares no components with the primary path. That single rule fixes 95% of lockouts.

My honest recommendation: Guacamole for the human-usable browser desktop (RDP backend → lock screens stop mattering), Tailscale + SSH for everything headless, and one tiny always-on rescue node that can’t fail with the main infra.

You’re actually in a better starting position than most newcomers because the Cloudflare Tunnel setup means nothing on your box is directly reachable from the internet — that alone removes the biggest attack surface (port scanning, brute forcing, CVE-driven mass exploitation of exposed services). A few gaps worth closing:

Monitoring, since you asked: before installing anything fancy, get the boring fundamentals working: apt list --upgradable or unattended-upgrades for patch status, a cron that emails you ss -tlnp and docker ps diffs so you know when something new is listening, and disk/smart alerts — in my experience drives dying and cert renewals failing silently are far more likely to bite you than an attacker. Uptime Kuma is a low-effort next step for service-level checks, and with a Pi you already have around, a second machine doing checks of the first is more useful than monitoring from inside the box you’re monitoring.

Duplicati-specific note: it has a history of bugs where restore jobs fail or repository checks go wrong and you only find out at restore time. Whatever your retention, do one actual restore of a few files each month — a backup you’ve never restored is a hypothesis, not a backup.

One thing to think about: E2EE in Nextcloud only protects files you’ve explicitly marked; the database, photos in Immich, etc. are plaintext on disk. That’s fine, but be honest with yourself about what an attacker with the disk would get. Full-disk encryption plus a reboot-dropbear setup covers that gap if the data is sensitive.

Biggest real-world risk for your setup isn’t hackers: it’s misconfiguration during the next “quick change.” Snapshot (even a LVM/zfs snapshot or a docker commit before major container updates) and you can roll back instead of rebuilding.

The AR8151 (atl1c driver) is a known-troublesome NIC, and what you’re seeing is a classic negotiation failure — it’s latching at 100Mb/s and then wedging under load. A few things worth trying, in order of effort:

1. Force the speed on the driver side before suspecting hardware. atl1c has had years of bugs around gigabit autoneg; you can pin the link with ethtool in a systemd unit:

[Service]
ExecStart=/usr/sbin/ethtool -s enp1s0 speed 100 duplex full autoneg off

If it stops freezing at a pinned 100Mb/s, you’ve confirmed it’s the gigabit negotiation path in the PHY, not a cabling/switch issue (though do swap the cable first — a marginal Cat5e can cause exactly this downshift-then-die pattern).

2. Disable ASPM and check MSI interrupts. These onboard Atheros parts share bugs with power management: boot with pcie_aspm=off and try ethtool -K enp1s0 gro off / check cat /proc/interrupts | grep atl1c for interrupt storms. Frozen link with “Link detected: yes” often means the MAC thinks the link is up while the ring buffers have stopped being serviced.

3. Try the newer atl1c from a backports kernel — Debian stable’s in-tree atl1c is old, and several link-stability fixes landed in later kernels. A live-USB of a recent distro is the fastest A/B test: if recent-kernel live media holds a gigabit link fine on the same hardware, it’s purely a driver version issue and a kernel upgrade fixes it.

4. The pragmatic fix: these chips cost pennies to replace. A used Intel i210/i340 PCIe NIC (~¥30-50 / $5-10 on the second-hand market) is the standard selfhosted escape hatch — Intel NICs are bulletproof under Linux and you stop burning evenings on a consumer PHY. Most of us in this community eventually did exactly that.

If it freezes even at 100Mb/s after the ethtool pin, that leans toward ASPM/power-management rather than negotiation, so do step 2 before buying hardware.

On the GitLab point: if you self-host CE and don’t need the newest features, the boring-but-effective posture is pinning to the last patch of the previous minor and only jumping on security releases — then a weekly unattended check of the release notes beats reading every announcement. Two things that actually bite people in practice:

1. The unauthenticated RCE class of bugs usually needs an exposed web endpoint, so an instance that’s only reachable over Tailscale/WireGuard buys you far more than rushing every patch. Network exposure first, patch cadence second.

2. When you do patch, snapshot the VM/container first — GitLab upgrades have historically had the same failure mode as major database migrations: fine on the test instance, wedged on yours because of a leftover custom config. A rollback point turns a scary maintenance window into a five-minute revert.

Also relevant to this week’s Bitwarden note: if the dual-license direction worries you, Vaultwarden keeps your server-side options open regardless of what the official clients do later — the data format is still exportable, so the real risk is forgetting to take regular unencrypted-format backups.

The useful split isn’t by time, it’s by data class — your “churn that isn’t real data” observation is the key:

Separate repositories for real data vs. app state. Databases, logs, container images, caches in one repo with aggressive expiry; documents, photos, configs in another with long retention. Then “how long” becomes easy per class instead of one uncomfortable compromise.

For the churn class, a sane baseline with restic:

restic forget --prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --keep-yearly 2

Reasoning: most restores are “it broke today/yesterday” — dailies cover those. Weekly+monthly exist for “the corruption was already there and I didn’t notice” (ransomware, a bad deploy 5 weeks ago, silently-degraded RAID). Yearly is only worth it for truly irreplaceable data.

Two things worth checking on the borgbase side:

1. Prune actually runs — restic forget without --prune (or borg prune vs borg delete semantics) marks snapshots but never frees repo space. Plenty of people run forget for years and wonder why the repo is full.
2. Restore tests, not just snapshots — quarterly, restore into a scratch VM. A backup that’s never been restored is a hypothesis.

“Keep forever” mostly comes from cheap snapshot storage, but with churn-heavy data old daily snapshots are exactly where dedup saves you the least — the churn is your storage cost there.

Yes, this works and people do exactly this — but a few things will make or break it:

Borg client-side encryption solves your trust worry. The Pi only ever sees encrypted chunks, so it doesn’t matter that it sits on a family member’s network. They can’t read a thing, and they can’t even see file names. Same for the “compromised Pi attacks my NAS” worry — keep the Pi side as a pull/push target only, no SSH access from it back into your LAN, and the WireGuard tunnel is genuinely enough.

NAT traversal is the real friction. With plain WireGuard between two home NATs you’ll be fighting dynamic IPs and CGNAT. Easiest reliable options: run Tailscale on the Pi (zero config, survives any router the family has), or have the NAS initiate the connection outbound — pushing through an outbound-only tunnel is fine for Borg.

Seed at home, then let deltas flow. Do the first full backup at home, then move the disk. Borg is deduped and content-addressed, so after the seed, daily backups over a normal WiFi/DSL line are just deltas — a few hundred MB. No VPS needed unless the family setup proves unreliable.

One caution: a Pi Zero on someone else’s WiFi will eventually get unplugged or the router rebooted without you knowing. Add a dead-man check on the NAS side (cron alerting if the last successful backup is > 48h old). “Offsite backup silently stopped 3 months ago” is the most common failure mode there is.

deleted by creator

Yes, this works and people do exactly this — but a few things will make or break it:

Borg client-side encryption solves your trust worry. The Pi only ever sees encrypted chunks, so it doesn’t matter that it sits on a family member’s network. They can’t read a thing, and they can’t even see file names. (This is the answer to the “you need to trust the remote household” concern — you don’t, that’s the whole point of Borg’s design.)

NAT traversal is the real friction. Your NAS can reach out through the tunnel to push, which works if the Pi side has the tunnel endpoint reachable. Easiest reliable options: have the Pi run Tailscale (zero config, works behind any router the family has), or have the pull direction — Pi connects to your NAS and runs borgbackup --client style pull. With plain WireGuard between two home NATs you’ll be fighting dynamic IPs and CGNAT.

Seed at home, then let deltas flow. Format the disk and do the first borg init + full backup at home. Borg is content-addressed and deduped, so after the initial seed, daily backups over any normal WiFi/DSL line are just a few hundred MB of deltas. No need for a VPS unless the family setup becomes unreliable.

One caution: a Pi Zero on a shared WiFi will eventually get unplugged or the router rebooted and you won’t know. Add a dead-man check on the NAS side (e.g. a cron that alerts you if the last successful backup is > 48h old). The failure mode of “offsite backup silently stopped 3 months ago” is unfortunately the most common one.

Fun writeup. For anyone considering the same route, the ongoing realities after you get the ASN + /24:

• Recurring costs don’t stop at the block: ARIN annual fee (~$250+/yr for this resource class), transit (a 1Gbps BGP session with a real provider runs $50-300/mo depending on who you know), and either your own router that can carry a full table or a manageable VPS as a looking-glass/export point.
• Do the RPKI ROA for your prefix the same day it’s assigned, and set up a bgp.tools/PeeringDB presence early — it’s how network ops will decide whether to accept your announcements, and an unfiltered new origin gets caught in route filters fast.
• Start announcing with conservative communities so you can back out cleanly; and keep the static fallback mentioned in the post because BGP origination outages are silent — the failure mode is “the internet can’t see you,” not an alarm.
• Also worth noting for most readers: you get 95% of the fun (your own ASN visible in bgp.tools, learning BGP hands-on) by renting a cheap VPS from providers that offer BGP sessions on a /48 or even a /24 you lease monthly. Owning the /24 outright is mainly for the permanence.

Not OP but running local LLMs for exactly the privacy reasons you describe, some practical notes:

• For a no-GPU start: llama.cpp (or Ollama as a wrapper) with Qwen3-4B/8B or Llama-3.1-8B at Q4_K_M runs fine on a plain x86 box with 16GB RAM. Speed on CPU is ~5-15 tok/s for 4B-class models, which is usable for search summarization and drafting, painful for long chats.
• Quantization is the whole game: 8B Q4 is ~5GB and close to fp16 quality for everyday tasks; don’t run fp16 on consumer hardware, run the bigger model more quantized instead.
• For your “web search without profiling” use case the actual stack that matters is: SearXNG (self-hosted metasearch, no tracking) -> fetch top N pages -> feed text to the local model for summarization. The LLM part is almost the trivial bit; the search layer is what fixes the privacy problem.
• Remote access: don’t expose Ollama/Open WebUI directly. WireGuard (or Tailscale if you don’t want to manage keys) and you get it on the phone with zero ports open.
• One honest caveat: local small models are noticeably worse at factual recall than cloud ones. Where they shine is processing text you hand them (summaries, extraction, rewriting). Design your workflows around that and the gap mostly disappears.

deleted by creator

test probe