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.

Proxmox: Reducing Power Consumption with 4 Practical Tips

In times of rising energy costs and increasing environmental awareness, many of us are looking for ways to reduce electricity usage in our IT infrastructure. Especially in home networks and small servers that run around the clock, energy demands can quickly become a non-negligible cost factor.

If you, like me, useProxmox — an open-source tool for virtualization — there are fortunately several effective ways to optimize your setup’s power consumption without sacrificing performance.

In this blog post I share four proven tips to make your Proxmox installation more energy efficient. It’s not just about hardware adjustments, but also about smart software optimizations that make your VMs and containers more power-friendly. Whether you’re an experienced Proxmox user or just starting out with the platform, these tips will help you reduce your electricity bill and at the same time make a small contribution to environmental protection.

Let’s get started right away and see how you can pull more efficiency out of your Proxmox server!

Beforehand: Measure Power Consumption

To even know how much electricity your devices are using, you should measure it. It’s not about perfect accuracy here, but rather getting a feeling for how much power each device consumes. For this you can purchase acheap power meter. Note please that cheaper devices naturally don’t always have high accuracy.
If you have a smart home setup, you can plug a smart-power-plug with measurement function in front of your homelab. That way you can monitor the real-time power consumption via software.

Pay Attention to the Right Hardware

Of course everything ultimately stands and falls with the right hardware. Old enterprise hardware naturally uses a lot of power. By contrast, so-called thin clients are a very good solution for building a power-efficient server. I have once presented them in a video.
Additionally, you can build a good server yourself with the right components. In the Hardwareluxx forum there’s a linked Google Sheets file listing systems that idle at under 30 Watts.
It is also important, in a self-assembled PC / server, to pay attention to all components. It starts with an efficient power supply, goes through a good motherboard, up to the right choice of CPU. Especially the latter: Intel still has a slight edge when it comes to lower idle power consumption. It is also important that Intel CPUs with a “T” in the designation only have a lower TDP.

TDP itself does not directly equate to power consumption, but is the maximum heat output. A “T” CPU is thus suitable for systems that are intended to run fully passively. Components that tend to speak for higher power consumption would be:

• Graphics cards
• RAID controllers / HBAs
• Network cards with more than 10 Gbit speed

Further down in the article I discuss ASPM status. ASPM (Active State Power Management) means that a component can or cannot support certain power-saving functions. Roughly put, enterprise hardware often is not equipped with these functions.

Set BIOS Settings Correctly

Disable Unnecessary Hardware

In most BIOS settings you can disable various devices. For a virtualization host, for example, audio is often not needed. So it would be advisable to disable the sound card in BIOS. The same applies to COM or serial ports.
If you do not have a graphics card or other add-in card requiring a high PCI-Express standard installed, you could also reduce the PCIe slots from version 4 to version 3, for example. This too saves some watts.

Enable ASPM

ASPM stands for Active State Power Management and is a technology used in computers to improve the energy efficiency of PCIe connections. PCIe is a high-speed interface used in computers to attach various hardware components such as graphics cards, network cards, or SSDs. ASPM aims to reduce the power consumption of PCIe devices by dynamically adjusting power usage in connection lines between the CPU (or chipset) and connected PCIe devices. This is done by automatically switching between different performance states depending on utilization and current requirements.

Enable CPU Power-Saving Functions

In BIOS always enable C-States. Depending on manufacturer and version you should be able to enable up to C10. But don’t worry if your BIOS only allows e.g. up to C6 — you’re not missing out on much potential.

C-States

What Are C-States

C-States, or CPU sleep states, are states into which a CPU (Central Processing Unit) can enter when it’s not being actively used. They are part of modern CPUs’ performance control functions and serve to reduce power consumption when full CPU performance is not needed.

There are different C-states, from C0 up to Cn (depending on the processor). Here are some of the most common:

• C0: Active, executing tasks.
• C1: Light sleep, can quickly return to active.
• C3: Deeper sleep, more energy saved, slower wake.
• C6: Very deep sleep, almost completely off, longest wake time.

The switch between these states is automatically handled by the operating system and hardware based on current CPU load and energy settings.

You should always aim forC10 status. In a Proxmox server you likely won’t achieve that — after all the system is typically designed to run continuously, especially if you’re running many virtual machines or LXCs.

Check C-States withpowertop

powertop is a great Linux command that allows you to check the C-states of your server. If they only go up to e.g. C3, you are still wasting energy “unnecessarily”.

Often it’s PCI-Express devices that don’t allow further C-states. With the command:

lspci -vv | awk'/ASPM/{print $0}'RS= | grep --color -P'(^[a-z0-9:.]+|ASPM )'

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)

This is a German-run website, and the legally authoritative imprint (Impressum) required under German law (§ 5 DDG) is maintained in German only.

You can find it here:Impressum

This is a German-run website, and the legally authoritative privacy policy (Datenschutzerklärung) required under the GDPR is maintained in German only.

You can find it here:Datenschutzerklärung