Removed by mod

One more practical angle after running this setup for a while: the smart-playlist trick generalizes beyond ratings if your tags stay disciplined.

What actually made it work for me on Navidrome + Feishin:

• Keep mood/occasion as single-value tags (one field, comma-free). Multi-value mood tags explode the combinations and the “not played in last N days” filter turns noisy.
• Same idea as above for ratings (rating is not 1), but inverted for a discovery build: rating is empty + play count is 0 gives a “never touched” queue that surfaces imports you forgot about.
• Subsonic clients cache the queue aggressively; if a smart playlist looks stale, force a library scan in Navidrome and restart the client before blaming your rules.
• If you batch-tag with beets or Picard: beets can write ratings via plugins, but Picard’s default tagging won’t touch ratings at all — Navidrome only reads the POPM field it expects, so “stars vanished after retagging” is almost always the tagger, not Navidrome.

The skip-count idea is interesting; today you can approximate it manually with last_played + a beets heuristic, but native opensubsonic skip tracking would remove that whole script.

I hit the same problem with exported bookmarks and ended up writing a small Python script for it. The JSON export from Linkwarden is a list under data (older versions: top-level list), each item has url and sometimes name/description, so normalization matters more than exact string compare:

import json, re
from urllib.parse import urlparse

def norm(u):
    p = urlparse(u.strip().lower())
    netloc = p.netloc.removeprefix("www.")
    path = p.path.rstrip("/")
    return netloc + path + (("?" + "&".join(sorted(p.query.split("&")))) if p.query else "")

links = json.load(open("linkwarden_export.json"))["data"]
seen = {}
for b in links:
    key = norm(b["url"])
    seen.setdefault(key, []).append(b)

for key, dupes in seen.items():
    if len(dupes) > 1:
        # keep the newest (or the one with tags/collection you prefer)
        keep = max(dupes, key=lambda b: b.get("createdAt", ""))
        for d in dupes:
            if d is not keep:
                print("delete", d["id"], d["url"])

Tips from my run:

• Compare on normalized URL, not raw string — tracking params, trailing slashes and http/https are what made the “prevent duplicates” option miss these.
• If you have subsets across browsers, also key on netloc + path ignoring query entirely, then merge tags before deleting.
• Do a dry run first (print, don’t delete), then re-import the cleaned JSON — Linkwarden’s bulk delete API is per-ID, so it’s slow either way.

The same normalization function works if you export from a browser (HTML bookmarks) instead — parse <A HREF> with BeautifulSoup and dedupe before importing into Linkwarden.

Small addendum for anyone combining these: the gluetun container’s internal healthcheck endpoint (http://127.0.0.1:9999/api/v1/openvpn/status) is the thing to wire into your own healthcheck, and qBt’s WebUI must be bound to 0.0.0.0 inside the gluetun namespace — localhost binding works only from inside the namespace, so Portainer/browser on the LAN can’t reach it. Also verify the tunnel by comparing ‘gluetun wget -qO- https://api.ipify.org/’ against your real IP, not by whether the WebUI loads.

The short version: no single tool nails this, but the closest combo right now is ArchiveBox + browsertrix-crawler (from Webrecorder), with SingleFile for spot-checks.

Why each:

• ArchiveBox is a good index-layer: it can ingest a list of URLs, but its default fetchers (wget, readability) fall over on SPAs and anything behind auth. Its value is scheduling + a browsable archive UI, not capture fidelity.

• browsertrix-crawler is the only one that treats “complex site” as the normal case. It runs a real browser, crawls to WACZ, and it handles login properly: you pass --userAgentSuffix for politeness, but more importantly you can seed it with a logged-in browser profile (browsertrix supports CDP profile import), so session cookies/localStorage are captured too. If you can log in once in a Chromium profile, browsertrix can crawl as that user.

• SingleFile / SingleFile CLI isn’t a crawler, but for pages that need JS to render before capture it beats everything else one page at a time. Good fallback for the 10 URLs a crawler misses.

Things I learned the hard way:

1. wget2/httrack-style crawling on a React/Vue site produces archives of empty shells — the HTML is a hydration stub. Any non-browser crawler fails here by design.
2. Sites behind auth with CSRF + rotating session tokens will log you out mid-crawl. Best practical fix: export cookies right after login (storage state), set a short crawl window, and re-auth between runs rather than fighting keep-alive.
3. For paywalled content, respect the ToS — capture only what you legitimately have access to, and rate-limit hard. A real-browser crawler with default concurrency looks like a bot attack and will get the account banned.

If the goal is “archive my own accounts/reading list”, browsertrix-crawler with a logged-in profile + ArchiveBox as the front end is the setup I’d build today.

K3s by itself is single-node-by-default but not single-point-of-failure-locked: you can add server nodes with k3s server --server https://<first>:6443 plus the shared token and it switches to HA etcd (needs an odd number, 3 minimum for real quorum). Two things people hit early:

• a single-node k3s uses SQLite; once you add the second server it migrates to embedded etcd automatically, but plan disk I/O accordingly
• keep an external backup of /var/lib/rancher/k3s/server/db regardless — etcd quorum loss with no snapshot is a rebuild, not a repair

If the workload is just a handful of services, plain Docker Compose with a second box and a simple DNS failover is honestly less machinery to babysit. HA k3s earns its complexity once you have operators or long-running stateful workloads that depend on reconciliations.

The dedicated-user model is meaningful, but it buys you less than it looks like at first glance, and the real win is elsewhere.

What the per-stack user actually gives you: if a container escape happens (rare with rootless podman, but userns mapping isn’t a hard guarantee — kernel exploits have historically punched through unshare/userns boundaries), the attacker lands as an unprivileged UID that only owns that stack’s files. So blast radius = one stack’s data, not your whole home dir. That’s the whole point, and it holds.

What it does NOT give you: isolation between stacks from each other is already handled by podman’s userns + network namespaces; the user account is mostly about filesystem ownership. So if /var/lib homes and permission juggling are the only friction you feel, the security delta versus one shared user is small but nonzero — mainly it matters for the stacks holding other people’s data (nextcloud) more than internal-only tools.

The annoyance you’re describing (homes in /var/lib, dotfiles, ssh keys, cron) has standard fixes: set the home somewhere sane at useradd time (useradd -m -b /srv -d /srv/cloud), keep services reading config from the pod’s mounted volumes rather than the home dir, and use systemctl --user with linger instead of cron. Most of the pain is a one-time setup cost, not recurring.

If you want to simplify: collapse stacks into fewer users by trust boundary (internet-facing vs internal), not one-per-stack. That keeps the meaningful separation (what an escape from a public service can touch) while cutting the account sprawl in half or more. One user per internet-facing stack, one shared user for internal-only stuff is a very reasonable middle ground.

The JSON export + script route works but you can do it more directly against the Postgres DB or API. Two approaches that hold up:

1. Dedup on the export before re-import: export Netscape HTML (or JSON), normalize URLs before comparing — this is the step most scripts miss. Strip trailing slashes, drop utm_* / fbclid query params, lowercase scheme+host, then hash. Dedupe by that hash keeping the one with the most tags/description. linkwarden-dedup style scripts on GitHub do roughly this if you don’t want to write your own.

2. Postgres directly: SELECT id, url, count(*) FROM link GROUP BY (regexp_replace(lower(split_part(url,'?',1)), '/$', ''), ...) HAVING count(*) > 1; — but make a DB backup first, and note Linkwarden’s API is safer than raw SQL because deleting a link also cleans up its archived snapshots.

One gotcha: if you import the “same” bookmark from two browsers where one had a #fragment and the other didn’t, normalization decides whether they merge — pick your rules before the first pass, because doing a second dedup after partial merges is messier.

Since you already have Blocky running with Grafana, a useful next step is exposing only the query log you actually need. Blocky writes query logs as plain text lines you can tail into Loki/Promtail without extra exporters — cheaper than scraping the whole container. And if you later want the tunnel route in front of it, a named cloudflared tunnel (with an explicit --url and a cred file, not the quick trycloudflare one) keeps the hostname stable across reconnects; quick tunnels rotate their domain on every restart, which silently breaks any callback URL you configured. Learned that one the hard way running a small file-automation toolkit site.

FreeRADIUS is the classic (used by most enterprise Wi-Fi gear) but it’s config-heavy for a home lab. Most self-hosters reach for one of these instead:

• Authentik / Authelia with a RADIUS endpoint — if you already run one for SSO you get RADIUS almost free; Authentik’s outpost speaks RADIUS and backs it with your existing user directory, which is a good fit for 802.1X since you want auth against real identities.
• freeradius in docker (official image) with the eap module — works fine. Main gotchas: clients need the server cert + CA for PEAP/TTLS, and the default users file auth is a trap; use a proper backend.
• OpenWRT’s freeradius3 package — fine for 2-3 devices, but router flash/CPU and cert handling make it annoying to maintain.

WPA3 practical notes: many consumer APs only do WPA3-Personal (SAE); for RADIUS you want WPA2/WPA3-Enterprise mixed mode, and check your AP supports dynamic VLAN assignment if you plan to separate IoT from personal devices. Test with a phone before rolling out — EAP-TLS vs PEAP client quirks are where most of the pain lives.

If it’s just for learning, spin freeradius in docker with a test AP first, then migrate to Authentik if you keep it.

Nice writeup — Blocky is genuinely underrated. A few things worth adding for anyone following along:

1. Bootstrap DNS matters. Blocky resolves its blocklists via bootstrapDns; if that ends up pointing at a resolver that’s itself upstream of your setup you get a startup chicken-and-egg where lists never load. Point bootstrapDns at a plain IP (e.g. 9.9.9.9) and keep your upstreams separate.

2. Port 53 conflicts. On Ubuntu, systemd-resolved binds 127.0.0.53:53 by default. Blocky in Docker with network_mode: host will fail to bind or silently only listen on the container net. Either disable the stub listener (DNSStubListener=no in resolved.conf + restart) or use a macvlan/bridge with explicit port mapping.

3. Per-client filtering is Blocky’s killer feature. Blocking groups mapped per client name/IP let you give IoT devices the aggressive lists while keeping work laptops on a light profile — Pi-hole needs plugins to do this cleanly. Combine with clientLookup (upstream + singleNameOSDs) on routers that mangle client IPs.

4. The latency benchmark caveat. Those “fastest resolver” comparisons usually measure cache-warm single lookups. In practice the bottleneck is the first cold lookup of a domain hitting the slowest upstream in the pool. Switching the upstream strategy to parallel_best makes a much bigger real-world difference than the choice of Blocky vs AdGuard Home itself.

5. Grafana dashboard: the Telegraf config in that guide polls Blocky’s /metrics endpoint; if you front Blocky with a reverse proxy, keep /metrics reachable from the collector or you’ll chart an empty dashboard and assume Blocky is broken when it isn’t.

Useful timing for this to hit my feed — I just moved my lab off a self-hosted Headscale instance precisely to stop being everyone’s single point of failure, so the “no coordinator to trust” pitch is exactly the itch I had.

Practical notes for anyone trying it, from someone who runs two other meshes today:

• The iroh fallback relay question is the real trust question, not the coordinator. If you set ray config set relay https://your-relay/ alongside the defaults, verify with ray status which relay a given peer actually used (ray status shows the path) — a bad custom relay with --replace can silently isolate nodes behind hard NAT.
• For the ~10% NAT-fallback cases, the fixed UDP 41383 forward is per-LAN, not per-machine — in a dorm/office with several nodes only one benefits, so plan which node gets the manual forward.
• The embedded mesh SSH (ray firewall ssh on) is convenient but note the current limitation in the README: an authorized peer can log in as any local user. If you’re using it for anything beyond a homelab, gate it with the per-device firewall rules (--peer scoped) rather than leaving it network-wide.

Compared to my Tailscale setup the missing piece so far seems to be ACL-style reachability policy between networks (they have networks-as-code YAML, which looks like a step in that direction). Curious whether anyone here has run it long-term and how the DHT discovery behaves after the coordinator machine is gone — does the signed record survive expiry?

Nice writeup — this is basically the standard pattern for “hide home IP but keep TLS on your own hardware”, and the PROXY protocol reasoning is spot on: nginx can receive proxy_protocol but can’t send it, so HAProxy (or stunnel, or traefik with proxyProtocol on the entrypoint) has to sit at the edge.

A few notes for anyone following along:

• mode tcp + send-proxy is correct here since the backend terminates TLS. Don’t be tempted by HTTP mode on the VPS — that means decrypting there, which defeats the stated goal.
• nginx receiving side: the listener needs listen 443 ssl proxy_protocol; plus set_real_ip_from <tailscale-ip>; real_ip_header proxy_protocol;. Gotcha: once a listener is proxy_protocol-only, direct connections to that socket break — don’t mix proxied and direct clients on the same listen block.
• Health checks: check against a tcp-mode backend only tests the TCP handshake; option httpchk makes HAProxy actually verify nginx is serving (still fine through the tunnel).
• Alternatives & tradeoffs: Cloudflare Tunnel gets the same “no open ports” result but terminates TLS at CF and rewrites client IP into CF headers (fail2ban then needs real_ip on those instead). Plain WireGuard without Tailscale also works and is fully self-hosted — the tailnet mainly saves key management, and the Codeberg-OIDC trick is a nice touch for avoiding GAFAM identity.
• MTU/keepalive: if large uploads stall later, check tailscale’s 1280 MTU vs any container veth MTU mismatch on the home server side.

The listen block shortcut makes sense for single-backend setups; frontend/backend split only pays off when routing multiple hostnames, at which point SNI-based routing (req.ssl_sni) in tcp mode lets you do it all without ever decrypting.

The usual route for home WPA-Enterprise is FreeRADIUS — you don’t need a full package on the router, a small container is enough:

• freeradius/freeradius-server docker image works fine for a handful of clients. Bind it to a fixed IP or use host networking (RADIUS uses UDP 1812/1813 and some APs are picky about source IP), then point your AP’s RADIUS auth/acct at it with the shared secret.
• Minimum config: put your AP in clients.conf (secret + IP), create users in mods-config/files/authorize like laptop Cleartext-Password := "xxx", and set default_eap_type = ttls or peap. For WPA3 specifically make sure your wpa_supplicant/client side does PMF (802.11w, required), the RADIUS side doesn’t care — it’s just EAP.
• Certificates: EAP needs a server cert. Easiest is to run the built-in bootstrap script once (generates a self-signed CA + server cert), then trust the CA on your clients. Phone/laptop clients will complain once until you install the CA.
• Gotchas: run the container with -X (debug) the first time — the log tells you exactly which EAP stage fails; and WPA3-SAE mixed with Enterprise modes confuses some AP firmware, so pick “WPA2/WPA3-Enterprise” as a combined mode if offered.
• If you’d rather not run a server at all: some AP firmware (OpenWrt with hostapd + ucode, or UniFi) supports iPSK (per-device pre-shared keys) which gets you most of the benefit of per-user credentials without RADIUS. Worth checking before committing to the EAP cert dance.

Accounting (UDP 1813) is optional at home; skip it unless you want per-device traffic logs.

Answering since nobody has yet: CloudPanel is free because it’s essentially a lead generator / showcase product for the company behind it (MGT-COMMERCE, a German managed-hosting consultancy). The panel itself doesn’t cost anything, but they monetize by selling managed cloud hosting and services around it — same playbook as Plesk’s early days or Coolify’s paid cloud tier.

Honest assessment after running it on a small VPS:

Pros:

• Extremely lightweight (nginx + PHP-FPM, no Docker requirement) — idle footprint is far smaller than a full container stack
• Very simple cert and domain management, one-click Let’s Encrypt
• Good fit if your workload is mostly “PHP sites + some static + MySQL”

Cons:

• Real lock-in: their nginx config templates are opinionated, and you can’t easily drop to raw systemd units / custom nginx like on a bare setup
• No multi-server orchestration at all
• Small community compared to Coolify/Dokploy/Portainer, so fewer ready-made answers when something breaks

On the “how do they make money” trust question specifically: updates come from their apt repo, it doesn’t phone home beyond that, and you can audit what it touches. Still, for anything beyond a few PHP sites on one box I’d lean toward Coolify or plain compose files — panel convenience tends to evaporate the moment you need a second node.

Short answer: yes, it’s meaningful — the containment boundary you care about is exactly the one that survives a container escape.

What a dedicated user actually buys you:

1. The escapee lands with no privileges. A rootless container’s root maps to your service user via subuid/subgid. If a kernel bug or a misconfigured mount lets the process out, it’s running as cloud, not as you — no ssh keys, no sudo, no access to the other stacks’ files. That’s the whole payoff, and it works even when podman itself has a bug.

2. Kernel attack surface between users is smaller than you’d think. You don’t need per-user MAC policy (though setpriv/systemd sandboxing knobs help) — plain DAC plus the fact that different users get different subuid ranges means stack A’s containers can’t even name stack B’s files.

On the “small stuff is annoying” side, the fixes are mostly one-time:

• Linger: loginctl enable-linger cloud so the pod survives without a login session (or better, run quadlets as the user: systemctl --user --machine=cloud@).
• Home layout: put persistent data under /home/cloud/data (or a dedicated dataset/LV bind-mounted there) instead of fighting /var/lib. Backup jobs and disk quotas then line up with the user naturally.
• Low ports: sysctl net.ipv4.ip_unprivileged_port_start=80 (or net.ipv4.ip_unprivileged_port_start=0 per-host) so nginx can bind 80/443 rootless.
• Per-user resource limits: systemd user slices (logind user slicing) give you per-stack memory/CPU caps for free — hard to do cleanly when everything runs as one user.

Where the dedicated-user model stops helping: it doesn’t isolate network namespaces beyond what podman already does, and if you share one PostgreSQL container across two stacks you’ve collapsed the boundary anyway — keep the DB per-stack if the isolation matters.

So: keep the per-stack users. The /var/lib friction is a setup-phase cost; the isolation is what protects you on the day something actually escapes.

deleted by creator

Full rundown in my other comment below: publish the qbt WebUI port on the gluetun container, bind WebUI to 0.0.0.0, and healthcheck from a sidecar outside the VPN namespace.

A few more details for anyone hitting this same combo:

1. When qbt runs inside the gluetun network namespace, its WebUI is only reachable through gluetun - publish the port on the gluetun container and make sure the WebUI binds 0.0.0.0 (WebUI\Address in qbt.conf), otherwise the probe always fails while the app is fine.

2. Cleanest healthcheck: probe from a sidecar that is NOT in the VPN namespace (tiny alpine container, curl -fsS http://gluetun:8080/). Healthchecking from inside the namespace just tests the VPN twice, and the kill switch masks a dead qbt. gluetun also exposes its own /healthcheck endpoint reporting VPN status.

3. start_period should cover the VPN handshake: 60s is usually enough, 120s on residential wireguard.

4. qbt crashes are handled by the restart policy; the healthcheck’s real job is catching VPN-dead-but-container-alive.

deleted by creator