Over the past few years I’ve writtenthe occasional post about my top 10 apps for my homelab . This time I wanted to write a slightly different post. After all, the top 10 always end up looking pretty similar, especially once you look at what other homelab folks are posting. So I figured I’d introduce you to a few tools that not everyone has running on their home network. Maybe it’s some inspiration for you.

AutoKuma

Almost everyone knows Uptime Kuma. What I don’t like is having to configure everything by clicking through the UI, especially when the work is basically repetitive. WithAutoKuma (external link) you can configure Uptime Kuma directly via Docker labels. That eliminates the extra configuration step after starting the app. This is especially handy if, like me,you run GitOps : the availability monitoring gets set up right along with the deployment of the application. Naturally all the usual Uptime Kuma monitor types work here too.

labels:-"kuma.strava.http.name='Strava Statistics'"-"kuma.strava.http.url=https://strava.casalani.de"-"kuma.strava.http.parent_name=apps"-"kuma.strava.http.max_retries=5"

That’s a small example from Strava Statistics. In the end it’s easy to carry over to other systems with a simple copy & paste.

AutoKuma itself is of course just a Docker container, so it can easily be started alongside everything else on any host.

services:autokuma:image:ghcr.io/bigboot/autokuma:2.0.0restart:unless-stoppedenvironment:AUTOKUMA__KUMA__URL:https://uptimekuma.example.comAUTOKUMA__KUMA__USERNAME:kumaadminAUTOKUMA__KUMA__PASSWORD:STRENGGEHEIMHESPASSWORDvolumes:-/var/run/docker.sock:/var/run/docker.sock-./autokuma:/datalabels:-"kuma.apps.group.name=Applications"

And really, that’s about all there is to it.

Patchmon

I discoveredPatchmon (external link) a while ago. This still fairly young piece of software can handle patch management for your Linux and Windows systems. On top of that, a small vulnerability scanner can show you various hardening measures directly – though implementing them is of course up to you.

The Docker Compose stack for Patchmon is a bit bigger, since it consists of the app, a database, Redis, and Guacamole. The compose file provided by the vendor works really well though; I took it, including the accompanying .env file, pretty much as-is and barely had to adjust anything.

AdGuardHome-Sync

For a while I ran several physical servers, each with its ownAdGuard Home instance . These days onlyone Proxmox host is left, but several AdGuard instances are still running on it.

Here too, I don’t want to make every change manually, and definitely not twice. At some point I noticed that I’d added a new filter list to one instance, and only days later, while debugging a completely unrelated problem, realized the second instance had never picked it up. That’s exactly the kind of forgettingAdGuardHome-Sync (external link) solves. If I change the blocklists or other settings on one host, they’re synced over to the second host shortly after.

The whole thing is configured through a single YAML file with an origin and replica definition:

cron:"*/10 * * * *"origin:url:https://adguard-1.example.comusername:adminpassword:STRENGGEHEIMESPASSWORDreplicas:-url:https://adguard-2.example.comusername:adminpassword:STRENGGEHEIMESPASSWORDautoSetup:true

TheautoSetup parameter is particularly handy: if a brand-new AdGuard Home instance joins the mix, the replica gets set up automatically on the first sync, instead of me having to click through the setup wizard by hand.

OpenCloud

OpenCloud (external link) is my (theoretically) leaner alternative toNextcloud . I ran the latter for many months using the all-in-one container setup. It was definitely stable – unlike a lot of other people, I couldn’t really complain about it. But at some point, running a whole extra VM with the big Nextcloud stack just to manage a handful of files I want to access from outside my network started to feel like overkill.

A while ago OpenCloud kept coming up more and more in various communities, and I figured I’d give it a shot. It needs noticeably fewer resources, but in exchange the basic setup is quite a bit more complicated, especially if, like me, you want to manage a lot through Single Sign-On. Setting the whole thing up with Authentik is already a bit more involved, which is why I might write a separate post about that at some point.

Meerkat

Some of you have probably run into Monica as a CRM at some point. Unfortunately, development seems to have stalled, and its successor Chandler seems to have met the same fate. By contrast,Meerkat (external link) feels pleasantly lean and actively maintained: it ships as a single container instead of a big stack, which lowers the bar quite a bit for actually keeping it alive long-term.

Meerkat is a system that lets you manage your family, friends, acquaintances, coworkers, and everyone else as contacts. And not just addresses or phone numbers, but relationships, all kinds of anniversaries, and above all personal information about each person. I’ve for example noted down that my brother-in-law can’t eat peanuts, because there’s no way I’d remember that on my own by the next barbecue. For people like me, who struggle to keep track of a lot of information, it’s a fantastic system. As long as you actually keep it up to date…

Through the optional CardDAV server you can even sync the contacts to your phone. That turns Meerkat from just a digital notepad into something that can genuinely replace your address book.

SparkyFitness

Apps for tracking calorie burn, activities, and the like are a dime a dozen. Unfortunately most of them cost a fair bit of money these days. If you’re chasing a very ambitious fitness goal, those apps might be exactly right for you. For me, someone who just wants a bit of an overview, that’s an expense I don’t really need.

Luckily I came acrossSparkyFitness (external link) a while back. The developer describes the app as a selfhosted MyFitnessPal alternative, and I’d agree with that. The app can really do a lot. The downside is that onboarding, or rather the first few steps, are fairly tricky. You really have to sit down and carefully enter the foods you eat.

AdventureLog

WithAdventureLog (external link) you can either plan your trips or just track them. I only use it for the latter. In AdventureLog I’ve logged all the trips I’ve taken with my partner.

One really nice feature in AdventureLog is how your trips are displayed on a map. I printed it out and hung it on a wall in our living room together with various vacation photos, so guests can guess which photo belongs to which point on the map.

Conclusion

Seven tools that hopefully aren’t already on every other homelab top-10 list – from monitoring to patch management to a digital address book. Some of them I’m confident are here to stay (AutoKuma and AdGuardHome-Sync have been running quietly in the background for months), while with others like OpenCloud or SparkyFitness I’m still trying things out myself.

What almost all of them have in common: they solve one specific problem really well, instead of trying to be a giant all-in-one solution. Those are exactly the kind of tools that tend to get lost in the usual top-10 lists – even though they’re often the ones you end up appreciating most in everyday use.

Is there something running on your own network that hardly anyone talks about? Feel free to let me know – it might just turn into a second part of this list.

Update, December 2025: This article has been revised to reflect the recent changes to the Tesla Fleet API and current Teslamate versions.

Modern vehicles now offer API interfaces that let you pull all kinds of data. Tesla was one of the first manufacturers to expose this comprehensively, and software like Teslamate grew out of that. Teslamate is a self-hosted, open-source data logger that continuously captures your Tesla’s data, stores it, and visualizes it with Grafana.

What changed in 2025?

The key updates at a glance:

Tesla Fleet API: Tesla replaced the unofficial “Owner API” with the official Fleet API. Since February 2025, a pay-per-use model applies, with a $10/month free allowance. For private users with 1-2 vehicles, that allowance is usually enough; heavier usage adds roughly $2-5/month.

PostgreSQL 17: Teslamate now requires at least PostgreSQL 16.7 or 17.3. The developers recommend PostgreSQL 17.

Fleet Telemetry: New is the option for the vehicle to stream data directly. This is more precise and cheaper than classic polling, but more complex to set up. Fleet Telemetry requires your own server endpoint and TLS certificates — the vehicle then streams data via WebSocket whenever values change. That saves on API costs since you no longer have to poll actively, and you get high-frequency data with minimal latency, especially while driving. For most users, though, the tried-and-tested polling approach still works fine and is considerably easier to set up.

Teslamate – Install It Yourself, or Pay for a Service?

Teslamate isn’t a software-as-a-service — you install and run it yourself. Whether that’s on your home homelab or on a VPS in the cloud, e.g. withNetcup (external link) , both work fine. I host it on my own server on my home network.

Installation is straightforward withDocker . You need a database (PostgreSQL) and the application container. For visualization, Teslamate relies on Grafana with pre-configured dashboards.

Prerequisites

Hardware & software:

• A server with at least 2 GB RAM (Raspberry Pi 4/5, NAS, VPS)
• Docker and Docker Compose installed
• A permanently active internet connection

Tesla account:

• Tesla account with two-factor authentication
• A Tesla Developer account (free atdeveloper.tesla.com (external link) )

Setting Up a Tesla Developer Account

Since the switch to the Fleet API, you’ll need a developer account:

1. Sign in atdeveloper.tesla.com (external link) with your Tesla account
2. Create a new application (e.g. “Teslamate Homelab”)
3. Provide a short description
4. For local use, you can use localhost as the domain

Review takes a few days; for private use, approval is usually straightforward. The monthly $10 allowance is real credit — you don’t need to add a credit card as long as you stay under it.

Creating Tokens

Authentication used to work with your username and password. Today you need a “Refresh Token” and an “Access Token.” The easiest way to generate these is with dedicated apps:

• iOS: “Auth for Tesla” (Apple App Store)
• Android: “Tesla Tokens” or “Auth for Tesla”
• Windows/Mac: “Tesla Auth” or web-based tools

Steps:

1. Install the app and sign in with your Tesla username
2. Enter your password
3. At the second prompt, enter your 2FA code (not your password again!)
4. The app shows a Refresh Token and Access Token — keep both somewhere safe

The tokens stay valid for several months. Teslamate refreshes the access token automatically.

Installation with Docker Compose

The easiest way to install Teslamate is via Docker Compose. If you don’t already have Docker Compose installed:

# On Ubuntu/Debiansudo apt install docker-compose-plugindocker compose version

Create a working directory:

mkdir ~/teslamate&& cd ~/teslamate

I’ll point you to theofficial documentation (external link) here, since the configuration changes fairly regularly.

Important adjustments for 2025:

version:"3"services:teslamate:image:teslamate/teslamate:latestrestart:alwaysenvironment:-ENCRYPTION_KEY=your_secure_key-DATABASE_USER=teslamate-DATABASE_PASS=secure_password-DATABASE_NAME=teslamate-DATABASE_HOST=database-TZ=Europe/Berlin# Your timezone!-MQTT_DISABLE=true# If you don't need MQTTports:-4000:4000cap_drop:-alldatabase:image:postgres:17# At least 16.7 or 17.3!restart:alwaysenvironment:-POSTGRES_USER=teslamate-POSTGRES_PASSWORD=secure_password-POSTGRES_DB=teslamatevolumes:-teslamate-db:/var/lib/postgresql/datagrafana:image:teslamate/grafana:latestrestart:alwaysenvironment:-DATABASE_USER=teslamate-DATABASE_PASS=secure_password-DATABASE_NAME=teslamate-DATABASE_HOST=databaseports:-3000:3000volumes:-teslamate-grafana-data:/var/lib/grafanavolumes:teslamate-db:teslamate-grafana-data:

MQTT for Home Assistant:

If you want to forward the data to an MQTT server (e.g. forHome Assistant ), replaceMQTT_DISABLE=true withMQTT_HOST=mosquitto and add a Mosquitto container.

Start the containers:

docker compose up -d

Teslamate is then reachable athttp://{your-server-ip}:4000. On first launch, enter the tokens you generated earlier. After 1-2 minutes (waking the vehicle via the app may help), you should start seeing data.

Analysis with Grafana

A big advantage of the pre-built Docker Compose file: Grafana is included out of the box, reachable by default athttp://{your-server-ip}:3000.

Default login (change immediately!):

• Username:admin
• Password:admin

Grafana already has the PostgreSQL database configured as a data source, and all dashboards are pre-imported. If you’re running your own separate Grafana instance, you’ll need to import the JSON files manually from theGitHub (external link) repository.

Key dashboards:

• Overview: an overall summary of all metrics — the perfect starting point
• Drives: trip analysis with interactive maps, showing route, speed, and consumption
• Charges: detailed charging history with cost analysis per charge, and comparisons between charging stations
• Battery Health: long-term battery capacity trends, showing degradation over time and mileage
• Efficiency: consumption analysis by speed, temperature, and elevation — see what’s actually affecting your range
• Vampire Drain: standby consumption while parked, useful for spotting phantom drain
• Locations: frequently visited places, with automatic geofencing detection
• Updates: a history of every software update, with timestamps

Long-term Use and Insights

The real value shows up after several months. Here are some concrete examples from my own usage:

Battery degradation: my Model Y showed about 4% capacity loss after 50,000 km. 3-5% in the first 50,000 km is typical, and degradation slows noticeably afterward. With Teslamate you can see the exact trend and spot outliers (e.g. from BMS calibration).

Seasonal differences: in winter (around 0°C), my consumption sits at roughly 20-22 kWh/100km; in summer it’s 15-17 kWh/100km — about 30% more due to heating and a cold battery. That data is genuinely useful for route planning.

Cost optimization: home charging (€0.30/kWh) vs. Supercharger (€0.52/kWh) — the difference adds up. At 15,000 km a year, I save roughly €400 annually by charging at home. Even better:charging with solar surplus brings the cost down to about €0.08/kWh.

Efficiency: surprisingly, my optimal speed range turned out to be 90-110 km/h, not 70 km/h as I expected. Below 70 km/h, relative consumption creeps back up slightly due to auxiliary systems.

Troubleshooting

Teslamate shows “offline” instead of “asleep”: That’s expected behavior since Tesla firmware 2024.8+ — Tesla changed the API response, it’s not a Teslamate bug.

Token isn’t accepted: Use the Refresh Token (the longer of the two strings), not the Access Token.

No data: Check the Docker logs withdocker compose logs teslamate. Common causes: the vehicle is in deep sleep, wrong timezone, or network issues.

High API costs: Reduce the polling frequency, switch to Fleet Telemetry, or check for unnecessary wake commands.

Security and Backup

Network:

• Don’t expose it directly to the internet
• Use a reverse proxy with HTTPS (Nginx, Caddy, Traefik)
• Enable firewall rules

Backup:

docker compose exec database pg_dump -U teslamate teslamate > backup.sql

Updates:

docker compose pulldocker compose up -d

Frequently Asked Questions

Does Teslamate cost money? The software itself is free. Tesla API costs apply, but are usually covered by the $10 free allowance. Only heavy usage adds roughly $2-5/month.

Does it work with the new Fleet API? Yes, fully compatible and kept up to date.

Does it drain the battery? No, the additional consumption is negligible.

Can I track multiple vehicles? Yes, each one is logged separately.

Conclusion

For me, Teslamate is the best solution for in-depth vehicle data analysis. The upsides:

• Full data ownership through self-hosting
• Detailed analysis with Grafana
• Low cost thanks to the free API allowance
• An active community
• Great fit for Home Assistant integration

The downsides: it requires technical know-how, your own server, and there’s no official support.

For Tesla owners with a smart-home or homelab streak, Teslamate is an excellent piece of software. After a few months of use, the analytics get genuinely interesting, once trends and long-term patterns start to show. Even while driving, the Grafana dashboards surface plenty of interesting data.

Tips for Advanced Users

Reverse proxy setup: For secure access on the go, I’d recommend a reverse proxy with a Let’s Encrypt SSL certificate. Traefik or Caddy fully automate the process.

Database optimization: On very old installations, a manual vacuum of the database can help:

docker compose exec database vacuumdb -U teslamate -d teslamate -z -v

Custom dashboards: Grafana offers endless possibilities. You could, for example, build comparisons with other Tesla drivers, or visualize correlations between weather and consumption.

Further reading:

• Teslamate Documentation (external link)
• GitHub Repository (external link)
• Community Forum (external link)

If you’ve read myprevious post on my 2025 homelab setup , you know I’ve been usingKomodo (external link) as my GitOps tool for Docker Compose stacks. The concept is solid: Git as a single source of truth, Renovate for automated version updates, and Komodo deploying changes to the target system on every new commit. It mostly works – but Komodo has been driving me up the wall with one thing: file permissions. It simply doesn’t work consistently. Either the permissions on the host are off, or Komodo complains during deployment, or something in between. After the nth time dealing with it, I’d had enough and wanted something leaner.

The requirement is straightforward: when Renovate pushes a new commit to the repo (after I merge the pull request), the compose file on the server should be updated and the affected containers restarted. No Kubernetes, no additional framework. Just git pull and docker compose up.

The Basic Concept

The setup relies on three components working together:

1. Gitea (external link) – my self-hosted Git server where the compose files live
2. Renovate (external link) – checks the image tags in the compose files against the respective container registries every four hours via cronjob, and automatically opens pull requests when newer versions are available. I merge the PR, the commit lands onmain.
3. webhook (external link) – a single Go binary that exposes an HTTP endpoint on the target server. Gitea fires a webhook on every push, which triggers the deploy script.

The data flow looks like this:

Renovate detects new image tag
→ PR in Gitea
→ Merge
→ Gitea fires webhook
→ webhook binary calls deploy.sh
→ git pull + docker compose up -d

No polling, no daemon watching container registries, no framework with its own opinions about file permissions.

Why Not Just Watchtower or a Cron Script?

Before reaching for webhook, I briefly considered two other approaches.

Watchtower (external link) monitors running containers and pulls new images automatically. The problem: Watchtower reacts to new images in the registry, not to Git commits. When Renovate opens a PR and I merge it, Watchtower has no idea – it just pulls whenever it decides to check. That doesn’t fit a setup where Git is supposed to be the single source of truth. I also want to control the merge timing, not Watchtower.

A cron script withgit fetch would be the other option – check for changes every few minutes and deploy if there are any. It works, but has a conceptual drawback: it’s polling. I already have Gitea infrastructure that can deliver push events, so I should use it. A webhook reacts within seconds; a cron job with a 5-minute interval adds unnecessary delay.

webhook is the cleanest approach: event-driven, no extra daemon, a single binary with no dependencies.

Repo Structure

I have one repository per server:

• apps-stack fordocker01 – running tools likePaperless-ngx (external link) ,Immich (external link) ,Vaultwarden (external link) , and similar
• media-stack formedia01 – all the*arr containers and everything else in the media stack

Each repo just contains thecompose.yaml and any additional config files individual applications need. Nothing special.

Renovate in the Repos

Renovate runs self-hosted and checks the image tags in the compose files every four hours via cronjob. A minimalrenovate.json in the repo root is all it takes:

{"$schema":"https://docs.renovatebot.com/renovate-schema.json","extends": ["config:base"],"docker-compose": {"enabled":true }}

Renovate automatically detects image tags in the compose file and opens PRs when a newer version is available. For software that uses semantic versioning (major.minor.patch), this can be fine-tuned – for example, automatically merging patch updates while reviewing minor updates manually.

I exclude Postgres containers from Renovate. Major upgrades between Postgres versions require a manual database dump and restore – not something I want a bot to trigger automatically.

Installing and Configuring webhook

webhook is available as a single binary, or as a package:

apt install webhook

The configuration lives at/etc/webhook/webhook.conf:

-id:deployexecute-command:/opt/scripts/deploy.shcommand-working-directory:/opt/media-stacktrigger-rule:match:type:payload-hmac-sha256secret:"{{getenv \"WEBHOOK_SECRET\"}}"parameter:source:headername:X-Gitea-Signature

A few notes on this:

Header name: Gitea sends the signature asX-Gitea-Signature – without a-256 suffix and without asha256= prefix in the value. Sounds trivial, but it cost me a debugging session on the first try.

Secret as environment variable: The HMAC secret doesn’t belong in the config file in plaintext, especially if the file is versioned in the repo. So it’s read from the environment viagetenv.

Generate the secret:

openssl rand -hex32

Write it to a secrets file that only root can read:

# /etc/webhook/secrets.envWEBHOOK_SECRET=your-generated-string

chmod600 /etc/webhook/secrets.env

Systemd Unit

# /etc/systemd/system/webhook.service[Unit]Description=Webhook ReceiverAfter=network.target[Service]User=teqqy # Replace with your own usernameEnvironmentFile=/etc/webhook/secrets.envExecStart=/usr/bin/webhook -hooks /etc/webhook/webhook.conf -port 9000Restart=on-failure[Install]WantedBy=multi-user.target

User=teqqy ensures the webhook daemon and the deploy script don’t run as root. That’s important to me – processes that only need to run git pull and docker compose up have no business running as root. Replace the username with your own; the user needs access to the repo directory and must be a member of thedocker group.

EnvironmentFile loadssecrets.env and makesWEBHOOK_SECRET available as an environment variable before the process starts – so the secret flows cleanly into thegetenv call in the config.Restart=on-failure ensures the daemon automatically restarts after an unexpected crash without manual intervention.

systemctl enable --now webhook

Setting Up the Gitea Webhook

In Gitea underRepository → Settings → Webhooks → Add Webhook → Gitea:

• Target URL:http://media01.example.com:9000/hooks/deploy
• Secret: the same string you generated above
• Trigger: OnlyPush events are needed

On every push, Gitea automatically computes an HMAC-SHA256 signature over the request body and sends it as theX-Gitea-Signature header. The webhook binary verifies the signature before executing the script – a simple Authorization header would be significantly less secure since it doesn’t protect the payload against tampering.

Port 9000 shouldn’t be exposed directly to the internet. In my setup, Gitea and the webhook daemon are on the same internal network and the port isn’t reachable from outside. Anyone who needs to expose the endpoint for an external Gitea instance or GitHub should at minimum put it behind a reverse proxy with IP restrictions.

The Deploy Script

#!/bin/bashset -euo pipefailREPO=/opt/media-stackLOG=/opt/deploy-logs/deploy-$(date +%Y%m%d-%H%M%S).logexec >>"$LOG" 2>&1echo"=== Deploy$(date) ==="cd"$REPO"git pull origin maindocker compose up -d --remove-orphansdocker compose psecho"=== Done ==="

set -euo pipefail ensures the script immediately aborts on any error and returns a non-zero exit code. webhook logs that as well, sojournalctl -u webhook is the first place to look when something goes wrong.

The log directory needs to be owned by the executing user:

mkdir -p /opt/deploy-logschown teqqy:teqqy /opt/deploy-logs

Pitfalls I Hit Along the Way

.git directory ownership: If the repo was ever cloned or pulled as a different user, Git refuses access with a warning about “dubious ownership”. Fix:

chown -R teqqy:teqqy /opt/media-stack/.git

safe.directory: In some setups this helps additionally:

git config --global --add safe.directory /opt/media-stack

/var/log permissions: The executing user doesn’t have write access there. Put the log directory somewhere the user owns – I use/opt/deploy-logs.

*arr containers and UID/GID: My*arr containers run as99:100 (Unraid-compatible for NFS reasons). On the very first deployment, Docker creates bind mount directories with1000:1000 if they don’t exist yet. One-time fix before the first start:

chown -R 99:100 /mnt/data/arr/

After that it’s a non-issue since the directories already exist.

Monitoring

I useUptime Kuma (external link) to check whether containers are still running cleanly after a deployment. That’s enough for my use case: if a container stops responding after a failed update, Uptime Kuma alerts me. The deploy log andjournalctl -u webhook then provide the details on what went wrong.

A dead man’s switch (e.g. via Healthchecks.io) would be the next sensible step if you also want to be notified when a deploy simplydoesn’t happen – but for a media stack that’s not critical enough for me to add the overhead.

Conclusion

The setup has been running for a little while now and does exactly what it’s supposed to – without me having to debug anything in Komodo. The webhook binary is stable, the deployment flow is deterministic, and the total overhead is a handful of config files and a shell script.

For anyone with similar requirements who doesn’t want to run Kubernetes: this is, in my opinion, the most pragmatic approach. No magic, no frameworks, no overengineering. Just git pull and docker compose up.

If you have questions or feedback, reach me through the links in the menu bar.

Just like in 2021 and 2024, I’m once again sharing a list of my favorite software products of the year. I always enjoy reading posts like this because you can often discover a few hidden gems. Usually – let’s be honest – these lists are filled with the usual suspects. Nevertheless, this year’s list includes three selfhosted projects that you might not have heard of before.

#10: Wanderer

Let’s start withWanderer (external link) , an app for collecting your hiking routes – basically a selfhosted Komoot. The app itself doesn’t record routes, but you can easily import GPX files or data from Strava or Komoot and enrich them with additional details.

Since one of the latest updates, you can even share your new activities in the Fediverse, making it easy to discover hiking routes from people all over the world.

I like this software because after Komoot’s acquisition and price hikes, I lost interest in using it and went looking for alternatives. Now, when I go hiking, I track the route with Strava and then import it into Wanderer.

9: Nextcloud

Nextcloud (external link) really needs no introduction. For me, it’s a bit of a love-hate relationship. On one hand, it’s completely overpowered for simple file storage; on the other hand, it’s incredibly versatile and extensible with lots of small apps. I’ve tried several alternatives, but I always end up coming back to Nextcloud.

In myHomelab (external link) , I’m currently running the All-in-one installation, which has proven to be more stable than the usual Docker Compose or manual setups. To be honest, I mainly use Nextcloud for calendars and file syncing; I don’t run additional apps permanently at the moment.

8: Jellyfin

Jellyfin (external link) , the well-known media player. I’ve already written a separate post comparing it to Plex, the market leader. Personally, I’m very happy with Jellyfin – it does exactly what I need. And since there’s no cloud component, I don’t have to worry about hacks or data leaks.

Jellyfin runs as an LXC container on my Proxmox host. This allows me to use the iGPU of my thin client instead of a dedicated GPU for transcoding. However, I also make sure that all my media files are stored in a format that doesn’t require any transcoding in the first place.

7: FreshRSS

I’ve written aboutFreshRSS (external link) a few times before. It’s still the software for me when it comes to selfhosted RSS readers. FreshRSS aggregates all my feeds (which are a bit empty at the moment), but I don’t actually read them there. On my Apple devices, I use the Reeder app, which integrates flawlessly with my FreshRSS instance – as it always has.

6: Mealie

Anyone who enjoys cooking probably knows the struggle: recipes scattered everywhere, and modern recipe sites overloaded with ads and trackers. That’s why I rely onMealie (external link) – I collect all my favorite recipes there.

Mealie does an excellent job extracting recipe data from websites and presenting it in a clean, structured way. I often tweak steps and ingredients manually, but overall, it works great. As my collection grows, I’ve started organizing everything properly – otherwise, finding things becomes a mess over time.

Mealie runs as a Docker container using SQLite (no separate database). I’ve learned that smaller apps often don’t need a full-fledged database. Just make sure never to host SQLite databases on NFS shares – trust me on that one.

5: Immich

Immich (external link) is one of the rising stars in the selfhosted world. It’s a photo management app that just works incredibly well. Of course, like any complex software, it has the occasional hiccup, but the developer team fixes issues quickly. I chose Immich because more and more apps are integrating with it – allowing you to display albums or photos directly in other software.

One of my favorite features is “Memories” – similar to Facebook’s flashbacks (for those still on there). It shows photos taken on the same date in previous years, letting you revisit old moments – like the thousandth cat picture from two years ago.

Immich is important enough to me that it runs in its own VM, though still as a Docker container. That way, I have all data in one place, and backup or restoration is super simple using snapshots.

4: Adventure Log

Adventure Log (external link) was a lucky find on the r/selfhosted subreddit. The developer shared it there, and I’ve been a fan ever since.

It lets you plan and track your adventures (trips, vacations, etc.). You can now even import routes from Wanderer, though other import options are still missing. For people who love to travel, it’s a great tool.

Adventure Log also integrates nicely with Immich: you can link albums from your Immich instance directly to your travel entries and view them in context.

It’s currently the only app I run using Proxmox Helper Scripts, mainly because of its more complex setup. I might switch to the Docker version later, though.

3: Statistics for Strava

I started running regularly again a few months ago. I’ve been using Strava for years, andStatistics for Strava (external link) extends its standard functionality with additional analytics. The developer notes that, due to API restrictions, they can’t offer features that directly compete with Strava Premium.

Still, the app provides tons of useful data – personal records, heart rate analysis, and more. It originally focused on cycling but now supports many endurance sports.

The app runs as a Docker container, though you’ll need a separate cron job to import data and generate HTML reports.

2: Mastodon

Mastodon (external link) has been my main social network since Musk’s takeover of Twitter. Over the past few years, many new ActivityPub- and Fediverse-based apps have appeared, all of which integrate nicely with Mastodon. There are still some technical quirks (as I mentioned in aprevious post ), but overall, it’s been great.

Despite having an account on Bluesky, Mastodon remains my main platform. One of its downsides – which might also be an advantage – is that there are no algorithms. You don’t get suggestions or “people you might like,” which makes discovery harder but keeps the feed authentic.

I host Mastodon as a Docker container on my VPS, which also powers this blog. The containerized setup makes updating much easier.

1: Proxmox

The most important piece of software in my Homelab is definitelyProxmox (external link) . The virtualization platform keeps all my virtual machines running smoothly and has done so for years without major issues. Its built-in backup tools let me restore files or even just single configuration files when something goes wrong.

With that, my Top 10 list for this year is complete. As always, it wasn’t easy to decide which apps to include – there are plenty of smaller tools running in my setup that could easily have made the list too. But at some point, you have to draw a line. 😊

It’s fascinating to see how my Homelab has evolved over the years – and that brings me to the conclusion.

Conclusion – What’s Changed Since 2024

Comparing this year’s list to last year’s shows how much both my Homelab and my priorities have evolved. In 2024, many of my top picks were more “classic” infrastructure tools: Home Assistant, Paperless, Minio, EVCC – the backbone of any functional smart home or Homelab.

This year, the focus shifted slightly – away from automation and more toward tools that add fun and personal value. With apps like Wanderer, Adventure Log, and Statistics for Strava, several of my favorites are now tied to hobbies and everyday life. My Homelab isn’t just supposed to run efficiently anymore; it’s supposed to accompany me through daily routines – whether I’m hiking, cooking, or exercising.

Some old friends stayed on the list: Nextcloud, Immich, and Mastodon are still going strong. Others, like Home Assistant or Paperless-NGX, didn’t make the list this time – not because they’ve become worse, but because they’ve become invisible workhorses. They’re no longer highlights, but foundational parts of my setup.

Another interesting shift is that many of my 2025 favorites are more social. Through the Fediverse, shared photo albums, or activity feeds, my Homelab now connects me with others who share the same passions.

Who knows what 2026 will bring – maybe it’ll get more technical again, maybe not. But one thing’s for sure: life in the Homelab is never boring.

I’ve been onMastodon (external link) and in the ActivityPub universe ever since Elon Musk took over Twitter. The concept that there are many distributed servers in a social network really appeals to me. It’s, if you will, social networking rethought — decentralized, open, and community-driven. Most importantly, we avoid many of the built-in problems of the big mainstream networks, no matter which political direction one might lean toward.

My Journey in the Fediverse

From day one it was clear to me: if I’m active somewhere on the internet, it should be self-hosted. That meant I didn’t just want an account onmastodon.social (external link) orchaos.social (external link) , but full control of my own instance. I started with a Mastodon server on a Netcup VPS, using a classic (non-containerized) setup. Some time later I migrated that installation into Docker containers. Both versions ran without issues; updating is simply easier with containers.

Moving into the Homelab

A few months later, my KubernetesHomelab (external link) was finally stable — so what better time to move the Mastodon instance there? With a Cloudflare Tunnel, routing wasn’t a problem. That setup ran smoothly too. At some point I switched from the official Mastodon containers to the LinuxServer.io images — but functionally it made no real difference.

Switching to GoToSocial

A few weeks agoMatthias (external link) wrote about his experiment withGoToSocial (external link) . This software is essentially a lightweight alternative to Mastodon: written in Go, runs as a single binary. No Ruby, no external dependencies, no bloat. Perfect for small installations with just a few active accounts. GTS does not include its own frontend, so you need to rely on external apps (mobile or web) for UI.

Matthias shared some observations on performance and resource usageon his blog (external link) — pretty fascinating to read. So I spun up my own small GoToSocial instance. Configuration was very simple: download the binary, create a config file, start — done. And yes — it ran surprisingly stably. That said, it becomes clear fast that while GTS supports ActivityPub, interoperability is not yet on par with Mastodon.

Problem #1 – Wanderer and Silence in the Feed

ActivityPub — the protocol behind many Fediverse platforms — has gained traction in selfhosting communities lately, and I was excited when the appWanderer (external link) added support for it. The idea: share hiking routes, upload GPS tracks, and post them into the Fediverse. Fully federated via ActivityPub. I had to try it. Following from my GoToSocial instance was no problem. I imported a GPX route, then waited to see the post in my feed… nothing. After some fiddling I tried the same from a regular Mastodon account — and lo and behold, the hike showed up in the timeline. I reported the bug to the developer, but as of today nothing has changed. This clearly illustrates a point: ActivityPub is powerful but complex. Not every implementation “speaks” the same dialect, and small deviations can cause compatibility breaks.

Problem #2 – PeerTube and Follower Issues

Another area I explored was my old YouTube channel. I wanted to publish videos not only on YouTube, but also in the Fediverse.PeerTube (external link) is a good choice for a decentralized video platform: it works similarly to Mastodon, but for video content. Installation was fast, but configuration took work: roles, permissions, federation settings, and many tuning parameters. But once set, it was stable and the community is active. However: interoperability between PeerTube and GoToSocial is even more brittle. I could follow accounts or channels, but PeerTube didn’t handle the follow request properly. This bug was known — an issue on GitHub claimed it was fixed in version 7.2. I was already running 7.3 — and still hit the error. Again, when I tried from a Mastodon account everything worked flawlessly. I could list more minor quirks (incompatibilities, HTTP header oddities, federation timeouts, etc.), but that would be nitpicking.

Interim Conclusion — Small Tools, Big Hurdles

The bottom line: if you have minimal demands and just want to run a lean Fediverse account, GoToSocial is a great choice. It’s slim, resource efficient, and quite stable. But once you try to extend beyond the basics — integrating with PeerTube, Bookwyrm, Pixelfed, or Wanderer — you notice that many projects haven’t quite aligned yet. That’s understandable. Every one of these tools is developed by small teams or individuals, often in their spare time. There’s no big corporate oversight. That’s part of the charm of the Fediverse — and also the source of many small frustrations.

Final Thoughts

I can’t really judge who is “at fault” for these issues. Sure, Mastodon likely sets the de facto standard, and ultimately all these smaller projects are built and maintained by people doing it for passion, not profit. I just hope that over time things will converge and that all these platforms can talk cleanly to one another.

3 DNS Blocklists for PiHole, AdGuard or blocky

A DNS ad blocker has become part of the standard setup in every homelab. Of course, these ad blockers require DNS blocklists that should be maintained. In this post, I’ll show you my lists and explain why I recommend them.

Of course, you can maintain many more lists than the three I recommend in this post, but more lists also cause more load and can impact your ad blocker’s performance.

Which software you use to block ads is, of course, a matter of preference. Since I run GitOps in my Kubernetes cluster and prefer config-as-code (enough buzzwords for now), I use blocky. However, these lists work just as well in PiHole or AdGuard.

Ads and Trackers

To block ads and trackers, this single list is usually sufficient. So far, I haven’t noticed any ads slipping through that could be filtered by an ad blocker.

https://raw.githubusercontent.com/ookangzheng/dbl-oisd-nl/master/dbl.txt

TV Ads and Tracking

Of course, no ads are blocked on regular TV, but modern smart TVs — if connected to the network and the internet — use various trackers to, for example, display ads via the red button feature. I’ve configured several lists for this on my setup, but generally, the first list would already be enough.

https://gist.githubusercontent.com/wassname/b594c63222f9e4c83ea23c818440901b/raw/1b0afd2aecf3a099f1681b1cf18fc0e6e2fa116a/Samsung%2520Smart-TV%2520Blocklist%2520Adlist%2520(for%2520PiHole)
https://gist.githubusercontent.com/wassname/78eeaaad299dc4cddd04e372f20a9aa7/raw/d7863a978993e99d9c77c9001008ce670a3b4c29/LG%2520Smart-TV%2520Blocklist%2520Adlist%2520(for%2520PiHole)
https://raw.githubusercontent.com/Perflyst/PiHoleBlocklist/master/SmartTV.txt
https://gist.githubusercontent.com/hkamran80/779019103fcd306979411d44c8d38459/raw/e0f084b396bb8ffcb390c8e7272ae96a6c2

Fake News

This list blocks domains known for fake news, conspiracy theories, and misinformation.

https://raw.githubusercontent.com/jojo321/hosts/master/fakenews

Whitelist

Of course, you should also maintain a whitelist — otherwise, you’ll likely block legitimate services. For example, in my environment, this includes Apple and Google services that are sometimes blocked by generic lists.

Further Recommendations

If you want to explore even more blocklists, take a look at these collections:

• https://firebog.net/ (external link)
• https://blocklistproject.github.io/Lists/ (external link)
• https://github.com/blocklistproject/Lists (external link)