DepotDownloader with Lancache (-use-lancache)

01What a Lancache is

A Lancache is a self-hosted caching proxy you stand up on your own network. It sits between your machines and the game CDNs: the first time anything on the LAN downloads a piece of Steam content, the cache fetches it from the internet, slices it up, stores it to disk, and hands a copy to the requester. Every machine that asks for that same content afterward gets it from the cache — at local network speed, with zero further internet usage.

The mechanism is DNS. Clients are pointed at a Lancache DNS server that resolves the CDN download domains (for Steam, *.steamcontent.com) to the cache's local address, so their download traffic lands on the cache instead of going out to the internet. One important consequence: a cache can only store plain HTTP content — encrypted HTTPS can't be cached, it can only be passed through. Hold that thought; it's why the DepotDownloader flag behaves the way it does.

02The `-use-lancache` flag

DepotDownloader added Lancache support in v3.0.0 (January 2025). The flag is exactly one word:

> .\DepotDownloader.exe -app 440 -username you -remember-password -use-lancache

The help text describes it plainly — "forces downloads over the local network via a Lancache instance" — but it's worth knowing what it does under the hood, because three behaviours are bundled into that one flag:

It auto-detects the cache. On startup it resolves lancache.steamcontent.com and checks whether that name points at a private (RFC 1918) network address. If it does, a Lancache is present and it prints Detected Lancache server! Downloads will be directed through the Lancache. If the name resolves to a public address — i.e. there's no cache — the flag quietly does nothing.
It downgrades to HTTP. Because a cache can't store TLS traffic, the flag routes requests as plain http://lancache.steamcontent.com instead of HTTPS. That's the whole point — it's what lets the cache actually cache. The private-address check above is the safety gate: it only makes this switch once it's confirmed the traffic is staying on your own LAN.
It raises parallelism to 25. Normally -max-downloads defaults to 8; with a cache detected, DepotDownloader bumps it to 25 (unless you set -max-downloads yourself), on the logic that a LAN-speed source can feed far more concurrent chunks than the open internet. Steam's own client does the same.

03When it actually helps

The flag earns its keep wherever the same content is downloaded more than once on one network:

LAN parties. Twenty machines installing the same handful of games — one trip to the internet, nineteen from the cache.
Households and multi-PC setups. You and a sibling pulling the same depot, or the same game across a desktop and a laptop.
Server fleets and re-deploys. Rebuilding several dedicated servers off the same depot, or tearing down and standing one back up repeatedly — the second build onward is local. This pairs naturally with running DepotDownloader on a NAS or in Docker as a fleet's content source.

For a single machine downloading something once, the flag does nothing useful — there's no second request to serve from cache. And if your problem is just that one download is slow, the cache isn't the answer; the speed-tuning page is, where -use-lancache appears as one tool among several (the others being -max-downloads, -max-servers and -cellid).

04SteamPrefill — the other tool

Here's the distinction that trips people up. DepotDownloader with -use-lancache caches whatever you happen to be downloading, as a side effect of keeping a copy. But sometimes you want to warm a cache deliberately, ahead of time — fill it with the games your LAN party will install tomorrow, before anyone shows up — and you don't want a copy of those games on disk at all.

That job has its own purpose-built tool: SteamPrefill (by tpill90). It's a .NET tool built on the same SteamKit2 foundation, and it does one thing well: it downloads selected games' content through the Lancache to populate it, and writes nothing to disk — it pulls the chunks and discards them, so the only lasting effect is a warm cache. You pick apps from an interactive menu of what your account owns, it fills the cache, done. No disk space needed, no SSD wear, no game folders to clean up afterward.

Don't bulk-warm a cache with DepotDownloader

It's tempting to point DepotDownloader at twenty games with -use-lancache to prep a LAN party — but DepotDownloader keeps every byte it downloads, so you'd be writing all twenty games to disk just to populate a cache you'll serve them from anyway. That's what SteamPrefill exists to avoid. Use DepotDownloader when you want the files; use SteamPrefill when you only want the cache warm.

05Which tool for which job

Three pieces, three jobs — they stack rather than compete:

You want to…	Use
Run the cache itself (the infrastructure)	Lancache — stand it up first; both tools below need it present
Download & keep a depot or old build, cached as a bonus	DepotDownloader `-use-lancache`
Warm the cache for many games without keeping files	SteamPrefill

The short version: Lancache is the warehouse, DepotDownloader is the truck that brings a crate you keep, SteamPrefill is the crew that stocks the shelves with stock you don't. A couple of the ecosystem tools live in this same neighbourhood if you want the wider map.

06Setup gotchas

The flag uses a cache; it doesn't create one. -use-lancache assumes a Lancache already exists on your network. If you haven't set one up, the flag detects nothing and silently downloads normally. Stand up the cache (the lancachenet/monolithic Docker image is the usual route) and configure its DNS before expecting the flag to do anything.
DNS has to be the only DNS. The single most common Lancache failure is clients having a second DNS server alongside the Lancache one — then roughly half their requests bypass the cache. The Lancache DNS must be the only resolver handed to your gaming machines. This is a Lancache-config matter, not a DepotDownloader one, but it's where "it's not caching" almost always traces back to.
No "Detected Lancache server!" line = it's not engaged. That message is your confirmation the flag took effect. The first time I set this up I never saw the line and couldn't work out why nothing was caching — it was a stray second DNS server on the client, exactly the trap above. If you don't see it, detection failed — check that lancache.steamcontent.com resolves to your cache's private IP from the machine you're running on.
Old chunks can still be slow on the first pull. The cache only speeds up the second request. The first fetch of an old build still goes out to Steam's CDN at internet speed — and old manifests can be slow or sparsely served regardless, which is a CDN matter, not a cache one.

Net of it: a Lancache is separate infrastructure you set up once; -use-lancache lets DepotDownloader feed and draw from it when you want to keep what you download; and SteamPrefill is the right tool when you only want the cache warm. Get the DNS right first, watch for the detection line, and every repeat download on the network stops touching the internet.