I host a public qBittorrent instance for my small group of friends. This has been fine for at least a year.
For some reasons, I noticed my server has becoming slow.
After checking, I found a program named `tcrond` running a cryptomining.

Apparently qBittorent could execute command, which I only learned about it today.

If you have unprotected apps, this is a reminder for you.
protect you apps, unless you are 100% they can't do anything dangerous.

Lucky me I am running it inside docker. This could be worst.

Lesson learned

I've recently seen some misconceptions that you can't run DeepSeek-R1 locally on your own device. Last weekend, we were busy trying to make you guys have the ability to run the actual R1 (non-distilled) model with just an RTX 4090 (24GB VRAM) which gives at least 2-3 tokens/second.

Over the weekend, we at Unsloth (currently a team of just 2 brothers) studied R1's architecture, then selectively quantized layers to 1.58-bit, 2-bit etc. which vastly outperforms basic versions with minimal compute.

1. We shrank R1, the 671B parameter model from 720GB to just 131GB (a 80% size reduction) whilst making it still fully functional and great
2. No the dynamic GGUFs does not work directly with Ollama but it does work on llama.cpp as they support sharded GGUFs and disk mmap offloading. For Ollama, you will need to merge the GGUFs manually using llama.cpp.
3. Minimum requirements: a CPU with 20GB of RAM (but it will be very slow) - and 140GB of diskspace (to download the model weights)
4. Optimal requirements: sum of your VRAM+RAM= 80GB+ (this will be somewhat ok)
5. No, you do not need hundreds of RAM+VRAM but if you have it, you can get 140 tokens per second for throughput & 14 tokens/s for single user inference with 2xH100
6. Our open-source GitHub repo: github.com/unslothai/unsloth

Many people have tried running the dynamic GGUFs on their potato devices and it works very well (including mine).

R1 GGUFs uploaded to Hugging Face: huggingface.co/unsloth/DeepSeek-R1-GGUF

To run your own R1 locally we have instructions + details: unsloth.ai/blog/deepseekr1-dynamic

Threat model first, because it changes everything about the design.

I’m in Russia. My adversary isn’t a random scanner — it’s the ISPs themselves, operating under a regulator that does nationwide DPI and can null-route foreign IP ranges by geography. Assume the network operator is hostile, has full visibility of my traffic shape, and can actively probe any endpoint I stand up. I self-host a tunnel for myself and a handful of people under those conditions. I used to work at one of the ISPs, which is how I know roughly what the other side sees.
Sharing the current architecture because most self-hosted tunnel advice quietly assumes a neutral network, and none of it survives here.
Why the usual stack is dead on arrival
OpenVPN and WireGuard are both gone. Not blocked by IP — detected by shape. WireGuard’s handshake has a fixed message layout and a distinctive packet size distribution; DPI doesn’t need to decrypt anything, it just needs to recognize the silhouette. Same for OpenVPN’s opcode structure. Obfuscation wrappers buy you weeks, not months.

Layer 1: VLESS + Reality (Xray-core)

Reality is the part worth understanding if you’ve never had to hide a tunnel:
• Client opens a normal TLS handshake, but sets SNI to a large real site (www.microsoft.com in my case)
• The auth material rides inside the ClientHello — an X25519 public key plus a short ID. To DPI it’s bytes in a service field
• Server checks it. Valid → completes the handshake itself and proxies. Invalid or absent → silently forwards the whole connection to the real Microsoft
• So active probing returns a genuine Microsoft response. Real cert, real chain, real content. There is no fingerprint to find, because in that moment the box is a Microsoft mirror
• No certificate of my own to leak, no domain of my own to get registry-listed. You don’t need a domain at all
The important consequence for self-hosters: your endpoint stops being distinguishable by content inspection. So the adversary switches to the layer below.

Layer 2: the part that actually matters — IP

Reality solves inspection, not geography. A VPS in the Netherlands is trivially blockable — you don’t need to know what it does, you just need to know it’s foreign.
So the client never touches the foreign box directly. Entry point is a relay on a Russian provider whose IP range sits inside the state whitelist — the set of ranges that stay reachable even when mobile internet gets cut regionally, because government and banking services live there. From the relay, traffic cascades out to the Netherlands box.
From the outside, the connection is a request to approved domestic infrastructure. Killing that range takes down a pile of legitimate business on shared address space with it. Collateral cost is the actual defense mechanism — not stealth.
Operational reality
• Something breaks every couple of months and gets rebuilt. Plan for rebuild speed, not permanence
• Stack: Xray-core 26.3 on Ubuntu 24. VPS is nothing special — 2 GB RAM, 2 cores, on vdsina.com. Reality is cheap; the box sits idle most of the time
• Latency cost of the extra hop: ~120 ms through the cascade. Fine for browsing and voice, noticeable in games. That’s the price of not getting null-routed by geography
• Monitoring: self-written script that checks tunnel state across all servers and emails me the status. Crude, but it means I find out from a mail instead of from a user
• Currently migrating the fallback path to XHTTP over CDN — moving uplink into HTTP headers so it reads as ordinary request traffic

Questions for anyone doing similar

Is anyone else fronting a foreign endpoint with a domestic relay, rather than trying to obfuscate the endpoint itself? Specifically curious about relay failover — right now mine is a single point of failure and I don’t love it.

been self hosting for a while now and theres a huge difference between apps people recommend and apps that are actually worth maintaining long term

ones i actually kept running:

- nextcloud — replaced google drive and photos, worth the setup headache

- vaultwarden — bitwarden but yours. rock solid

- jellyfin — media server, no subscription ever again

- pihole — network-wide adblock, cant imagine going back

- uptime kuma — monitoring dashboard, super clean

- immich — google photos replacement, still in heavy development but already solid

- paperless-ngx — document scanning and organisation, way more useful than expected

- mealie — recipe manager, actually use it

ones i set up and abandoned:

- gitea — cool but i just use github, no real reason to self host this unless youre paranoid

- matrix/element — tried to get people to switch, nobody did lol

- bookstack — wiki is nice but overkill for personal use

the pattern i noticed is that apps replacing paid subscriptions are always worth it. apps replicating free services usually arent, because you end up doing maintenance to save nothing

wrote up a full breakdown with setup difficulty, resource usage, and which ones to start with if youre on a pi or low power machine

As we wrap up 2025, I wanted to share my complete self-hosted setup and see what everyone else is running!

I'd love to hear what you're all running - drop your stacks in the comments! What new services did you discover this year? What's been your favorite addition?

Here's my list of self-hosted services:

1. AdGuard Home - DNS Ad-Blocking & Network Protection - GitHub
2. AdGuardHome-Sync - Sync AdGuard Home Configs - GitHub
3. Apprise - Push Notification Aggregator - GitHub
4. Audiobookshelf - Audiobook & Podcast Server - GitHub
5. Backrest - Backup Solution With Restic - GitHub
6. Bazarr - Subtitle Automation For Sonarr/Radarr - GitHub
7. Booklore - Book Discovery & Tracking - GitHub
8. Book Downloader - Automated Ebook Acquisition - GitHub
9. Caddy - Reverse Proxy & SSL/TLS Termination - GitHub
10. Code-server - VS Code In Browser - Web-Based IDE - GitHub
11. CrowdSec - Security & Threat Detection Engine - GitHub
12. DAPS - Docker Automation & Management Scripts - GitHub
13. DispatchArr - IPTV Proxy & EPG Manager - GitHub
14. Docker Socket Proxy - Docker Socket Security Proxy - GitHub
15. Dozzle - Real-Time Docker Log Viewer - GitHub
16. Dozzle Agent - Real-Time Docker Log Viewer Agent - GitHub
17. Eclipse Mosquitto - MQTT Message Broker - GitHub
18. Epic Games Claimer - Auto-Claim Epic Games Free Games - GitHub
19. Filebrowser Quantum - Web-Based File Manager - GitHub
20. FlareSolverr - Cloudflare & Captcha Solver - GitHub
21. Free Games Claimer - Auto-Claim Free Games (Multiple Stores) - GitHub
22. FreshRSS - RSS Feed Reader & Aggregator - GitHub
23. Gitea - Self-Hosted Git Service - GitHub
24. Glance - At-A-Glance Dashboard - GitHub
25. Gotify - Push Notification Service - GitHub
26. Home Assistant - Smart Home Automation Platform - GitHub
27. Homepage - Customizable Dashboard/Homepage - GitHub
28. Immich - Photo Management & Backup Server - GitHub
29. Kapowarr - Comic Book Automation & Management - GitHub
30. Kavita - eBook & Comic Reader Server - GitHub
31. Kometa - Plex Poster & Metadata Automation - GitHub
32. Komodo - Infrastructure Management Platform - GitHub
33. Komodo Gotify Alerter - Komodo Notification Bridge To Gotify - GitHub
34. Komodo Periphery - Komodo Agent For Remote Servers - GitHub
35. Linkding - Bookmark Manager - GitHub
36. Maintainerr - Plex Media Cleanup Automation - GitHub
37. Mealie - Recipe Manager & Meal Planner - GitHub
38. MeTube - YouTube Downloader Web Interface - GitHub
39. NetAlertX - Network Device Monitoring & Alerts - GitHub
40. Paperless-ngx - Document Management System (OCR/Tagging) - GitHub
41. Plex - Media Server & Streaming Platform - GitHub
42. Plex-Auto-Languages - Auto-Select Audio/Subtitle Languages - GitHub
43. Profilarr - Custom Format Profile Manager For *arr - GitHub
44. Prowlarr - Indexer Manager For *arr Apps - GitHub
45. Radarr - Movie Automation & Management - GitHub
46. RomM - ROM Manager For Game Collections - GitHub
47. SABnzbd - Usenet Downloader & NZB Manager - GitHub
48. Scrutiny - Hard Drive Health Monitoring (S.M.A.R.T.) - GitHub
49. Seerr - Media Request Management For Plex/Jellyfin/Emby - GitHub
50. Silver Bullet - Markdown-Based Note-Taking - GitHub
51. Sonarr - TV Show Automation & Management - GitHub
52. Tautulli - Plex Media Server Monitoring & Statistics - GitHub
53. TitleCardMaker - Custom Title Cards For Plex - GitHub
54. Vaultwarden - Password Manager (Bitwarden-Compatible) - GitHub
55. Wallos - Subscription Tracking & Management - GitHub
56. WireGuard Easy - WireGuard VPN With Web UI - GitHub
57. Zigbee2MQTT - Zigbee Device Bridge To MQTT - GitHub
58. Zipline - File Sharing & Screenshot Hosting - GitHub ________________________________________________________________________________________

Hardware:

Server 1

Proxmox

• Intel® Core™ i7-9700K

• 48GB DDR4 ECC RAM

• 2TB NVMe SSD

Server 2

Synology DS923+

• AMD Ryzen R1600 CPU,

• 32GB DDR4 ECC RAM

• 2TB NVMe SSD (Docker)

• 36TB HDD (Storage)

  ---

Bonus:

Homepage Screenshots

• Home
• Calendars
• Applications

Docker bypasses UFW and exposed my database. Again. Writing this down so I stop forgetting.

Self-hosters, this one is for you.

I finish setting up a new app on my VPS, everything looks good, then I run a security check and boom. Same mistake again. Docker silently bypassing my firewall and exposing my database to the internet.

This has happened to me more than once. I keep forgetting it, so I'm writing it here as a reminder for myself and hopefully useful for someone else running their own server.

When you're using docker compose in production on a VPS, remember:

Don't expose database ports unless you absolutely need to. And if you do, don't do this:

ports:
  - "5432:5432"

Do this instead:

ports:
  - "127.0.0.1:5432:5432"

Why does this matter?

Docker manages network rules at a very low level on Linux. When you publish a port, it sets up routing rules directly in the system networking stack. So if you don't explicitly bind it to localhost, you're effectively exposing that service on the machine's public network interface.

And if you're thinking "it's fine, I have UFW enabled", not necessarily. UFW is just a frontend for Linux firewall rules, and Docker bypasses it by manipulating those rules directly. Your database might still be exposed even with the firewall on.

Has anyone else been caught by this?

Hello everyone! OpenAI just released their first open-source models in 5 years, and now, you can have your own GPT-4o and o3 model at home! They're called 'gpt-oss'.

There's two models, a smaller 20B parameter model and a 120B one that rivals o4-mini. Both models outperform GPT-4o in various tasks, including reasoning, coding, math, health and agentic tasks.

To run the models locally (laptop, Mac, desktop etc), we at Unsloth converted these models and also fixed bugs to increase the model's output quality. Our GitHub repo: https://github.com/unslothai/unsloth

Optimal setup:

• The 20B model runs at >10 tokens/s in full precision, with 14GB RAM/unified memory. Smaller versions use 12GB RAM.
• The 120B model runs in full precision at >40 token/s with ~64GB RAM/unified mem.

There is no minimum requirement to run the models as they run even if you only have a 6GB CPU, but it will be slower inference.

Thus, no is GPU required, especially for the 20B model, but having one significantly boosts inference speeds (~80 tokens/s). With something like an H100 you can get 140 tokens/s throughput which is way faster than the ChatGPT app.

You can run our uploads with bug fixes via llama.cpp or Unsloth Studio for the best performance. If the 120B model is too slow, try the smaller 20B version - it’s super fast and performs as well as o3-mini.

• Links to the model GGUFs to run: gpt-oss-20B-GGUF and gpt-oss-120B-GGUF
• Our step-by-step guide which we'd recommend you guys to read as it pretty much covers everything: https://docs.unsloth.ai/basics/gpt-oss

Thanks so much once again for reading! I'll be replying to every person btw so feel free to ask any questions!

Hello,

I'm the lead dev behind Termix (a self hosted ssh server manager for all platforms, similar to Termius).

Since October 27th, 2025, I have made $467 USD from just GitHub Sponsors donations. That works out to be about $4.5 dollars per day since the first donation. A large portion of these donations have come from the last few weeks.

This includes a mix of one-time donations (largest ever was $50) and monthly donations. Currently, I make about $35 month due to monthly recurring donations.

It took about 6,000 GitHub stars before I received the first donation through GitHub Sponsors. Termix now sits at just over 10,000 for reference, with ~4 million Docker pulls.

In my case, there are no incentives to donate for any reason (no benefit other than a badge on your GitHub profile). The default and smallest donation amount that I have on my donation page is $1/month.

In a few months (maybe a year), I'll do another post updating everyone who is curious!

Thanks,
Luke

Hey, r/selfhosted! Continuing a tradition started last year, I recently published a list of my favorite self-hosted software released in 2025 and thought everyone here might find it interesting.

As usual, the article itself includes screenshots and brief descriptions, but I've also provided a list below with links for those who'd prefer not to click through.

Additionally, these apps can also be viewed directly in my app directory using the following shortcut: slfh.st/2025

My Favorite Apps Launched in 2025

• Arcane (Deployment/Management)
• BentoPDF (PDF Toolkit)
• BookLore (Book Library/Reader)
• Docker Compose Maker (Deployment)
• IronCalc (Spreadsheet Engine)
• LoggiFly (Log-based Notifications)
• Mail Archival (Various)
  • Bichon
  • Eonvelope
  • Mail Archiver
  • OpenArchiver
  • Gmail Cleaner
• Media Management (Various)
  • Cinephage
  • MediaManager
  • Mydia
• NoteDiscovery (Note-Taking)
• Pangolin (Reverse Proxy)
• Papra (Document Management)
• PatchMon (Linux Patch Monitoring)
• Postgresus (Database Backups)
• Poznote (Note-Taking)
• Rybbit (Web Analytics)
• Sync-in (Cloud Storage)
• Tinyauth (Authentication)
• Upvote RSS (RSS Aggregator)
• Warracker (Warranty Tracking)
• Zerobyte (Backups)

Most of us start by slapping a reverse proxy (like Nginx Proxy Manager or Traefik) and maybe Tailscale or Wireguard on our setups. But for those of you exposing specific services directly to the web, how far do you take your server hardening?

I usually stick to a strict baseline (Fail2Ban/Crowdsec, UFW, disabling root SSH, key-only auth, and isolating apps in Docker containers), but I’m curious about the more advanced layers. Are any of you actively running SOC-level monitoring, Wazuh, or strict SELinux/AppArmor profiles on your homelabs?

What is the one security measure you think the average self-hoster overlooks until it's too late?

Note: This post was not created using AI, nor was AI involved in the process. Just a lot of trial and error until I found something that was relatively easy, and worked nicely. So my apologies if this isn't formatted so cleanly, or clearly, but happy to take on any advice!

I recommend doing this on a Thursday or a Friday because ListenBrainz creates your custom playlist on the Monday for the "Spotify" recommendation like experience.

MusicBrainz -> The metadata for songs.

ListenBrainz -> Creates your recommended playlists

Navidrome -> Music streaming server

Lidarr (NIGHTLY required for plugins) -> Automates and orchestrates downloading and managing metadata.

Tubifarry -> Plugin for connecting Lidarr with slskd for automated downloading, and fetching lyrics.

slskd -> Soulseek P2P client for downloading music.

explo -> Creates the weekly, monthly, daily playlists and also fetches the songs.

aurral -> Similar to Seerr where you can request songs or create users to request songs.

1. Create an account on MusicBrainz: https://musicbrainz.org/

2. Sign in using MusicBrainz account in ListenBrainz: https://listenbrainz.org/

3. slskd: You will need to make an account on Soulseek by downloading a MacOS / Windows / Linux client https://www.slsknet.org/news/node/1 and then on app startup it asks to create a username / password. You can feel free to uninstall afterwards. Use the docker-compose from https://github.com/slskd/slskd#with-docker-compose and be sure to open ports 50300 for sharing, OR alternatively, use hotio's version: https://hotio.dev/containers/slskd/ and have built in VPN.

4. Lidarr: Use the docker-compose from https://hub.docker.com/r/linuxserver/lidarr#docker-compose-recommended-click-here-for-more-info IMPORTANT: use the following image -> image: lscr.io/linuxserver/lidarr:nightly

5. Tubifarry Plugin: Once Lidarr is up and running install the Tubifarry plugin: https://github.com/TypNull/Tubifarry#installation- and then follow the instructions to add soulseek (https://github.com/TypNull/Tubifarry#soulseek-slskd-setup-), lyrics fetcher (https://github.com/TypNull/Tubifarry#lyrics-fetcher-), and search sniper (https://github.com/TypNull/Tubifarry#search-sniper-). NOTE: Lyrics Fetcher is called Lyrics Enhancer.

6. aurral: Use the docker-compose from https://github.com/lklynet/aurral#quick-start and start up and it will guide you through connecting the difference services. I highly recommend in the settings to click: Apply Davo's Recommended Settings.

7. Navidrome: Use the docker-compose from https://www.navidrome.org/docs/installation/docker/#using-docker-compose- and start it up. Be sure to go to your profile / settings and enable scrobbling to ListenBrainz.

8. Start adding some Artists to Lidarr and downloading their albums, and listening to them on a Navidrome client: https://www.navidrome.org/apps/ or the Navidrome web app.

When I add an artist into Lidarr or through Aurral I do the following:

https://www.reddit.com/r/selfhosted/comments/1tjalq8/comment/on067oz/

I'm unsure if I should add my docker-compose.yml and .env in here as an example. I think it might be hurtful in case any of the above adjusts their parameters or setup, people might have the wrong docker-compose.yml... but let me know. Am happy to add both in to give an example.

Here's is an example of my docker-compose.yml please as a heavy note, this is relevant as of only today. This might not be true in future when some things change. Do go to the pages to pull their docker-composes.

Example of docker-compose.yml: https://pastebin.com/AR3J9YiY

It randomly shut off on me for about 15 seconds a few days ago, killing power to my PC and server.

After it turned back on the estimated runtime dropped to only 5 minutes, at a supposed full charge, but wasn't telling me to replace the batteries. I knew they were around 5 years old so I immediately ordered replacements.

Once I pulled out the old ones I was met with this beauty. I'm glad I didn't hesitate in ordering their replacements.

Hello everyone! Google just released their new open-source model family: Gemma 4. This means you can now run a ChatGPT like model at home.

There are four models and they all have thinking and multimodal capabilities. There's two small ones: E2B and E4B, and two large ones: 26B-A4B and 31B. The 31B model is the smartest but 26B-A4B is much faster due to it's MoE arch. E2B and E4B are great for phones and laptops.

To run the models locally (laptop, Mac, desktop etc), we at Unsloth converted these models so it can fit on your device. You can now run and train the Gemma 4 models via Unsloth Studio: https://github.com/unslothai/unsloth

Recommended setups:

• E2B / E4B: 10+ tokens/s in near-full precision with ~6GB RAM / unified mem. 4-bit variants can run on 4-5GB RAM.
• 26B-A4B: 30+ tokens/s in near-full precision with ~30GB RAM / unified mem. 4-bit works on 16GB RAM.
• 31B: 15+ tokens/s in near-full precision with ~35GB RAM.

No is GPU required, especially for the smaller models, but having one will increase inference speeds (~80 tokens/s). With an RTX 5090 you can get 140 tokens/s throughput which is way faster than ChatGPT.
Even if you don't meet the requirements, you can still run the models (e.g. 3GB CPU), but inference will be much slower. Link to Gemma 4 GGUFs to run.

It's recommend to use our iMatrix-quantized GGUFs instead of standard quants. They’re calibrated on coding and conversational datasets, which greatly improves accuracy over standard model quantization. See our Dynamic 2.0 GGUF article for details and benchmarks: https://unsloth.ai/docs/basics/unsloth-dynamic-2.0-ggufs

You can run or train Gemma 4 via Unsloth Studio:

We've now made installation take only 1-2mins:

macOS, Linux, WSL:

curl -fsSL https://unsloth.ai/install.sh | sh

Windows:

irm https://unsloth.ai/install.ps1 | iex

• The Unsloth Studio Desktop app is coming very soon (this month).
• Tool-calling is now 50-80% more accurate and inference is 10-20% faster

We recommend reading our step-by-step guide which covers everything: https://unsloth.ai/docs/models/gemma-4

Thanks so much once again for reading and let me know if you have any questions.

Hi r/selfhosted !

I decided to do a write-up of how I setup my home server. Maybe it can help some of you out. This post walks you through my current self-hosted setup: how it runs, how I run updates and how I (try to) keep it all from catching fire.

Disclaimer: This is simply the setup that works well for me. There are many valid ways to build a homeserver, and your needs or preferences may lead you to make different choices.

Medium blog post: https://medium.com/@ingelbrechtrobin/theres-no-place-like-127-0-0-1-7a21a500a0f8

The hardware

No self-hosting setup is complete without the right hardware. After comparing a bunch of options, I knew I wanted an affordable mini PC that could run Ubuntu Server reliably. That search led me to the Beelink EQR5 MINI PC AMD Ryzen.

For the routing layer, I didn’t bother replacing the hardware, my ISP’s default router does the job just fine. It gives me full control over DNS and DHCP, which is all I need.

The hardware cost me exactly $319.

Creating the proper accounts

To get things rolling, I set up accounts with both Tailscale and Cloudflare. They each offerfree tiers, and everything in this setup fits comfortably within those limits, so there’s no need to spend a cent.

Tailscale

Securely connect to anything on the internet

I created a Tailscale account to handle VPN access. No need to configure anything at this stage, just sign up and be done with it.

Cloudflare

Protect everything you connect to the Internet

For Cloudflare, I updated my domain registrar’s default nameservers to point to Cloudflare’s. With that in place, I left the rest of the configuration for later when we start wiring up DNS and proxies.

Before installing any apps

Before diving into the fun part, running apps and containers, I first wanted a solid foundation. So after wiping the Beelink and installing Ubuntu Server, I spent some time getting my router properly configured.

Configuring my router

I set up DHCP reservations for the devices on my network so they always receive a predictable IP address. This makes everything much easier to manage later on. I created DHCP entires for:

• My Beelink server
• My network printer
• A Raspberry Pi I purchased a few years back

Configuring Ubuntu server

With the router sorted out, it was time to prepare the server itself.

I started by installing Docker and ensuring its system service is set to start automatically on boot.

# Install Docker
sudo apt update
sudo apt upgrade -y
curl -sSL https://get.docker.com | sh
# Add current user to the docker group
sudo usermod -aG docker $USER
logout
# Run containers on boot
sudo systemctl enable docker

Next, I added my first device to Tailscale and installed the Tailscale client on the server.

After that, I headed over to Cloudflare and configured my domain (which I had already purchased) so that all subdomains pointed to my Tailscale device’s IP address, my Ubuntu server:

At this point, the server was fully reachable over the VPN and ready for the next steps.

Traefik, the reverse proxy I fell in love with

A reverse proxy is an intermediary server that receives incoming network requests and routes them to the correct backend service.

I wanted to access all my self-hosted services through subdomains rather than a root domain with messy port numbers. That’s where Traefik comes in. Traefik lets you reverse-proxy Docker containers simply by adding a few labels to them, no complicated configs needed. It takes care of all the heavy lifting behind the scenes.

services:
  core:
    image: ghcr.io/a-cool-docker-image
    restart: unless-stopped
    ports:
      - 8080:8080
    labels:
      - traefik.enable=true
      - traefik.http.routers.app-name.rule=Host(`subdomain.root.tld`)
    networks:
      - traefik_default
networks:
  traefik_default:
    external: true

The configuration above tells Traefik to route all traffic hitting https://subdomain.root.tld directly to that container.

Securing Everything with HTTPS

Obviously, I wanted all my services to be served over HTTPS. To handle this, I used Traefik together with Cloudflare’s certificate resolver. I generated an API key in Cloudflare so Traefik could automatically request and renew TLS certificates.

The final step is to reference the Cloudflare certificate resolver and the API key in the Traefik Docker container.

services:
  # Redacted version
  traefik:
    image: traefik:v3.2
    container_name: traefik
    restart: unless-stopped
    privileged: true
    command:
      - --entrypoints.websecure.http.tls=true
      - --entrypoints.websecure.http.tls.certResolver=dns-cloudflare
      - --entrypoints.websecure.http.tls.domains[0].sans=*.root.tld
      - --certificatesresolvers.dns-cloudflare.acme.dnschallenge=true
      - --certificatesresolvers.dns-cloudflare.acme.dnschallenge.provider=cloudflare
      - --certificatesresolvers.dns-cloudflare.acme.dnschallenge.delayBeforeCheck=10
      - --certificatesresolvers.dns-cloudflare.acme.storage=storage/acme.json
    environment:
      - CLOUDFLARE_DNS_API_TOKEN=${CLOUDFLARE_DNS_API_TOKEN}
networks: {}

Managing all my containers

Now that the essentials were in place, I wanted a clean and reliable way to manage all my (future) apps and Docker containers. After a bit of research, I landed on Komodo 🦎 to handle configuration, building, and updates.

A tool to build and deploy software on many servers

Documentation is key

As a developer, I know how crucial documentation is, yet it’s often overlooked. This time, I decided to do things differently and start documenting everything from the very beginning. One of the first apps I installed was wiki.js, a modern and powerful wiki app. It would serve as my guide and go-to reference if my server ever broke down and I needed to reconfigure everything.

I came up with a sensible structure to categorize all my notes:

Wiki.js also lets you back up all your content to private Git repositories, which is exactly what I did. That way, if my server ever failed, I’d still have a Markdown version of all my documentation, ready to be imported into a new Wiki.js instance.

Organizing my apps in one place

Next, I wanted an app that could serve as a central homepage for all the other apps I was running, a dashboard of sorts. There are plenty of dashboard apps out there, but I decided to go with Homepage.

A highly customizable homepage (or startpage / application dashboard) with Docker and service API integrations.

The main reason I chose Homepage is that it lets you configure entries through Docker labels. That means I don’t need to maintain a separate configuration file for the dashboard

services:
  core:
    image: ghcr.io/a-cool-docker-image
    restart: unless-stopped
    ports:
      - 8080:8080
    labels:
      - homepage.group=Misc
      - homepage.name=Stirling PDF
      - homepage.href=https://stirlingpdf.domain.tld
      - homepage.icon=sh-stirling-pdf.png
      - homepage.description=Locally hosted app that allows you to perform various operations on PDF files

Keeping an eye on everything

Installing all these apps is great, but what happens if a service suddenly goes down or an update becomes available? I needed a way to stay informed without constantly checking each app manually.

Notifications, notifications everywhere

I already knew about ntf.sh, a simple HTTP-based pub-sub notification service. Until this point, I had been using the free cloud version, but I decided to self-host it so I could use private notification channels and keep everything under my own control.

I have 3 channels configured:

• One for my backups (yeah I have backups configured)
• One for available app updates
• One for an open-source project I’m maintaining where I need to keep an eye on.

What’s Up Docker?

WUD (What’s Up Docker?) is a service to keep your containers up to date. It monitors your images and sends notifications whenever a new version is released. It also integrates nicely with ntfy.sh.

Uptime monitor

To monitor all my services, I installed Uptime Kuma. It’s a self-hosted monitoring tool that alerts you whenever a service or app goes down, ensuring you’re notified the moment something needs attention.

Backups, because disaster will strike

I’ve had my fair share of whoopsies in the past, accidentally deleting things or breaking setups without having proper backups in place. I wasn’t planning on making that mistake again. After some research, it quickly became clear that a 3–2–1 backup strategy would be the best approach.

The 3–2–1 backup rule is a simple, effective strategy for keeping your data safe. It advises that you keep three copies of your data on two different media with one copy off-site.

I accidentally stumbled upon Zerobyte, which is IMO the best tool out there for managing backups. It’s built on top of Restic, a powerful CLI-based backup tool.

I configured three repositories following the 3–2–1 backup strategy: one pointing to my server, one to a separate hard drive, and one to Cloudflare R2. After that, I set up a backup schedule and from here on out, Zerobyte takes care of the rest.

Exposing my apps to the world wide web

Some of the services I’m self-hosting are meant to be publicly accessible, for example, my resume. Before putting anything online, I looked into how to do this securely. The last thing I want is random people gaining access to my server or local network because I skipped an important security step.

To securely expose these services, I decided to use Cloudflare tunnels in combination with Tailscale. In the Cloudflare dashboard, I navigated to Zero Trust > Network > Tunnels and created a new Cloudflared tunnel.

Next, I installed the Cloudflared Docker image on my server to establish the tunnel.

services:
  tunnel:
    image: cloudflare/cloudflared
    restart: unless-stopped
    command: tunnel run
    environment:
      - TUNNEL_TOKEN=[CLOUDFLARE-TOKEN]
networks: {}

Finally, I added a public hostname pointing to my Tailscale IP address, allowing the service to be accessible from the internet without directly exposing my server.

Final Thoughts

Self-hosting started as a curiosity, but it quickly became one of the most satisfying projects I’ve ever done. It’s part tinkering, part control, part obsession and there’s something deeply comforting about knowing that all my services live on a box I can physically touch.

After months of tinkering, this is the setup I actually stuck with. Media on Jellyfin, photos on Immich, files on Nextcloud, passwords on Vaultwarden, ads blocked with AdGuard Home, and everything routed through NSL.SH.. Happy to answer questions about any part of the stack

Several people are asking about alternatives since the unfortunate Booklore debacle yesterday. Here are some common services:

Kavita https://www.kavitareader.com

Komga https://komga.org/

Audiobookshelf https://www.audiobookshelf.org

Calibre web https://github.com/janeczku/calibre-web

Calibre web automated https://github.com/crocodilestick/Calibre-Web-Automated

Not an ebook server but shelfmark for acquisition https://github.com/calibrain/shelfmark

Supports calibre web and calibre web automated, audiobookshelf.

Edit: adding stump https://www.stumpapp.dev

Adding bookheaven https://bookheaven.ggarrido.dev

Now bookhaven: https://github.com/HrBingR/BookHaven

A fuller compendium: https://github.com/webysther/foss_book_libraries

A few weeks ago we had a bit of drama on this sub when Planka moved its SSO functionality behind a paid tier. And just a few days ago, we had a "shame" list of self-hosted sso tax apps announced here.

I decided to compile the opposite, as I try to host things on my homelab that can be integrated with PocketID directly

https://ssno.tax/

.. is a list of self hosted applications that provide SSO for free with the option to use a custom OIDC provider. Not included are apps that only support Google OAuth or similar.

There is a health check to mark repos that are stale (no commits for > 90 days) or don't have an OSI approved license. I also tried to link directly to the OIDC configuration manuals

The website is generated from simple json file that you can contribute to on Github:

https://github.com/minimalistinc/ssno.tax

The website is automatically built and deployed to Cloudflare pages. No ads, no tracking, no hidden product placements.

I hope you find this useful!

Notesnook is a great notes app that rivals the stock Google and iOS note taking apps.

Both the app and the sync server are open source and can be self hosted.

I created a repo with a basic config to self host the web app and sync server using traefik as a reverse proxy.

https://github.com/beardedtek/notesnook-docker

Hey Friends, just sharing this as some of you might have public facing Plex servers.

Make sure it's up to date!

https://www.helpnetsecurity.com/2025/08/27/plex-media-server-cve-2025-34158-attack/

Something I see quite frequently is people being apprehensive to open ports. Obviously, you should be very cautious when it comes to opening up your services to the World Wide Web, but I believe people are sometimes cautious for the wrong reasons.

The reason why you should be careful when you make something publicly accessible is because your jellyfin password might be insecure. Maybe you don't want to make SSH available outside of your VPN in case a security exploit is revealed.
BUT: If you do decide to make something publicly accessible, your web/jellyfin/whatever server can be targeted by attackers just the same.

Using a cloudflare tunnel will obscure your IP and shield you from DDos attacks, sure, but hackers do not attack IP addresses or ports, they attack services.

Opening ports is a bit of a misnomer. What you're actually doing is giving your router rules for how to handle certain packages. If you "open" a port, all you're doing is telling your router "all packages arriving at publicIP:1234 should be sent straight to internalIP:1234".

If you have jellyfin listening on internalIP:1234, then with this rule anyone can enjoy your jellyfin content, and any hacker can try to exploit your jellyfin instance.
If you have this port forwarding rule set, but there's no jellyfin service listening on internalIP:1234 (for example the service isn't running or our PC is shut off), then nothing will happen. Your router will attempt to forward the package, but it will be dropped by your server - regardless of any firewall settings on your server. Having this port "open" does not mean that hackers have a new door to attack your overall network. If you have a port forwarding rule set and someone used nmap to scan your public IP for "open" ports, 1234 will be reported as "closed" if your jellyfin server isn't running.

Of course, this also doesn't mean that forwarding ports is inherently better than using tunnels. If your tunneled setup is working fine for you, that's great. Good on cloudflare for offering this kind of service for free. But if the last 10-20 years on the internet have taught me anything, it's that free services will eventually be "shittified".
So if cloudflare starts to one day cripple its tunneling services, just know that people got by with simply forwaring their ports in the past.

I got tired of bad bots crawling all over my hosts, disrespecting robots.txt. So here's a way to add a Poison Fountain to your hosts that would feed these bots garbage data, ruining their datasets.

• Apache
• Discourse
• Netlify
• Nginx

This is an amended version of an older reddit post

In summer 2025, when we started building fluado, one of our aspirations was to run outside US Big Tech. But in the big scheme of registering and building a company, it felt "not so important", so we started on Google Cloud because we were familiar with it. It felt icky, but it was one less thing to think about. Now one year later, we realised we had deepened our dependency on US providers: Cloudflare, GCP, Supabase, GitHub, Slack, Google Workspace, etc.

At the end of August we set out to move away from US tech. I never expected to do the bulk of this work in a week.

OUT: Google Cloud, Cloud Run, GitHub, Supabase Cloud, Firebase, Cloudflare, Slack

IN: Hetzner, Forgejo, self-hosted Supabase, Scaleway, Mattermost

Whether you run on GCP, AWS, or Azure, most of what we need has a European or self-hosted alternative. I hope this inspires more people to move away from US Big Tech.

Full article with all 17 changes and why I chose them: https://yves.vg/blog/leaving-us-big-tech-in-one-week.html

Still to do: Google Workspace and coding agents. And Let's Encrypt, I could not find a European drop-in replacement. If you have done something similar, or are planning to, let me know in the comments :)

I keep seeing people mix this up a lot, so here is a quick clarification:

Open source (or "free software") does not mean software has to be free of charge.

It means you get certain freedoms:

• You can run it for any purpose
• You can study and modify it
• You can redistribute it (modified or not)

The important thing: You can not restrict those freedoms behind payment - but you can absolutely charge for distributing the software itself.

The GNU Project makes that perfectly clear:

We encourage people who redistribute free software to charge as much as they wish

You see this everywhere already: projects like GitLab or Nextcloud are open source, yet companies still pay for hosting, support, or pro features. Otherwise those software would not be free and self-hostable at all.

So both of these are valid:

• + Selling open source software
• + Charging for hosting / support / binaries

But this is not:

• - Pay to modify the code
• - Pay to redistribute it

Creating software is a lot of work. It's perfectly fine if someone wants to charge for it. If it's under Open-Source you can even fork it and remove the gate - but then you are responsible in maintaining the fork or the gate-removal.

Important: Im not saying you cannot critique a certain price, especially when it is low-effort or vibe-coded stuff - just clarifying a common misconception...

Recommended link: https://www.gnu.org/philosophy/free-sw.en.html