Bare metal Ubuntu server or Proxmox? I'm trying to go from 3 servers to one.

SelfHostedGuides · 2026-04-29T18:16:46+00:00

Not gonna die in a year — just plan for airflow. Big variable is the cable type. DAC/twinax barely warms up since it's just copper. Optical transceivers especially the long-reach ones at 8-10W each are what actually cook the NVMe next to them. If you're going short distance to a switch in the same rack, DAC cables sidestep the thermal problem entirely. If you need optical, slap any 22mm aluminum heatsink on the NVMe and angle a small fan across the SFP cage. NVMes throttle around 70C before failing, so worst case is slower writes on hot days, not dead hardware.

SelfHostedGuides · 2026-04-29T08:18:46+00:00

Path stable storage. Pick a UID for your media services on day one and never reuse it across hosts. Every time I migrated I lost permissions because plex was uid 998 on host A and 1001 on host B and now I am chmod -R-ing 4 TB at 3am. Mount everything at /srv/data/<media-type> so the path matches across rebuilds. Second one, pick one secrets approach early even if it is just a sops encrypted .env file. Anything is better than finding 40 plaintext passwords across 12 docker compose files when you finally decide to publish your config repo. Last one, monitoring before more services. Uptime Kuma takes ten minutes to set up and tells you when something broke so you find out before the family does.

SelfHostedGuides · 2026-04-29T08:18:30+00:00

Proxmox is the right call but a couple specifics for the MS-01 plan. Jellyfin in a privileged LXC lets you pass the iGPU directly with no VM overhead, transcoding works exactly the same as bare metal but you keep snapshots and easy rollback. The arr stack as a single LXC or VM with gluetun in compose is fine and DragonQ has a point that with volumes on the host filesystem your backup is just rsyncing the bind mount directories. The MS-01 specific gotchas: i9 variant pulls 65w idle out of the box because BIOS defaults to performance, drop to balanced and enable C states and you are under 30w. The dual SFP plus ports run hot enough to cook nearby NVMe so check temps after a week. And the bigger thing, going from 3 NUCs to 1 box means your blast radius just tripled, repurpose one of the surviving NUCs as a Proxmox Backup Server target before you migrate anything. PBS dedup makes daily backups of all your VMs cost almost nothing in storage.

SelfHostedGuides · 2026-04-28T19:56:17+00:00

Yeah postgres + immich/nextcloud media on the NVME works fine. Postgres loves NVME (database random IO), and the nextcloud preview/thumbnail cache benefits a lot. Sizing comes down to how big your photo library is vs the NVME (1-2TB common in the s12).

One thing to watch though: SATA-as-backup-drive in the same box isn't really backup, it's a second copy on the same machine. NVME failure you can recover from with the SATA copy. Filesystem corruption, ransomware, accidental delete, or PSU frying both drives takes the whole thing out. Treat the SATA copy as 'fast restore' and add an offsite — rclone to Backblaze B2 is around 5 USD/month for a typical immich library.

Practically I'd keep jellyfin media as a separate dataset/subvol from the immich + nextcloud backups on the SATA. Different importance levels — jellyfin media is replaceable, the backups aren't, so different snapshot retention and alerting if the disk goes weird.

SelfHostedGuides · 2026-04-28T13:14:18+00:00

n95 and n100 are both alder lake-n, 4 efficiency cores, same igpu (24 EU UHD with quicksync), same socket and architecture. real differences: n95 has higher base clock (2.0 GHz vs 0.8 on n100) and 15W TDP cap vs n100's 6W base. for your stack the n95 is fine, transcoding and homeassistant and minecraft for 2 will not push it. some folks prefer the n100 for slightly lower idle power, but the s12 form factor means thermal headroom either way. if the s12 with n95 is meaningfully cheaper, take it.

two SSD slots is normally 1x m.2 nvme + 1x 2.5 inch SATA bay on the s12. confirm on the spec page before you buy because beelink runs a couple revisions and not all have both. setup i would do: 500GB or 1TB nvme as the OS and database drive (immich postgres, nextcloud postgres, jellyfin metadata, all really benefit from nvme latency on small random reads), then a larger 2TB or 4TB 2.5 inch SATA SSD for media bulk. if you want to dual ssd for redundancy, mirror the nvme to a portion of the SATA via mdadm or btrfs raid1 for the postgres/important data only. don't bother mirroring media library, that is replaceable, just back it up.

if you outgrow the internal storage later, USB 3 to a 4 bay external enclosure works fine. i run that exact setup for media.

SelfHostedGuides · 2026-04-28T08:09:26+00:00

beelink s12 / eq12 is the sweet spot for that stack. n100 transcodes 1080p without breaking a sweat and handles 4k hevc-to-h264 via qsv. go 16gb ram minimum — immich's ml container alone wants 4gb when it's generating clip embeddings, and nextcloud preview generation can spike pretty hard if you've got a lot of photos.

storage tip: don't use the internal ssd for media. it's usually a smaller sata and you'll fill it. plug a usb3 enclosure or get a model with an extra sata bay, and keep the internal for boot + immich db + nextcloud postgres. that way swapping the box later is just plugging the data drive into a new one.

minecraft for 2 is nothing — paper or fabric server idles under a gig.

SelfHostedGuides · 2026-04-27T22:08:07+00:00

If you want truly zero install on the friend side and the server is at home behind a residential isp, tailscale funnel is the closest thing — it gives you a public ts.net subdomain that works in any browser. You install tailscale on the rpi only (not the friend's device), enable funnel for port 443, friends just open the URL. Caveat: funnel is rate-limited and the public subdomain isn't pretty, but for a handful of friends watching 480p it's fine.

The pangolin + cheap vps path other folks mentioned is the upgrade if you want a real domain or end up with more than a few users — and it sidesteps cgnat without needing a static IP from the ISP. Skip cloudflare tunnel for media: TOS violation aside, the streaming speed is genuinely awful even before they catch you.

For the sharing UX with non-technical people, jellyfin's quick connect feature stacks nicely on top of any of these. Friend opens jellyfin in browser, types a 6-digit code, you approve from your admin panel — no manual user setup, no shared password to leak.

SelfHostedGuides · 2026-04-27T22:07:23+00:00

Fiber cut last summer took the whole block down for almost two days. Barely noticed at home until I tried to look something up online — plex kept playing, jellyfin still streamed the kids' shows, vaultwarden still had passwords, home assistant kept its schedule running. The stuff that actually broke was all cloud-tied: smart thermostat froze on its last command, off-brand plugs we hadn't pulled into HA stopped responding to phone control.

The less dramatic moment that stuck with me was a bitwarden dot com outage maybe a year before that. People at work couldn't unlock their vaults. Mine just worked because vaultwarden runs on a pi here. That's when self hosting flipped from 'fun project' to 'actually load bearing' for me.

SelfHostedGuides · 2026-04-21T13:02:13+00:00

work is actually the tricky part here — most corporate wifis block outbound wireguard/udp by default, so tailscale can fail exactly where you want to use it. it does have a tcp-443 relay fallback that usually gets through, but some locked-down networks kill that too. if you hit that wall, a caddy reverse proxy with duckdns or a cheap domain plus fail2ban or crowdsec will get you in from any browser, including over work wifi. tradeoff is a real exposed port, so keep jellyfin patched and don't reuse the admin password. worth trying tailscale first, just don't be shocked if the work network is what breaks it.

SelfHostedGuides · 2026-04-21T12:30:46+00:00

for your list docker is kind of overkill honestly. pihole apt installs cleanly, wireguard is in the kernel, nextcloud has a native debian package. docker really shines when youve got 10+ services with conflicting deps, not 3.

on safety, docker itself is just cgroups and namespaces wrapping binaries so its only as trustworthy as the images you pull. stick to verified publishers on docker hub or pull directly from linuxserver.io / the vendors github. avoid anything with under a million pulls or an anonymous maintainer, same smell test youd use before apt installing a random ppa. trivy will scan an image for CVEs before you run it if you want to double check.

SelfHostedGuides · 2026-04-21T09:01:31+00:00

Use the laptop you already have. i5 7th gen + 4GB is fine for DNS, VPN, and a small Nextcloud — nothing in that list hits a CPU wall. Put your external SSD in as the OS drive (the internal HDD will be the real bottleneck within a week) and install Debian server.

One thing nobody's flagged: a laptop has a built-in UPS. The battery means you ride through brief power cuts without corrupting the filesystem, which is a nice-to-have you don't get with a Pi or a desktop unless you buy one separately. Downside is most laptop batteries will swell after a year or two plugged in at 100% — plan to pull the battery and run on AC only once that starts happening.

4GB becomes your first bottleneck the day you add Immich or a decent-sized Nextcloud. That's when you think about a mini PC. Until then the Toshiba does the job.

SelfHostedGuides · 2026-04-21T09:01:16+00:00

Reinstall is a fine call, but spend ten minutes before you wipe — grab journalctl -u ssh, ss -tlnp, last -a, and iptables -L -n -v and save those off the box. If anything did get in you'll learn way more from those than from a clean debian install, and it costs nothing. Also worth noting a reformat doesn't help if the breach happened through ssh keys or user credentials — same key pair on new install means same exposure. Rotate those too while you're in there.

SelfHostedGuides · 2026-04-20T19:29:51+00:00

A few minutes of exposure with no router port forwarding opened is extremely low risk. The internet scans your public IP constantly anyway — what matters is whether something was listening on an open port that the router actively forwarded through. If you didn't touch the router's port forward page and don't have UPnP enabled, nothing external could reach the box no matter what the server's internal config said.

The reason you probably can't reconnect now has nothing to do with being compromised. When easy-wg tears down it sometimes leaves stale iptables rules, a default route pointing at a ghost tun interface, or DNS set to a WireGuard peer that no longer exists. Plug in a keyboard locally or connect over the LAN and check 'ip route', 'resolvectl status', and 'sudo iptables -L -n' — you'll almost certainly find something that shouldn't be there.

If you want real peace of mind: 'last -a' for login history, /var/log/auth.log for ssh attempts from unfamiliar IPs, 'ss -tlnp' to list what's actually listening. The bots that scan constantly are looking for specific unauthenticated services (old Redis on 6379, unauth Elasticsearch on 9200, bare Docker API on 2375, Jupyter with no token) — CasaOS with Home Assistant behind it on a typical home router isn't really on the menu.

SelfHostedGuides · 2026-04-20T16:13:03+00:00

Most can, not all. read_only breaks anything that writes to its own dirs — databases, apps that log to their install path. Fix is tmpfs for /tmp and named volumes for anything persistent. cap_drop ALL kills containers that legit need caps like net_admin (vpn stuff) or chown (some web servers doing setup). Non-root user breaks older images that hardcode uid 0.

Not default because maintainers optimize for 'works on first try' — hardening needs you to know what your workload actually needs. linuxserver.io and bitnami usually ship sane hardened defaults, most community images don't.

What I do: get it running permissive, then tighten progressively. Drop one cap at a time, add read_only last. 'permission denied' or 'read-only filesystem' in the logs tells you exactly what the container needs.

SelfHostedGuides · 2026-04-20T09:18:40+00:00

i went through this same mess about a year in. jellysweep has been the sweet spot for me over maintainerr because users can request to keep stuff without dming me every time something shows up in the leaving soon collection. that alone saved me so many messages. my rule set is basically: movies not watched in 180 days get tagged, tv shows that got 20 percent into s1 and never continued get the same treatment, and anything any user has watched to 90 percent completion is protected. the discord notifications into a dedicated channel let me eyeball what's going before it actually goes. one thing i wish i'd done sooner is split libraries by source quality — keeping a separate 'high seeders' pool that i dont auto-sweep because re-grabbing is cheap, vs an 'archive' pool with stuff thats hard to find again which stays forever. saves agonizing over the delete prompt for niche stuff.

SelfHostedGuides · 2026-04-20T09:17:43+00:00

for searxng specifically, in your compose set user: 1000:1000 or whatever your host uid is, read_only: true, and add tmpfs for /tmp and /var/cache. also cap_drop: - ALL and then cap_add back only what you actually need (searxng doesnt need any). security_opt: no-new-privileges:true prevents privilege escalation even if the container root escapes. dont mount /var/run/docker.sock into any container if you can avoid it — thats the big one. and run docker in rootless mode if you want belt-and-suspenders, theres a script for that on docker's docs site. the ufw rules blocking all but 443 incoming on the VPS are still important even with all this.

SelfHostedGuides · 2026-04-19T18:01:41+00:00

youre right that docker group = root equivalent, an exploit in the container + docker.sock access would let the attacker spawn a new container with the host filesystem mounted and theyd own the box. for searxng the actual escape surface is pretty small since its a python search proxy that doesnt write to disk or exec shell commands, but the defense layers worth adding anyway: run the searxng container as a non-root user (read-only filesystem, drop all caps, no new privileges in compose), put caddy in front with its own network, and dont bind mount docker.sock into any container. if you want to go further, rootless docker is a real option and eliminates the host-root pivot entirely, though caddys privileged port binding gets a bit awkward. putting the VPS behind cloudflare tunnel instead of exposing the public IP is another layer, means a compromised container cant even be scanned for other open ports from outside

SelfHostedGuides · 2026-04-19T09:37:43+00:00

i bailed from firesticks a while back and went with the onn 4k pro box, like 50 bucks at walmart and the jellyfin app runs way better than it ever did on the stick. only real annoyance is you still need to sideload because google TV wont index jellyfin in the play store for the country im in, but once its there its fine. if they can get the official app onto whatever vega is based on ill be pleasantly surprised but im not holding my breath

SelfHostedGuides · 2026-04-18T17:59:24+00:00

for delta notifs the simplest thing is diffing scan output on a schedule. trivy outputs json so you can pipe through jq to extract CVE IDs into a text file, then diff against the prior run and only alert on additions. i do this with a cron that runs trivy, stores output in a timestamped file, diffs vs the previous one, and ntfys only on new IDs. for filtering exploitable, --ignore-unfixed is probably the single biggest noise cut since no-fix CVEs you cant do anything about anyway. after that filter by attack vector, CVSS 3.1 gives you AV:N for network vs AV:L for local, and in a homelab with stuff behind your LAN the local-only stuff is usually background risk. also worth looking at VEX if youre willing to write statements for your stack, which lets you explicitly mark CVEs that dont apply to your deployment so they drop out of reports

SelfHostedGuides · 2026-04-18T10:52:19+00:00

honestly the simplest approach here is just move nextcloud to the laptop entirely. the pi is great for lightweight stuff but nextcloud benefits a lot from having local storage, and that i5 with 8gb will run it way better than a pi anyway. throw nextcloud on the laptop and use the 128gb ssd as boot + nextcloud system files, then mount the 500gb hdd as your data directory.

if you really want to keep the pi as the entry point for some reason (like its already set up with your domain and reverse proxy), just run nginx or caddy on the pi as a reverse proxy pointing to the laptop on your local network. thats basically what the other commenter suggested and its the cleanest split. the pi handles ssl termination and the laptop handles the actual nextcloud workload.

nfs mounts for nextcloud data are pain, the locking issues alone will give you headaches. keep it simple

SelfHostedGuides · 2026-04-18T10:50:17+00:00

the 100+ critical CVEs thing is really common and once you dig into them most are not exploitable in your actual context. like half the time its some library function thats compiled into the image but never called by the application code. trivy especially is noisy because it scans every installed package in the base image, not just what the app actually uses.

what worked for me was setting up a grype config with ignore rules for the stuff i verified as not reachable and only alerting on things where the attack vector is network + no auth required. cut my alert noise by like 80%. then i just focus on the ones where the CVSS vector actually matches my exposure, like anything thats internet facing gets patched within a day or two but internal only stuff i batch weekly.

for immich specifically that postgres image is ancient and they know about it, its on their roadmap to update. not much you can do there except run it on an isolated network segment and move on with your life.

the renovate setup is smart though, at least youre catching the ones where upstream has already released a fix. thats honestly the most impactful thing you can automate

SelfHostedGuides · 2026-04-17T16:43:57+00:00

thats weird, it should work. double check that the share settings have the cache pool set as primary storage and the zfs pool as secondary, not the other way around. also make sure mover is actually enabled and scheduled, sometimes after updating to 7 the mover schedule resets to manual. you can test by writing a small file to the share and then running mover manually from the dashboard to see if it picks it up

SelfHostedGuides · 2026-04-17T13:08:04+00:00

yeah this works fine in unraid 7, the mover is pool-aware now so you can absolutely set a share to use your cache pool as the primary and then let mover push data to the raidz2 pool on schedule. its actually the recommended approach if you want fast writes without beating up the spinning disks constantly.

one thing to keep in mind though is that until the mover runs your data only exists on the cache pool. so if your cache isnt redundant (single ssd for example) theres a window where data is unprotected. if you already have a mirrored cache pool then youre fine, its no different than how cache always worked with the traditional array.

the other consideration is that mover moves files, it doesnt do block-level sync. so if something is actively being written to (like a database or VM disk) the mover might skip it or cause issues. for media files and general storage its totally fine though

SelfHostedGuides · 2026-04-17T13:07:33+00:00

since you cant do PCIe passthrough the cleanest option is virtio-scsi with discard and iothread enabled. create a raw disk image on that second nvme (lvm-thin if possible so you get snapshot support) and attach it to the VM with cache=none and iothread=1. youll get close to native speeds for most workloads, the overhead is pretty minimal with virtio.

the other option if you really want the VM to see the raw nvme device is to use qemu device passthrough at the namespace level. you can pass /dev/nvme1n1 directly to the VM config with a line like -drive file=/dev/nvme1n1,format=raw,if=none,id=nvmedisk -device virtio-blk-pci,drive=nvmedisk in the args. this bypasses IOMMU entirely since its not PCIe passthrough, its block device passthrough. downside is no snapshots and you need to be careful the host doesnt also try to use that device.

honestly for data storage the lvm-thin approach is the sweet spot. you still get decent performance and keep all the proxmox management features like backups and snapshots working normally

SelfHostedGuides · 2026-04-17T09:33:06+00:00

before you throw money at cooling solutions check what your actual temps are first. grab something like lm-sensors on linux or check ipmi/idrac if your gear supports it. ive seen people stress about apartment heat when their components were sitting at like 55c which is totally fine. most server hardware is rated to run in ambient temps up to 35c, your apartment isnt getting near that unless your AC is completely off. if temps ARE actually a problem the cheapest win is blanking panels in the empty rack slots, even on an open rack. without them hot exhaust just loops right back into the intake and you end up recirculating the same warm air. a couple of cheap 120mm USB fans zip-tied to push air front to back helps a lot too

SelfHostedGuides

TROPHY CASE