DEV Community: Johannes Posch

LanCache Router: Routing and Failover for Technitium

Johannes Posch — Tue, 20 Oct 2026 20:28:49 +0000

A local game cache is valuable, but it becomes useless as soon as the DNS sends a bunch of PCs into a cache that is no longer functioning.

Another problem arises if you have multiple VLANs - the best choice of the cache for one network may turn out to be very bad for the other network. The PC server with a quick access channel to the gaming PCs of your LAN could be placed behind a firewall access point with a significantly lower speed for all the others.

And I wanted both these problems to work at once – which cache is appropriate for that client? Is the cache online?

The end product is called LanCache Router, an open source software application developed to work in Technitium DNS Server.

Why I moved the decision into Technitium

LanCache stores supported game and update downloads locally, so multiple machines can reuse downloaded content. DNS helps clients find it by returning the cache's address for the relevant download hostnames.

My previous setup spread the routing and health decisions across several components: dnsdist chose a DNS backend by client subnet, lancache-dns supplied the cache answers, and a separate checker toggled availability. Technitium handled normal DNS resolution.

That left several services coordinating a decision I wanted to make inside the DNS server. It also tied the setup to one cache and a hard-coded subnet.

Technitium supports apps that participate in query processing, so I brought the routing, domain matching, and health checks into one app. LanCache still handles the actual downloads and storage.

DNS chooses the destination. The download connection runs directly between the client and the cache.

A route for each client network

The configuration describes cache servers and the networks allowed to use them. A setup could look like this:

Client network	Preferred cache	If it is unavailable
Gaming PCs	Cache in the gaming room	Use the standby cache.
Another building	Cache in that building	Use its configured standby.
Guests	No cache route	Use normal DNS resolution.

For a supported query reaching the app, the decision is straightforward:

Find the first enabled route matching the client's source address.
Select the first Healthy server in that route's preference list.
Check whether the queried name belongs to the active cache-domain list.
Return the cache address for an A lookup, or let Technitium continue if those checks do not pass.

A route can also explicitly pass queries through, which is useful for exempting a test PC from its subnet's cache rule.

Routes use explicit priorities: lower numbers run first, and the first match wins. Put a device exception before the broader subnet route. If the winning route has no healthy server, the app passes through rather than trying a later route.

One subnet, two caches

Here is a complete configuration for a preferred cache and a standby:

{
  "enabled": true,
  "cacheServers": [
    { "name": "cache-1", "address": "192.168.3.44" },
    { "name": "cache-2", "address": "192.168.4.44" }
  ],
  "routes": [
    {
      "priority": 10,
      "sourceCidr": "192.168.3.0/24",
      "servers": ["cache-1", "cache-2"]
    }
  ]
}

Replace the addresses and subnet with your own. Both caches must be reachable by the routed clients and by the DNS server.

For matching download domains, clients in 192.168.3.0/24 receive cache-1 while it is Healthy. If it becomes unavailable, new answers use cache-2, provided that server is Healthy. If neither qualifies, Technitium resolves the lookup normally under its existing rules.

Clients outside the subnet have no matching route, so their lookups follow normal DNS processing. You could add a second route for 192.168.4.0/24 and reverse the preference list, giving each network its nearby cache first.

This is ordered failover. The app selects one cache at a time for each route; it does not balance downloads across all healthy servers.

The route's preference order decides each new answer. Clients may retain an earlier answer until its TTL expires.

Health checks without probing on every lookup

The default check requests /lancache-heartbeat over HTTP on port 80 and accepts a 200 or 204 response. TCP and HTTPS checks are also available, with shared defaults and per-server overrides.

Probes run in the background. Query handling reads the latest health state and domain matcher without making a network request of its own.

By default, two consecutive failures mark a cache Unhealthy, and three consecutive successes make it Healthy. Newly started caches begin Unknown and use faster startup checks until their state settles. A preferred cache returns to selection automatically after it recovers.

There is a timing limit here that matters in practice: changing a DNS answer does not move an existing download.

The app first needs to detect the failure. Clients may then retain an earlier answer until its TTL expires; the default is 60 seconds. Open connections continue independently. Failover improves subsequent lookups, but it cannot make an interrupted connection switch servers instantly.

Keeping the domain list current

The app downloads the community uklans/cache-domains list, with a configurable refresh schedule. You can include or exclude services, add download hosts, and carve individual names out of broader wildcard entries.

A failed refresh keeps the last successful list active. Each DNS node also saves a snapshot for ordinary restarts, so a temporary source outage does not require discarding a list it already has. A first installation still needs a successful download before cache-domain matching becomes available.

Before trying it on your network

There are a few boundaries to account for:

Technitium needs to see the client address. If NAT or a forwarding resolver makes every query appear to come from one gateway, subnet routes cannot distinguish the original clients.
Health checks run from the DNS node. A successful probe cannot detect a firewall rule that blocks only the clients. In a cluster, each node probes independently.
Cache addresses are currently IPv4 only. Eligible AAAA, HTTPS, and SVCB queries receive empty successful answers by default, keeping IPv6 addresses and service hints from bypassing the cache. Those modes are configurable.
Existing DNS rules still matter. Local zones and other apps can take precedence. Passthrough follows Technitium's normal behavior, including its blocking and upstream settings.

There is also no per-service routing yet: a client cannot send Steam downloads to one cache and Epic downloads to another through separate service rules. IPv6 cache addresses, per-service routing, and a diagnostic TXT query are recorded in the backlog.

Try it

You need a working LanCache and a compatible Technitium installation. Install the app ZIP through Technitium's Apps page, open its configuration, and start with one client subnet. The packaged configuration is disabled until you supply your settings and enable it.

Once the cache is Healthy and the domain list has loaded, test from a client in that subnet. Replace the DNS address below with yours:

dig @192.168.3.53 lancache.steamcontent.com A +short

With the default list and the example configuration, the answer should be 192.168.3.44 while the preferred cache is Healthy. The installation guide covers package compatibility, building from source, and checking fallback.

The project is MIT licensed, with a wiki covering configuration, routing examples, and troubleshooting.

If this fits your setup, take a look at the repository. Feedback from people running several VLANs or multiple DNS nodes would be especially useful. An issue with your intended topology, expected behavior, and relevant logs gives me something concrete to work with.

How are you handling cache availability across your networks today?

[Boost]

Johannes Posch — Mon, 26 May 2025 09:42:25 +0000

Johannes Posch

May 7 '25

Code Template Hub: How I Supercharged My Development Workflow (And You Can Too!)

#vscode #productivity #git #tooling

6 min read

Code Template Hub: How I Supercharged My Development Workflow (And You Can Too!)

Johannes Posch — Wed, 07 May 2025 14:04:32 +0000

Hey there! Ever found yourself copying and pasting the same component structure for the tenth time this week? Or maybe you've spent way too much time fixing inconsistencies in boilerplate code when you could be building actual features? Trust me, I've been there too, and it was driving me crazy.

That frustration led me to create Code Template Hub, a VS Code extension that's completely changed how I approach repetitive coding tasks. I'm excited to share it with you today!

Why I Built This (My Story)

Let me tell you a bit about my situation. I split my coding time between my day job at a company and my projects at home. These two worlds have totally different requirements, coding standards, and project structures.

At work, we needed standardized templates that every team member could use to ensure consistency across our codebase. Nothing kills productivity like having five developers each implementing components in their own unique way!

For my personal projects, I wanted something more flexible that matched my personal coding style. I didn't want to compromise on either front - I needed templates that would work seamlessly in both contexts.

I searched and searched for an extension that could:

Be flexible enough for ANY templating situation
Support different template sets for work vs. personal projects
Play nicely with version control (crucial for team collaboration!)
Be simple enough that my colleagues would actually use it

Nothing quite fit the bill. So I did what developers do best - I built it myself! Code Template Hub is the result of scratching my own itch.

What Code Template Hub Does For Me (And Can Do For You)

In simple terms, Code Template Hub lets me quickly generate files from templates stored in git repositories. But it's so much more than that.

Think of it as your personal coding assistant that knows exactly how you (or your team) like to structure your files. Need a new React component with all the trimmings? Two clicks. API service with proper error handling? Three clicks. Documentation file with your team's exact required sections? Done.

The best part? The templates evolve as my needs change, and I can have completely different templates for work versus personal projects. No more context switching headaches!

My Favorite Features (That You'll Love Too)

Here's what makes Code Template Hub so powerful in my daily workflow:

📦 Repository-based Templates with Automatic Updates

All my templates live in git repositories - just like my code. This means they're versioned, trackable, and shareable with my team. I configure my repositories through VS Code settings, which lets everyone on the team access the same templates.

The best part? Templates update automatically when VS Code starts. This means my team is always using the latest version - no more "oh, I was using the old template" problems!

💪 Powerful Templating Engine That Does The Heavy Lifting

I'm using dot.js as the templating engine, which gives me incredible flexibility. I can add loops, conditionals, and transformations directly in my templates. I've created templates that adapt to different component types, styling approaches, and project structures - all from a single template file.

🧩 Smart Parameters That Adjust To What You Need

One of my favorite innovations is how parameters work. I can define what information I need from the user, add validation to prevent mistakes, and even make certain prompts appear or disappear based on previous answers.

For example, if a user selects "Include Tests" for a component, only then do I show them options for test configuration. This keeps things clean and focused.

🔮 Advanced Variables For Intelligent Templates

The variables feature has been a complete game-changer for me. Beyond just collecting user input, I can define sophisticated variables that preprocess parameters or analyze the file structure where the template will be created.

What makes this truly powerful is the ability to define custom JavaScript functions (in separate files) on a template-by-template basis. These functions can:

Fetch information from web APIs
Analyze the project structure
Transform user inputs into exactly what the template needs
Generate complex derived values based on multiple parameters

For instance, in one of my templates, I created a function that checks our API documentation and automatically pulls in the latest endpoint structure. Another template examines the surrounding folder structure to adapt its output to match existing patterns.

Since these are full JavaScript functions with access to the workspace context, the possibilities are virtually limitless. It's like having a mini-AI assistant that understands your project before generating files!

👥 Author Info That's Always Correct

I've set up author and organization information in my VS Code settings, which means every file created has consistent attribution. My team members do the same, so we always know who created what. It's a small thing, but it adds accountability and helps with code ownership questions down the road.

🗂️ Complex File Structures With One Click

My absolute favorite capability is creating multiple files from a single template. For example, when I create a new feature, I need:

Component files
Style files
Test files
Documentation
Index exports

Before, this was a tedious, error-prone process. Now, I select one template and get a complete, perfectly structured feature folder. It's almost magical how much time this saves!

How I Use It (And How You Can Too)

Here's my typical workflow:

I've set up two repositories: one for work templates and one for personal projects
I create template files using dot.js syntax, adding placeholders for things like component names
When I need a new feature, I right-click in VS Code, select "New from Template...," and follow the prompts

The extension handles the rest, processing each template file and replacing placeholders with my input. The first time I showed this to a colleague, their jaw literally dropped. "You made that whole folder structure with two clicks?!" was the reaction.

Real-World Examples That Transformed My Workflow

Here's how Code Template Hub has changed my daily coding life:

React Components That Just Make Sense

Creating React components used to be tedious. Now, one template generates:

A properly structured component file
Styling that matches our project's approach (CSS modules, styled-components, or Tailwind)
Index exports for clean imports
Test files with proper testing library setup

The template even adapts based on the parameters I choose. If I select "Include Hooks," it automatically adds useState and useEffect imports and boilerplate. If I choose "With TypeScript," it adds the proper type definitions.

API Integration Without The Boilerplate

API integration always required tons of repetitive code. With Code Template Hub, I created a template that generates:

Service functions with proper error handling
Type definitions that match our API structure
Mock data for testing scenarios
Documentation comments with usage examples

The conditional prompts feature really shines here - I only see options relevant to the type of API I'm integrating with.

Documentation That People Actually Write

Let's be honest - documentation is often neglected because it's tedious to set up properly. My documentation template:

Creates files with all required sections pre-populated
Automatically includes author information
Sets up the proper formatting and structure
Adds the creation date and basic metadata

Since implementing this, our team's documentation quality has dramatically improved!

Getting Started (It's Easier Than You Think!)

Ready to try it yourself? Here's how to get started:

Install Code Template Hub from the VS Code Marketplace
Configure at least one template repository in your VS Code settings
Run "Code Template Hub: Refresh Templates" to fetch your templates
Right-click in Explorer and select "New from Template..."

That's it! Your first template creation is just a few clicks away.

How Templates Are Structured (For The Curious)

If you're interested in creating your own templates, here's a peek at how they're structured:

A template repository must contain a templates.json file in the root directory that defines all available templates and their parameters. This file is essential as it's what the extension looks for when loading templates. The template files themselves live in a subdirectory.

For example, a React component template might include:

/
├── templates.json
├── templates/
│   ├── react/
│   │   ├── component.dot.js
│   │   ├── styles.dot.js
│   │   └── index.dot.js

The beauty of this system is that you can structure your templates however makes sense for your workflow.

From Frustration To Freedom

Before I created Code Template Hub, I was spending hours each week on repetitive file creation tasks. Now, that time is spent actually solving interesting problems and building features.

The ability to use different template sets for my company work versus personal projects has been a complete game-changer. I no longer have to context-switch between different coding standards - my templates handle that mental overhead for me.

If you're like me and tired of repetitive boilerplate tasks stealing your coding joy, give Code Template Hub a try. I built it to scratch my own itch, but I'd be thrilled if it helps you too!

Check out Code Template Hub on GitHub and install it from the VS Code Marketplace today. I'd love to hear how you're using it and any suggestions for making it even better!