Scale to Zero, Docker OIDC, and AI Video Tools

Homelab Highlights for 2026-07-31: self-hosting and homelab notes worth knowing.

[Audio embed placeholder]

The Lead: I stopped leaving my self hosted apps running all night. Now the first request wakes them

A homelab operator shares a complete Kubernetes setup where nine apps scale to zero replicas overnight using KEDA. An HTTP interceptor holds incoming requests while pods start, and a cron trigger keeps daily-use apps warm. The public repository includes 21 apps and 22 infrastructure components as a blueprint.

Why it matters: This demonstrates a real-world, energy-saving implementation of scale-to-zero for self-hosted services, providing a template for others to optimize resource usage and reduce power consumption in their own labs.

Source: github.com

The Feed

Docker OIDC connections for GitHub Actions available for Docker Orgs

Docker now supports OpenID Connect (OIDC) for GitHub Actions, allowing workflows to authenticate with short-lived, per-run tokens instead of stored personal or organization access tokens. This eliminates the need to manually rotate long-lived credentials and reduces the risk of leaked tokens.

Why it matters: For teams using Docker Hub in CI/CD, this improves security by adopting the same short-lived credential pattern used by major cloud providers, reducing the attack surface and audit burden associated with static secrets.

Source: Docker

A Week in Matrix

A community digest highlighting recent developments, discussions, and project updates within the Matrix ecosystem, an open protocol for secure, decentralized communication.

Why it matters: For those self-hosting communication tools, this provides a curated look at the state of a major open-source alternative to centralized platforms, useful for staying informed on features, security, and community trends.

Source: Hacker News

Run Kimi K3 using 29 GB of RAM at 0.50 tok/s

A research project from SQLiteAI demonstrates running the Kimi K3 language model using 29 GB of RAM by storing model weights in a SQLite database file and using its B-tree for lookups, trading speed for reduced memory footprint.

Why it matters: This presents a novel, resource-constrained approach for running local LLMs, potentially enabling experimentation on hardware with limited RAM, albeit at significantly slower inference speeds.

Source: Hacker News

Algorithms on billion-scale graph using 10GB RAM: I love DataFusion

A blog post details performing graph algorithms on billion-scale datasets using only 10 GB of RAM, leveraging the Apache DataFusion query engine for efficient, memory-conscious data processing.

Why it matters: This showcases techniques for handling large-scale data analytics in memory-constrained environments, relevant for homelabs and developers working with big data on limited hardware.

Source: Hacker News

The development pipeline is a production system

An essay argues that CI/CD pipelines should be treated with the same rigor as production systems—including SLOs, monitoring, and runbooks—because their failure directly impacts the ability to develop and deploy software.

Why it matters: It reinforces a critical operational mindset for teams of any size, encouraging better reliability practices for the infrastructure that underpins software delivery, which is especially relevant for self-hosted development environments.

Source: Hacker News

One Thing to Try

Review the open-source Kubernetes configuration that scales nine apps to zero overnight using KEDA. Examine the YAML for scaling rules, the HTTP interceptor setup, and the cron trigger for predictable usage patterns as a practical template.

Sources

Transcript

Host A: Welcome to Homelab Highlights, the show that surfaces practical homelab wins and useful self-hosted tools.

Host A: Let’s start with Docker. They just announced OIDC support for GitHub Actions, and the problem it solves is pretty straightforward: you’ve probably got personal access tokens sitting in your GitHub secrets right now, and they’re long-lived. Someone has to remember to rotate them, and if one leaks, it stays valid until you catch it. Docker’s new approach uses OpenID Connect to let your workflows request short-lived tokens instead—one per run, expires in minutes, can’t be reused. [conversational] It’s the same pattern AWS and GCP already use for cloud access, now applied to container registry authentication.

Host B: The tokens are scoped to the specific job, so even if someone grabbed one mid-run, its usefulness is extremely limited. It’s available for Docker Team, Business, or Hardened Images subscriptions, plus their sponsored open source program. The setup is pretty straightforward: you create a connection in Docker Home, define rulesets that control which repos and branches can access which resources, then update your workflow YAML to use the new docker/login-action with an environment variable pointing to your connection ID. You can get really granular with the rulesets—pin to a specific branch, allow only certain repos, block pushes from forks entirely. That kind of fine-grained control is what makes this more than just a checkbox.

Host A: Shifting to CI/CD infrastructure itself, someone posted on Hacker News about treating your development pipeline as a production system. The argument is straightforward: if your pipeline breaks, your ability to ship fixes breaks with it. The author suggested applying SLOs to pipeline stages—like ‘pipeline runs must complete within 10 minutes 99% of the time’—and having a documented runbook for when things fail, just like you would for a service outage.

Host B: [with emphasis] The discussion thread had some good war stories. One person mentioned their team started treating their Jenkins controller with full monitoring and backup after an outage cost them a day of development time. Another said they now run their CI/CD controllers in high-availability mode because a single-node failure once blocked the entire team. It’s a perspective shift: the tools you use to build and deploy are just as critical as what you’re deploying.

Host A: There’s a GitHub project called ‘waste’ from a group called SQLiteAI that claims to run the Kimi K3 language model using 29 gigabytes of RAM at half a token per second. The approach is interesting—they store model weights directly in a SQLite database file and use the database’s B-tree for lookups instead of loading everything into RAM upfront. That 29 GB figure is for the 7-billion-parameter version, which is pretty lean compared to some of the memory-hungry runners out there. The trade-off is speed: half a token per second is slow for interactive use, but could work fine for batch processing overnight.

Host B: [skeptical] The repo’s README is upfront about it being a research project, not production-ready, but it’s a clever hack if you’re disk-I/O bound but RAM constrained. They’re essentially using SQLite as a virtual memory manager for the model weights. If you’ve got a machine with 32 gigs of RAM and you’re experimenting with local LLMs, it’s worth keeping an eye on, though we haven’t seen real-world benchmarks yet.

Host A: The open-source video editor Shotcut released version 24.07, and the standout improvements are hardware encoding for AMD and Intel GPUs on Linux. They specifically fixed VA-API encoding on AMD’s RDNA 3 architecture, which has been a pain point for some folks. They also added AV2 codec support in MP4 containers, which is still niche but good for future-proofing. If you’re running a Jellyfin or Plex server and also doing video editing on the same machine, better hardware encoding means less fan noise and lower power draw when you’re processing files.

Host B: One more from the feed: VictoriaMetrics released v1.105 with a substantial memory optimization for high-cardinality metrics. They changed how they store label names in memory, moving from a map to a more compact data structure, and saw up to 70% memory reduction in real deployments. One example they showed dropped from about 40 GB of RAM to just under 12 GB for the same workload. [with a small lift] That’s the kind of engineering that matters when you’re self-hosting on a budget. Query performance improved slightly too because of reduced memory pressure. If you’ve been hitting memory limits with your monitoring stack, it’s worth checking out.

Host A: Our tool highlight is a real-world scale-to-zero setup that a homelab operator named Morten Nordbye shared on GitHub. He’s got nine apps that scale themselves to zero when nobody’s using them, all nine go down overnight, and he’s been running this on a Kubernetes cluster at home for months. The repo is essentially a blueprint of his entire setup—21 apps and 22 infrastructure components. He shared Grafana dashboard screenshots showing clear dips to zero replicas during off-hours, with sharp spikes back up when traffic hits. He’s inviting people to poke around and steal what’s useful.

Host B: He’s using KEDA for the scaling, with its HTTP interceptor handling the wake-up. Here’s how it works: traffic routes to the interceptor first, which holds the request open while the pod starts, then forwards it. So the first request doesn’t fail; it just waits a bit. He’s also got a cron trigger to keep daily-use apps warm, so he’s not cold-starting every single visit. The cron trigger scales to one replica at 7 AM, so his morning routine apps are ready when he is. That’s a clever balance between savings and usability.

Host A: [curious] Looking at the actual YAML configuration, he’s set a cooldown period of 300 seconds after scaling down. That prevents rapid cycling if there’s a burst of traffic—you don’t want the pod spinning up and down every few seconds. He’s also using a custom metric based on request queue length in the interceptor, which is more responsive than just checking for zero active connections. The scaling threshold is ‘if there are more than zero requests waiting in the interceptor’s queue for more than 10 seconds, scale up.’ That means a single request won’t trigger a scale-up immediately; it has to be sustained demand.

Host B: Over two days, his dashboard showed about 302 pod-hours not spent. The community reaction was mixed but thoughtful. Some people questioned the real power savings, arguing that containers are already pretty efficient when idle. One commenter did the math: if an idle container uses 5 watts and you scale it to zero for 12 hours a day, that’s 0.06 kWh saved per day, per container. Over a month with nine containers, that’s roughly 16 kWh, which depending on your electricity rate could be a couple dollars. It’s small, but it adds up.

Host A: Another person shared their own experience: they’ve seen savings of 5 to 20 watt-hours per hour by shutting down VMs and containers they don’t need, which translated to about three dollars a month for them. They specifically said they wouldn’t spin down hard drives because the wear isn’t worth the couple bucks. They also mentioned noise reduction as a secondary benefit—fewer fans spinning means a quieter office. Morten himself noted that for him, the project was as much about learning KEDA and optimizing his cluster as it was about the savings. He wrote that the biggest win was understanding his own traffic patterns better and having a more responsive cluster that doesn’t waste resources on services nobody is using.

Host B: [thoughtful] The operational detail worth stealing here is the combination of the HTTP interceptor for on-demand wake-up and the cron trigger for predictable usage. If you’re looking to implement this, start by identifying apps with very spiky, user-initiated traffic. The repo shows how to set minReplicaCount to zero and max to whatever you need, then define your triggers. It’s a solid template for anyone wanting to experiment without starting from scratch. Pay attention to your pod resource requests and limits too—if you set them too low, the cold start will be slower as the system struggles to schedule the pod, which negates some of the responsiveness benefit.

Host B: Sticking with that scale-to-zero thread, one community member laid out a really practical framework for thinking about what to enable it for and why. They posted this in a Reddit discussion, breaking down their services into ‘yes’ and ‘no’ categories based on actual usage patterns and technical requirements, not just theory. The key insight is framing it as a trade-off: the cost is cold-start latency, the benefit is resource savings in power and compute headroom.

Host A: They have it enabled for forum software and a chat system for friends—if no one’s visiting, no resources are needed. It’s also on for various random static sites with dependencies that only get accessed infrequently. They gave the example of a documentation site for a side project that might get a few hits a week. Keeping a PHP-FPM container and a database warm for that is wasteful, so scale-to-zero makes perfect sense. They also included a personal finance dashboard they only check on weekends and a tool for generating custom RSS feeds that runs maybe once a day.

Host B: But they keep it disabled for their credential manager, because it’s used frequently and cold starts would be annoying. Also disabled for their NVR, DNS, Home Assistant, and media servers like Plex or Jellyfin, where the service needs to run in the background or autodetection would be ruined. For the NVR, motion detection needs to be always-on. For Jellyfin, background tasks like library scanning and live TV tuning require a running instance. These are services where ‘zero’ isn’t an option. Their DNS resolver handles local service discovery, so having it down would break internal networking for other scaled-up services trying to find each other.

Host A: [with emphasis] They made a distinction between a Signal CLI backend, which needs to run on a schedule to receive messages, and its web UI, which can scale to zero because it just interacts with the CLI on demand. Syncthing was another no-go because it’s not HTTP-based. That’s a key technical filter: KEDA’s HTTP scaler won’t work for protocols like Syncthing’s BEP. They also mentioned leaving their monitoring stack—Prometheus, Grafana, Alertmanager—always on, because you need to be able to see what’s happening even when other things are scaled down. Their backup server was also a ‘no’ because it runs on a fixed schedule and needs to be ready to initiate transfers immediately.

Host B: Their take was that for home software, scale-to-zero should be more of a ‘why not’ instead of a ‘why.’ It’s one person’s setup and reasoning, but it’s a useful framework for thinking about what in your own lab might be a good candidate. They emphasized starting small: pick one or two low-risk services, implement the scaling, and monitor the cold start latency. If a five-second wake-up delay is acceptable for that service, then it’s a win. This is attributed experience, not a universal rule, but it’s a fantastic starting point for your own evaluation. They concluded by saying the mental exercise of categorizing their services was valuable in itself, making them more aware of what each thing actually does and when it’s needed.

Host A: Here’s a quick tip pulled from today’s stories. If you’re looking at scale-to-zero, start by auditing your services for two things: one, is it strictly user-facing via HTTP? And two, does it need to do anything in the background on a schedule or listen for events? If it’s yes to the first and no to the second—like a static site or a tool you only use occasionally—it’s probably a safe first experiment. Just be ready for that initial load delay. A practical step: use KEDA’s simple HTTP scaler with a low cooldown period like 30 seconds for your test. That way, if it scales down too aggressively, it won’t take long to wake back up. And as the community highlight showed, keep your monitoring tools running to track the cold start times and make sure they’re within your tolerance. Also, consider setting a memory request for your pod that’s a bit higher than usual for the first minute after startup—some applications load data into memory on launch, and giving them a temporary boost can speed up that cold start. Happy hosting!

Host A: That’s Homelab Highlights for Friday. Until next time, happy hosting!