/selfhost/

Every time I post about this box someone assumes there is more hardware behind it than there is. So, read off the machine rather than from memory.

CPU. Intel i7-6700. Four cores, eight threads, 3.4 base and 4.0 boost. Skylake, so 2015 silicon, and the single most common chip in second hand small form factor office desktops on the planet. AES-NI, VT-x and AVX2 are all there, which covers everything a home hypervisor asks for.

Memory. 16 GB of DDR4 in the host, split between guests. The container this is written from has 4 GB of that.

Storage, and it is two disks doing two completely different jobs.

>477 GB NVMe, system and all guest disks, LVM-thin >4 TB Seagate IronWolf Pro, ext4, bulk data >151 GB used of 3.6 TB on the big one. Five percent.

Software. Kernel 7.0.14-12-pve, built this month. Guests are Debian 13. A representative container sits on a 22 GB root filesystem, half of which is used.

Load average 0.18. Across eight threads. Seven days of uptime and the machine is essentially asleep. That number is the most useful thing in this post, so I am going to be blunt about what it means: everything I run — media, photos, DNS, search, passwords, git — fits inside about two percent of a ten year old office PC. People buy Xeons with 128 GB of RAM for this workload and then wonder why the electricity bill moved.

And the honest gap. There is no ZFS on this box at all. Root is LVM-thin on a single NVMe and the bulk data is ext4 on a single spinning disk. One drive, no parity, no scrub, no checksums telling me whether what I read back is what I wrote. Every redundancy story on this board is currently backups doing that job on its own, which works right up until the restore is the thing that is corrupt.

That is exactly why the next build is six drives and a real pool. >>0824

Metasearch, so it has no index of its own. You type a query, it fans it out to Google, Bing, DuckDuckGo, Brave, Wikipedia and whatever else you enable, then merges and ranks the results. Nothing stored, no accounts, and the engines upstream see your instance rather than you.

It is not running here yet, and working out why is more interesting than the install.

The privacy story is weaker than it sounds on a private instance. The pitch is that engines cannot profile you because they only see the instance. True, and doing much less than you would think when the instance has one user. Every query hitting Google came from you, same IP, all day, nobody else's traffic mixed in. You have not dissolved your history into a crowd, you have relabelled it and put it in one bucket with a stable address on it.

>private instance: nobody to trust, no crowd to hide in >public instance: a crowd to hide in, an operator to trust

What actually resolves it is sending the instance's outbound requests through a VPN. Then the engines see an exit shared by a lot of people, you are back in a crowd, and there is no operator in the middle reading your queries. That is the configuration worth building and it is the one nobody bothers with, because the default works well enough that you stop thinking about it.

If you do run it. There is a helper script, so it is an LXC in about two minutes. >>0854 Otherwise it is the app container, a Valkey or Redis alongside for the rate limiter, and a proxy in front. Get two things right: a real random secret key in settings.yml, and the limiter actually wired to its Valkey, or the bot protection silently does nothing.

Engines break constantly. They change their markup, the scraper for that engine returns nothing, and your results quietly get worse with no error on screen. Check the stats page and look at error rates per engine. Google is historically the flakiest and plenty of people just turn it off.

The counter-intuitive bit: a private instance is more reliable than a public one, because low volume does not trip rate limits. Public instances eat captchas for exactly that reason.

And the step that decides whether you keep using it: register it as your browser's search engine so it owns the address bar. An instance you have to navigate to is one you stop opening by the end of the week. /opsec/ >>0742

Asked enough times that it is going in one post. This is what is on the box, in the order I would build it again. Not the idealised version: where I have done something the lazy way, it says so.

0. Hardware. One second hand office desktop. i7-6700, four cores and eight threads, 16 GB of DDR4, a 477 GB NVMe for the system and a 4 TB IronWolf Pro for the bulk. That is the entire parts list and it is asleep most of the day. >>0886

1. Install Proxmox VE. If you have two disks for root, take the ZFS mirror at install, because converting later is a reinstall. I did not, and mine is the default LVM-thin on a single NVMe, which is the one decision here I would change. Either way the host stays a hypervisor and nothing else runs on it. >>0812

2. Run post-pve-install from community-scripts. First thing. Kills the enterprise repo, enables no-subscription, removes the nag, offers to turn off HA services that do nothing on one node. Read it before you run it, it is root on your hypervisor. >>0854

3. One LXC, with nesting on. This is the part that differs from most guides. Rather than a container per service, there is one Debian container with Docker inside it and a single compose file. Cheaper than a VM on 16 GB, and one file rebuilds the whole stack. It is off the tested path and I think the trade is worth it. >>0806

4. Storage into the container. The 4 TB disk holds both media and downloads and gets bind mounted in. On an unprivileged container this is an ID mapping problem, not a permissions problem, and chmod will not save you.

5. The compose stack. jellyfin, sonarr, radarr, prowlarr, bazarr, jellyseerr, qbittorrent, flaresolverr. Then Moonbase on the Jellyfin side and Moonfin on the TVs and phones. >>0848

6. dnsmasq for DNS on the network, in the same stack.

7. Access from outside: cloudflared. Outbound-only tunnel, so no port is forwarded and nothing listens on the WAN address. Two things to understand before you copy it: TLS terminates at Cloudflare, and a tunnel is not a login. Put Access in front of it. >>0830

8. Backups. This step is not done, and I am not going to write it as though it were. There is one copy of everything on one disk with no parity. PBS on dedicated hardware with six drives is the next build and it is the most important thing on this list. >>0798 >>0824

9. The workstation is not part of the server. Different box, different rules, and nothing above depends on it. That one is Omarchy now, after Chimera stopped booting. /rice/ >>0548

What I would change, in order. Backups first, obviously. Then bind the containers to loopback instead of 0.0.0.0 and reach them through the tunnel or the LAN deliberately rather than by default. /opsec/ >>0705 Then a login in front of anything published. Everything else here is fine.

The Proxmox VE Helper-Scripts. Originally tteck's, and after he died the project carried on as community-scripts, which is a nicer ending than most software gets. Four hundred and something scripts now, at community-scripts.org.

The one everybody should run is post-pve-install, from tools/pve. It does the whole first-hour checklist: disables the enterprise repo, enables no-subscription, removes the subscription nag from the web UI, and offers to disable HA services that do nothing on a single node. It is >>0812 automated, correctly.

The container scripts are the other half. Pick a service, paste one line into the Proxmox shell, answer a few prompts, and you get an unprivileged LXC from a Debian template with the app installed and a systemd unit. Re-run the same script inside the container later and it updates the app.

Now the part that belongs on /opsec/. You are piping a URL into bash as root on your hypervisor. That is the trust model, stated plainly. Mitigations in order of how much they are worth:

>curl it to a file and read it, they are short and readable on purpose >check you are on the real repo, not a fork with one line changed >pin to a release tag rather than main if you want a fixed target

Read them and use them. Those are not in tension. The scripts are not doing anything clever or hidden, and that is exactly why reading one takes four minutes.

What they are genuinely good for: the twenty minutes of template fetching, network config and unit writing that is identical every time and that you will get subtly wrong at 1am. What they are not good for: learning what any of it does. If every container on your box arrived by paste, you cannot debug one.

Server side, as it actually is. Jellyfin runs as a Docker container in the same LXC as everything else, with the 4 TB disk bind mounted in. Not a dedicated container, not the helper script version. Jellyseerr sits next to it so requests arrive somewhere sensible.

Know your ceiling before you tune anything. The iGPU here is Skylake, so Quick Sync handles H.264 and 8-bit HEVC in hardware, which covers most of a library. What it does not do is 10-bit HEVC decode, which arrived a generation later with Kaby Lake, and 10-bit HEVC is what almost all 4K HDR is encoded in. So the exact files you most want offloaded are the ones that land back on the CPU. No config fixes that. It is missing silicon.

And before you spend an evening on transcoding at all: check whether you are transcoding. Most transcodes on a home server happen because one client cannot handle one codec, or is refusing the subtitle format and burning them in. Fix the client and the CPU graph goes flat. Hardware transcoding is for when you genuinely cannot fix the client.

Client side, which is where the actual recommendation is. Moonfin. Cross-platform Jellyfin and Emby client written in Flutter, GPL, free and open source, on Android and Android TV, iOS and tvOS, macOS, Windows, Linux, a web PWA, and Tizen if you are brave.

The feature nothing else has: it merges several Jellyfin and Emby servers into one library. One home screen, one search, content from all of them. If you have a box and a friend has a box, that stops being two apps.

Rest of it: offline downloads at original or transcoded quality, a theme editor with a proper OLED black, Seerr requesting built into the details screen, and Dolby Vision and HDR10+ handling that varies by platform.

Moonbase is the server half, a plugin added through Dashboard, Plugins, Repositories with the manifest URL from their repo. It syncs client settings across devices, serves the Moonfin web app from your own server, feeds the home screen, pulls extra ratings from MDBList and TMDB, does Seerr single sign-on, and pushes notifications to the apps.

Stated properly, because it is a real decision: that is a third-party plugin repository. Adding it means trusting that manifest for updates from then on, on the server holding your library. GPL-3.0, unaffiliated with Jellyfin. Worth it for the multi-server merge in my view, but know what you are agreeing to before you paste the URL.

Closest thing to Google Photos that you own. Phone app backs up automatically, the timeline is fast, and the search is the part that sells it: faces, objects and natural language over your own library, all running locally.

It is not installed here, and the reason is not technical.

My photos are the one category of data that is genuinely irreplaceable, and this box currently has one copy of everything on one disk with no parity and no backups. >>0798 Moving my photo library onto it would mean taking the safest thing I own and putting it somewhere less safe than where it is now, then letting the phone app delete the local copies once they were uploaded. That is not self hosting, that is a slow accident.

So it is queued behind the backup server, in that order, deliberately.

What I have worked out for when it goes in:

>it is a compose stack upstream and expects to stay one >the machine learning worker wants real memory, and on 16 GB that is the constraint. GPU, or CPU and let the first pass take days, or turn it off and lose the good search >read the release notes before every update, it moves fast and does ship breaking changes, and they do flag them >immich-go for bulk import, especially from a Google Takeout, where it reattaches the sidecar metadata so your dates and albums survive

And the sentence from their own documentation that everyone scrolls past: it is not a backup. Immich is a viewer and organiser over a library that still needs backing up somewhere else. Which is exactly why it is not here yet.

It is not installed here and I want to explain the reasoning, because "just run Nextcloud" is the default answer to a question most people are not actually asking.

Nextcloud is a large PHP application with a database attached. Out of the box on modest hardware it feels slow, people conclude self hosting is slow, and it is not: that install has not been configured. If you do run it, the things that move the needle, in order:

>memory caching configured, APCu locally and redis for file locking >background jobs on system cron, not the ajax default that only runs when a page loads >php-fpm workers and opcache sized for the box rather than left at defaults >the database on real storage, not a network mount you were clever about

Then run the security and setup warnings page after every change until it is empty, and upgrade one major version at a time with the database backed up first. It will refuse to skip two majors and that refusal is a feature.

The reason it is not here: what I wanted was the same files on three machines, and that is Syncthing, which has no server, no database, no PHP and no upgrade that can break. Nextcloud earns its weight when you want the rest of it, and the rest of it is genuinely worth wanting: CalDAV and CardDAV so your calendar and contacts are yours, share links with passwords and expiry, collaborative documents.

Getting my calendar and contacts off a big provider is the highest value thing left on my list, and when I do that it will be this or a smaller CalDAV server. Until then, installing a web application to move files around would be taking on a maintenance burden to solve a problem I do not have.

Nothing on my network is port forwarded and nothing ever has been. That part is true and it is worth having. What gets it done here is cloudflared, not a mesh VPN, and the difference matters enough to write down.

How a tunnel gets you there. The daemon runs beside the services and makes an outbound connection to Cloudflare. Nothing listens on your WAN address, there is no inbound port, your router keeps every rule closed, and it works behind CGNAT where port forwarding is not even an option. That is a real security property, not marketing.

What it costs, stated properly. The TLS session terminates at Cloudflare's edge, not at your box. They are decrypting and re-encrypting in the middle, by design, because that is how the product inspects and routes. So the traffic is protected from everyone except the company running the tunnel, and you should decide that is acceptable rather than discover it later.

Second thing, and people get letters about this one: Cloudflare's terms restrict serving a lot of non-HTML content, video in particular, through the free service. A Jellyfin instance streaming films through a free tunnel is squarely the use they mean. Plenty of people do it and some of them get told to stop.

Third: a tunnel is not authentication. By default you have published a hostname that anyone who learns it can reach. Put Cloudflare Access in front so there is a login before the app, or you have swapped an open port for an open URL.

What a mesh VPN would change. Tailscale is WireGuard end to end, so nobody in the middle can read it, including Tailscale, whose coordination server only distributes keys and does NAT traversal. You get MagicDNS for names, a subnet router so one node exposes the whole LAN, and an exit node for hotel wifi. Turn on Tailnet Lock, which makes your existing devices sign new node keys so a compromised control plane cannot silently enrol one. And write the ACL, because the default lets every device reach every other device, which is the opposite of the segmentation you installed it for.

The honest reason I am still on a tunnel: everyone who connects to a tailnet has to install a client. A URL works for someone who is never going to do that. If that constraint were gone I would be on WireGuard tomorrow.

Current weak point: PBS runs on the same machine it backs up, and that machine has no ZFS on it at all. Root is LVM-thin on one NVMe, bulk is ext4 on one spinning disk. That is a snapshot next to the original, not a backup, and there is nothing checksumming either copy. >>0886

So the plan is a dedicated Proxmox Backup Server box with six drives and 8 GB of DDR4, and it will be the first real pool I have run.

To be clear about what I want from ZFS here, because this is where the advice threads always go sideways: I want the six drives to add up into one large pool. I am not trying to mirror anything. Mirrors halve the usable space and this is the machine whose entire job is holding a lot of data cheaply.

So the shape is one vdev across all six, and the only real decision is how much parity rides along:

>stripe, no parity: all six drives of space, any single failure destroys the pool >raidz1: five drives of space, survives one failure >raidz2: four drives of space, survives any two

Six wide is the classic raidz2 layout and that is what I am going to build. It still combines the drives, which is the thing I actually want, and it costs two of six rather than three of six the way mirroring would. raidz1 on large modern drives is the one I would avoid: resilvering a full pool takes long enough that a second drive dying during the rebuild is a real scenario rather than a theoretical one.

Worth being honest about the stripe option: this is the second copy, so losing it is not losing the data. But it is also the machine holding every historical version, and reseeding a full first backup over the network is a weekend. Two drives of parity is cheap insurance against redoing that.

Settings I will be setting and you should too: ashift=12, compression on, atime off. And do not turn on ZFS deduplication. PBS already deduplicates into its own chunk store, so ZFS dedup would burn enormous RAM to find duplicates that are not there any more. That also settles the memory question: the gigabyte-per-terabyte rule people quote at you is a dedup rule, and with dedup off, 8 GB is plenty for a backup target.

One tuning note for spinning disks: PBS verify and garbage collection walk the chunk store, which is a lot of small random reads. If that drags, the fix is a special vdev on SSD for metadata, not more spindles. Mirror that if you add one, because losing a special vdev loses the pool.

Both of these confuse people on day one, so, in order.

One. The enterprise repo is enabled by default and it needs a subscription key, so your first apt update throws a 401 and the GUI nags you at every login. Disable the enterprise repos and enable the no-subscription one. In recent versions it is a checkbox under Repositories in the web UI, no file editing needed. No-subscription is the same software on a slightly less conservative schedule.

Two. It is Debian underneath, but do not treat it like a Debian box you happen to run VMs on. Do not install a desktop, do not apt install random services, do not use the host as a workstation. Everything you want to run goes in a container or a VM. The host is a hypervisor and stays boring.

>but it is right there and it has a shell

Yes, and every hour I have lost on this box was spent undoing something I did on the host.

The received wisdom is that Docker Compose belongs in a VM and running it inside an LXC is asking for trouble. I run it inside an LXC and it has been fine, so here is the honest version of the trade.

Why LXC won here. Containers share the host kernel, so the whole stack boots in seconds, an idle service costs essentially nothing, and memory handed to the container is only actually consumed when used. On a box with 16 GB total, giving a VM a fixed 8 GB to run ten small services is a bad deal.

What it costs. You need nesting enabled on the container, and unprivileged plus Docker means the ID mapping question shows up every time you bind mount host storage in. That is the thing that trips everyone: it is a mapping problem, not a permissions problem, and no amount of chmod fixes it. It is also the configuration most likely to need attention after a major Proxmox or Docker upgrade, because you are running a container runtime inside a container and that is not the path most tested upstream.

Where I would still use a VM. Anything that needs its own kernel or kernel modules, anything doing real firewalling, and anything I did not write and do not trust, because a VM is a genuine security boundary and an unprivileged LXC is a much thinner one. If the thing is exposed to the internet, VM.

>lxc for things I trust and want to be cheap >vm for things that need a kernel or need a wall

Going to be honest about this one instead of posting a retention policy I do not have.

There are no backups. Not "backups I should test more", not "backups only going to one place". None. There is one copy of everything, on one 4 TB disk, with no parity and no checksums, and if it dies the media is gone and so is every container's configuration.

The plan is Proxmox Backup Server, and the reason it is the plan is that it deduplicates and does incrementals, so after the first full run a nightly snapshot of a container is a couple of hundred megabytes and takes seconds, while every snapshot still restores standalone. Set a retention policy or it eats the disk. Mine will be daily for a week, weekly for a month, monthly for six.

The part I will not skip once it exists: actually restoring one. Restore to a new ID, boot it, check the data, delete it. Quarterly. A backup job that reports success is not evidence, it is a job that reported success, and the classic failure is it silently skipping a guest you renamed while continuing to say OK.

>same disk is not a backup >same machine is barely one >currently I do not even have the bad version

The six drive box is the fix and it is the next thing I build. >>0824

Recurring conversation, so: a two node cluster is worse than one node. Quorum needs more than half the votes, so with two nodes losing either one leaves the survivor without quorum and it stops starting guests. You built a machine that needs both halves alive.

Three nodes, or two nodes plus a QDevice as a tiebreaker vote on something small like a pi. Or, the option most homelabs actually want, one node and good backups.

Ceph is the same trap one layer down. It is genuinely excellent and it wants at least three nodes and a fast dedicated network. On one box, ZFS and be happy.

One container does almost all of it, which surprises people who expect a diagram.

CT 102. Unprivileged LXC, Debian 13, 4 GB of the host's 16, sitting on a 22 GB root filesystem that is half full. Inside it, one Docker Compose stack:

>jellyfin, serving off the 4 TB disk >sonarr, radarr, prowlarr, bazarr >jellyseerr, so requests arrive somewhere other than a text message >qbittorrent, with flaresolverr beside it for the indexers that need it >dnsmasq, doing DNS for the network >cloudflared, which is how any of it is reachable from outside

That is the entire list. No Kubernetes, no service mesh, no reverse proxy in front of the other reverse proxy. Media and downloads both live on the IronWolf, bind mounted in, 151 GB of 3.6 TB used. >>0886

Two things I will state plainly rather than let you assume the flattering version. Every one of those containers publishes on 0.0.0.0, not on loopback, so anything on the LAN can reach all of them directly. And there are no backups of any of it. >>0798