The Issue

Every mid-size domain eventually needs a front door - and a lobby and elevators and unit numbers… why not deliver all of that infrastructure at once, and with matching trim?

Our Take

There’s a huge middleground where Operators need to move past localhost on the CLI and start to deliver domain services flexibly at cloud scale, but without resorting to global-scale multi-cluster failover coordination in Kubernetes. Inside this vast contingent, every new domain needs a (reinforced) front door - for our needs it has to be something battle-tested that terminates TLS without us having to get involved in certificate rotations, enforces HTTPS evenly across the domain, and flexibly routes traffic to whatever containers sit behind it.

Just like SOCKS this is a repeated problem across the ecosystem - whether it’s a full product site backed by a Postgres database, a single container serving a bespoke API from a t3.micro, or a pile of your own micro-services that just need a single place to call home, the job is the same and so is the ritual. You realize you haven’t deployed a new domain in years so you open the compose file from the last project, which was copied from the project before that, which started life as a blog post written for a router framework version that has since been through two major releases.

This obviously isn’t going to work so you start checking items off the list: stand up a reverse proxy from scratch, spend an entire morning wiring up SSL certificates, and then spend the entire afternoon proving that it actually routes where and how you think you’ve configured it to. Routing layouts are easy even with a dozen services; it’s the surrounding knowledge that evaporates between projects - which flags were load-bearing, which ones were cargo-culted, and which ACME certificate store quirks cost you a weekend last time an SSL rotation kicked off.

We got tired of spinning our tires while re-deriving all of it - so today we’re announcing our solution: Traefik In A Box In Advance, or TIBIA. It’s Open Source, it’s on our GitHub, it’s up-to-date, and it does one job: get a production-ready cloud-native router planted securely in front of your containers, without any of the ritualistic archaeology. It’s also a natural companion to SOCKS - one serves your files at the container level, the other puts them on the internet behind a superlative-class domain gateway.

What is TIBIA?

TIBIA is a pre-packaged production-ready Traefik routing stack running in Docker Compose: the latest Traefik domain gateway with automated Let’s Encrypt TLS certificates and domain-wide HTTP-to-HTTPS redirects baked-in, and for the discerning Operators among us - a specialized BRINGUP MODE with canary services already wired in for accelerated E2E validation of a freshly deployed stack. The single purpose of TIBIA is to get a properly configured Traefik instance sitting in front of your containers, quickly - and it’s really good.

To get started just clone the repo, set two environment variables, and in less than 5 minutes you have a live production-grade domain gateway with fully automated certificate plumbing and validated proof that it’s configured the way you expect. It’s another one of our solid production-ready building blocks, not a platform fragment you have to model your workflows around.

Why We Built It

This is the “hard delivery” angle, striking again. We ship connected devices and cloud services, which means we’re regularly standing up new domains, new hosts, and new services that all need a safe home on the global internet - the boring part of doing some seriously fun project work. And the same gateway/domain/networking issues keep turning up: a Let’s Encrypt rate limit hit for the new domain because DNS propagation wasn’t quite complete, a cached staging certificate stubbornly served in production even after hard refreshes and Incognito sessions in the browser, an ACME state file with the wrong permissions that Traefik quietly refuses to use during a critical certificate rotation, a ufw ruleset that Docker cheerfully punches through, and a stale routing label that survives multiple container restarts. None of these are hard once you know them but all of them are expensive the first time - and the fifth. We wanted the lessons baked into scripts and defaults so that bring-up is safe from the first command, not re-learned from the error logs. It’s the same zero-trust, secure-by-default approach we promote, applied to another recurring problem space where the common sense solution needs to just work, every time.

What’s In The Box

No guessing what’s in the box, here - just the pieces you’d end up building yourself:

• Three Entrypoints: Get three for the price of two! We ship the two standard public HTTP/S ports and a custom private HTTPS entrypoint on its own port for workloads you don’t want on the open internet.
• Two Let’s Encrypt Resolvers: Use stg for bring-up and debugging, prd for real, publicly trusted certificates that are all issued and rotated with an automated zero-touch mechanism. Move from one to the other without punching in a new provider configuration - just one label update as you validate each workload.
• A Traefik Dashboard: We pre-configure the Traefik dashboard to be served on the private port, as a practical demonstration of a restricted service. Keep an eye on all of your Traefik workloads in real time as you bring them online!
• Two whoami Service Canaries: Operators get copy/paste-able workload demonstrators, one routed by subdomain and one by path. Operators can prove routing rules, redirects, and certificates are lined up correctly before a real workload ever touches the stack - and then directly apply the same configurations to your own workloads.
• Helper Scripts: Operator tooling for the whole lifecycle: ./init, ./up, ./down, ./clean, and ./verify help speed things up through both BRINGUP MODE and PRODUCTION MODE phases - plus additional scripts for creating the shared network, installing Docker on fresh Debian or Ubuntu hosts, and locking down the rest of the host networking stack with ufw.
• Flexible Configuration: Use compact and portable Docker labels by default, or adopt the included file provider if you can’t tolerate even a momentary ingress outage when routing changes. Neither is wrong, and the README lays out the tradeoff for Operators.

Bring Up Safely, Then Immediately Go Live

The hard business of a stack like this isn’t necessarily which micro-service gets routed to where - it’s the global networking order of (non)operations. Traefik is feisty about getting things working right now, but Let’s Encrypt rate-limits duplicate certificates and even repeated TLS challenge failures against the production issuer can lock your domain out from getting SSL certificates. DNS that isn’t quite ready is the most common (but definitely not the only) way to trigger it - wrong certificate cache permissions? Container restarts now silently blow away your existing certificates and Traefik asks for another set every time it starts up… bringing 20 micro-services online? Get locked out on #15 and you have to start again, from scratch.

TIBIA executes a strong but cautious path into the workflow - BRINGUP MODE (./up) starts Traefik with untrusted staging certificates and both canaries running, a stack configuration where rate limits are generous and mistakes are cheap. Then ./verify prints a straight up PASS/FAIL for the checks that matter most to Operators:

• all containers are running
• HTTP is redirecting with a 308
• both canaries are answering requests
• path prefixes are stripped appropriately
• the staging certificate issuer is in use
• the dashboard is responding on the private port

Once the board is green you run ./down && ./clean and switch to PRODUCTION MODE with ./up production && ./verify production to confirm live production certificates are being used and there are no more canaries on the stack. The scripts also handle the certificate cache and file-permission traps along the way, and the README ships a troubleshooting table for the symptoms we’ve hit ourselves - from certificates that never issue to redirect loops behind a CDN. The outcome is a bring-up process that proves the stack works rather than hoping it does, and gets the whole thing working at absolute light speed.

Honest Limitations

We’re dedicated to talking about the soft underbelly of our creations, and a domain gateway sits at the second most sensitive spot in your infrastructure, so there’s plenty to consider with TIBIA:

• Traefik mounts the Docker socket to discover labelled containers, and access to that socket is effectively root on the host. Compromising the Traefik container compromises the machine. A read-only socket proxy or the file provider can reduce that exposure, but you’d have to set it up yourself. ChatGPT - What’s the big deal?
• The private HTTPS port is a standard entrypoint with TLS - it is not authenticated by default, and Docker publishes it on all host interfaces. Worse, Docker can bypass ufw entirely. The provided firewall script only locks down the other ports; protecting the private port itself requires a cloud or network firewall, and verifying it from an outside machine. Network security remains the Operator’s responsibility. ChatGPT - How can I handle this?
• With the default label-based configuration, changing Traefik’s own routing means recreating its container - which briefly takes your domain ingress offline. The file provider avoids that, at the cost of carrying an extra file and mount.
• Every container on the shared traefik_backend network can reach every other one, so sensitive services should get their own networks as well.
• The canaries can echo request headers during use and they clutter up configuration and domain resources. They’re a bring-up aid only, and production mode skips them for a reason - you shouldn’t run them in production unless you have a valid reason.
• Doing it - TRAEFIK_VERSION tracks a minor line so we expect the cadence on this project to be fairly tame, but minor-version changes mean reading release notes and re-running verification. TIBIA’s tooling makes that cheap to check, but it is not zero effort. Fork or extend it and plan on owning your own upgrade ops.

Get It / What’s Next

TIBIA is available, now, on our GitHub. You’ll need a domain you control, DNS records pointing at your VM/host, and public ports 80 and 443 reachable - then it’s literally a handful of commands to launch a validated gateway:

./init                          # then set SERVICE_DOMAIN and ACME_CERTIFICATE_EMAIL in .env.local
./scripts/create-network.sh
./up && ./verify                # bring-up mode: staging certs + canaries
./down && ./clean
./up production && ./verify production

The README also covers the full configuration reference, entrypoints, firewall guidance, certificate handling, and how to attach your own workloads - SOCKS makes a particularly good first one! ChatGPT - Can you help me get this working?

As with SOCKS, the code is out in the open so you can use it, break it, and improve it. If you hit a rough edge, find a gap in the verification, or want TIBIA to do something it doesn’t yet - open an Issue or send a Pull Request. The best fixes tend to come from someone else’s “oh, that’s why nobody does it that way” moment. And don’t mind the gopher - he didn’t write any of the code and we don’t let him actually route any traffic.

---

Disclosure: The “ChatGPT” links in this post are provided purely as a convenience, and 315Concepts does not endorse, review, or guarantee anything an AI assistant returns from them. AI-generated answers can be incomplete, outdated, or simply wrong - especially on security topics. Always use AI-provided information safely: treat it as a starting point, and double-check it directly against authoritative source material (such as the official Traefik and Docker documentation, and the project README) before acting on it, particularly for anything touching your firewall, certificates, or production infrastructure.