Getting 100 Doors Working Without Losing Your Mind
I picked up 100 Doors a few years ago after someone recommended it as a lighter alternative to the more resource-heavy solutions out there. It does one thing — manages a large set of entry points or access gates across different systems — and it does it okay, but not without some annoying friction. Let me walk through what actually happens when you try to run it.
The installation process is straightforward on Windows. You grab the installer from the official distribution page, run it, and it puts everything under your Program Files directory. On macOS it's a bit messier because of sandboxing rules, and you'll need to grant the app special permissions through System Settings > Privacy & Security before it can actually touch the door registry files it needs to read. Linux users usually compile from source, which requires a working Go toolchain and about twenty minutes of patience depending on your machine. At its core, the tool maps a number of logical doors (that's the nomenclature they use — doors, not endpoints, not routes, doors) to physical or virtual access points. You define a door, assign it an identifier, set some routing rules, and the program handles the decision tree when a request comes in. That's it. Nothing fancy. The configuration is stored in a JSON file at ~/.100doors/config.json on Unix-like systems or %APPDATA%\100Doors\config.json on Windows. Each door entry looks something like this:
{"id": "main_entry", "type": "ip_gate", "allowed": ["192.168.1.0/24"], "deny_list": [], "timeout_ms": 5000} Simple enough. The problem comes when you start chaining doors together — that's where things get interesting, and also where most people run into trouble. I spent about three days debugging a setup where door A was redirecting to door B, which was supposed to apply a deny rule, but the deny list on B was being ignored because of how the middleware layer handles nested references. Turns out the middleware caches door configurations at startup and doesn't reload them unless you send it a SIGHUP signal or restart the process. I found this out by accident after watching the config file change on disk but seeing no effect in the logs. The workaround is either to configure reload_on_change: true in the global settings or just accept that you need to restart the service after every config edit.
Common Pitfalls That Aren't Obvious
Beginners often assume that adding more doors improves security. It doesn't. Each additional door in the chain adds latency — I measured somewhere between 2 and 8 milliseconds per hop depending on your setup — and more importantly, each door is a potential misconfiguration vector. The more doors you have, the harder it is to audit what's actually happening to any given request. Another thing people miss: the deny list isn't evaluated before the allow list in older versions. If you're running anything before version 3.2.1, your deny rules might be completely ineffective because allowed IPs bypass the entire check. Upgrading fixed this, but you won't see an error message. It just silently does the wrong thing. There's also a known issue with IPv6 support that still isn't fully baked. The tool accepts IPv6 addresses in the config files, but the actual gate logic only evaluates the first 64 bits of the address for comparison. So if your network uses /64 subnets properly, you'll never notice anything wrong. If you're doing something more granular than that, you're on your own.
Get the Full Details
Performance Expectations
Under normal load — say, a few hundred requests per second across maybe twenty doors — 100 Doors handles itself fine. Memory usage sits around 40-60 MB on a default install. But if you push it past about 1,000 concurrent requests with more than fifty doors in the chain, you'll start seeing queue buildup and the timeout settings become more relevant. The program doesn't crash, but response times degrade linearly with door count past that threshold. I've seen it used in production environments with mixed results. The people who have success with it tend to keep their door count low and their routing logic simple. The people who struggle are the ones trying to turn it into something it's not — like a full access control system or a WAF substitute. It can't do either of those things well.
Download and Setup
You can find the official release at the 100 Doors project page. Grab the latest stable build for your platform, verify the checksum if you're doing anything production-adjacent, and run through the basic config. The documentation is sparse but adequate for the scope of the tool. If you run into issues that aren't covered there, the GitHub issues section has some decent threads from other users who hit the same snags I mentioned above. The community is small. Don't expect enterprise-level support. But for what it is — a straightforward door management utility — it gets the job done without demanding too much from your infrastructure.
