unsubbed.co

Middleware Manager

Released under MIT, Middleware Manager provides traefik middleware, router, and server manager on self-hosted infrastructure.

Traefik infrastructure tooling, honestly reviewed. Built for operators who want a dashboard instead of YAML files.

TL;DR

  • What it is: A self-hosted Go microservice with a React UI that lets you manage Traefik middlewares, routers, services, plugins, and mTLS through a web dashboard instead of editing configuration files [1].
  • Who it’s for: Self-hosters and small platform teams running Traefik or Pangolin who find manually maintaining dynamic config YAML tedious or error-prone.
  • Cost: $0. MIT licensed. Runs as a Docker container alongside your existing Traefik setup [1].
  • Key strength: Single UI for middleware assignment, plugin installation, custom service definitions (load balancer, weighted, mirroring, failover), and mTLS — things Traefik has no built-in UI for.
  • Key weakness: Critical operational caveat — the Middleware Manager container must stay running at all times to keep its overrides active. Container crash = your custom middleware configuration disappears until the container restarts [1].

What is Middleware Manager

Middleware Manager is a microservice that wraps around Traefik’s HTTP provider system. Instead of editing dynamic configuration YAML files by hand, you get a dashboard where you attach middlewares to routers, define backend services, install plugins, and enable mTLS — all through a UI, with changes propagating to Traefik within seconds.

The project comes from hhftechnology, the same team behind Pangolin, a self-hosted overlay network manager built on top of Traefik and WireGuard. That lineage matters: Middleware Manager was built primarily to fill a gap in Pangolin’s web UI, which doesn’t expose Traefik’s middleware configuration. It works with standalone Traefik too, but the Pangolin path gets the most documentation attention [1].

The integration mechanism is Traefik’s HTTP provider: you configure Traefik to poll http://middleware-manager:3456/api/v1/traefik-config every five seconds. Middleware Manager serves the merged dynamic config — original Traefik config plus your UI-defined overrides — from that endpoint. Traefik picks it up on the next poll cycle, no restarts required for middleware changes [1].

As of this writing: 472 GitHub stars, 16 forks, 275 commits, MIT license. Small project by open-source standards, but deliberately scoped — this isn’t trying to replace Traefik, it’s trying to make Traefik manageable without a text editor.


Why people choose it

Independent third-party reviews of Middleware Manager don’t exist in any meaningful form — the tool is niche enough that it hasn’t appeared in general tech media. The closest available coverage is the project’s own documentation and the implicit problem statement it addresses.

That problem statement is well-understood in the self-hosting community: Traefik’s dynamic configuration system is genuinely powerful, but managing it means maintaining YAML syntax, keeping mental track of which middleware is attached to which router, and SSHing into a server every time you want to adjust a rate limit or add an auth header. Traefik’s dashboard is read-only — you can see your config but you can’t change it there. Traefik Enterprise adds UI features, but its licensing is not designed for the home-lab-to-small-VPS audience.

People running Pangolin are the most natural adopters: they already have Traefik, Docker Compose, and the habit of self-hosting in place. Middleware Manager slots into that existing stack as one additional container without requiring new skills or infrastructure.

The second use case is purely the mTLS and plugin management surface. Both normally require editing Traefik’s static config (which means a Traefik restart to take effect) and navigating the plugin catalog manually. Middleware Manager wraps both into UI flows [1].

There are no Trustpilot reviews, no G2 ratings, no third-party benchmarks to synthesize here. Evaluate this tool on its stated capabilities and architecture, not on community consensus.


Features

Based on the README and project documentation [1]:

Resource discovery and overrides:

  • Discovers existing routers and services from Pangolin’s API or Traefik’s API
  • Apply configuration overrides without modifying original Traefik YAML files
  • Reverting an override through the UI restores original behavior

Middleware management:

  • Create any Traefik-supported middleware type through a form interface
  • Assign middlewares to discovered routers with priority ordering
  • Template-based middleware creation for repeated patterns

Custom service definitions:

  • Load balancer services with multiple backend URLs
  • Weighted load balancing for traffic splitting between service versions
  • Traffic mirroring to a secondary backend (useful for shadow testing)
  • Failover configuration

Plugin management:

  • Browse and install Traefik plugins through the UI
  • Installation writes to Traefik’s static config — triggers an automatic Traefik restart
  • Bundled mtlswhitelist plugin for per-resource mTLS

mTLS:

  • Enable mutual TLS on individual routers via the bundled plugin
  • Configure certificate whitelists per resource

Built-in explorer:

  • Read-only view of all routers, services, and middlewares Traefik currently knows about
  • Useful for debugging which middleware chain is applied to which router

Technical stack:

  • Go API backend, React/Vite frontend
  • SQLite database (middleware.db) for configuration persistence
  • REST API for programmatic access
  • Docker/Docker Compose deployment [1]

Pricing: self-hosted only

There is no SaaS version. Middleware Manager is MIT-licensed software you run yourself. The software costs nothing. You pay for the server it runs on — in practice, one additional Docker container added to a machine already running Traefik, which means negligible marginal cost.

The relevant cost comparison is against the alternatives for solving the same problem:

Traefik Enterprise: Adds official UI features and RBAC to Traefik. Pricing is not publicly listed — it’s enterprise sales territory. For a self-hoster or small team, this is functionally not an option.

Manual YAML management: Zero cost, but every change requires a text editor, SSH access, and correct syntax. Mistakes produce silent misconfigurations or Traefik config reload failures.

Nginx Proxy Manager: A different ecosystem (nginx-based), but represents what a mature, well-supported UI for reverse proxy management looks like. For teams not committed to Traefik, it’s worth knowing this option exists.

For anyone already running Traefik: the economics are simple. Middleware Manager costs nothing to try. The 30-minute setup is the only investment. If it doesn’t fit your workflow, removing it means deleting a docker-compose service and reverting Traefik’s HTTP provider to its original endpoint.


Deployment reality check

The setup assumes you already have Traefik running and understand its configuration model. If you don’t, start with Traefik first — this tool simplifies Traefik management, it doesn’t replace understanding it.

Two deployment modes [1]:

Option A: With Pangolin (recommended for Pangolin users) Add the container to your Pangolin docker-compose stack. Set ACTIVE_DATA_SOURCE=pangolin, point PANGOLIN_API_URL at Pangolin’s internal API, mount the Traefik static config directory into the container, and update Traefik’s HTTP provider endpoint to point at Middleware Manager.

Option B: Standalone Traefik Same process, but ACTIVE_DATA_SOURCE=traefik and TRAEFIK_API_URL points directly at Traefik’s dashboard API.

The required Traefik provider change:

providers:
  http:
    endpoint: "http://middleware-manager:3456/api/v1/traefik-config"
    pollInterval: 5s

This replaces any existing HTTP provider endpoint. If you’re using Pangolin, you’re replacing Pangolin’s provider with Middleware Manager’s — which then incorporates Pangolin’s resources internally.

What can go wrong:

The “must stay running” problem. Stated explicitly in the README: “Middleware-Manager container has to be kept running in order to keep the override middleware deployed” [1]. Your custom middleware assignments are served live from this container. It is not a file on disk that Traefik reads once — it’s an HTTP endpoint that Traefik polls continuously. A container crash or OOM kill means Traefik falls back to its base config, losing all custom middleware assignments until the container restarts. For production infrastructure, you need a tested restart policy (restart: unless-stopped minimum), health checks, and monitoring. This is not an edge case — it’s the fundamental architecture of the tool.

Silent plugin path failures. The README explicitly warns: if TRAEFIK_STATIC_CONFIG_PATH inside the container points to the wrong location, plugin install and removal fail silently [1]. Check the mount point carefully before testing plugin management.

Plugin changes require Traefik restarts. Middleware Manager triggers these automatically, but it means the tool is restarting your reverse proxy — test this in a non-critical environment before relying on it.

Small project support surface. 16 forks and an active Discord channel are not the same as a large maintainer team. Bug reports may take time. Documentation gaps exist for edge cases outside the Pangolin happy path.

Realistic setup time for someone comfortable with Docker Compose and Traefik basics: 30–60 minutes to a working instance with the first middleware assigned through the UI. Add another hour if you’re unfamiliar with Traefik’s provider system.


Pros and cons

Pros

  • MIT licensed. No usage restrictions, no vendor relationship, no licensing cost [1].
  • Fills a genuine Traefik gap. Traefik has no official middleware management UI outside of Enterprise. This is the only MIT-licensed option in this space.
  • Non-destructive overrides. Your original Traefik YAML files are not modified. Reverting through the UI restores original behavior [1]. The override lives in Middleware Manager’s SQLite database.
  • Plugin management UI. Installing Traefik plugins normally requires two manual steps: editing static config and restarting Traefik. The UI handles both.
  • Custom service types. Weighted, mirrored, and failover load balancer configurations are available through the UI — useful for canary deployments or shadow testing.
  • REST API for automation. Teams that want to script config changes have an API surface [1].
  • Pangolin-native. If you’re already on Pangolin, this is effectively a first-party middleware management addition from the same team.

Cons

  • Container must stay running. This is the primary operational risk. File-based Traefik config is resilient by default; this architecture is not [1].
  • Silent plugin management failures. Path misconfiguration produces no error — just a plugin that doesn’t install [1].
  • Small community. 472 stars and 16 forks means limited ecosystem, limited community debugging help, and uncertain long-term maintenance commitment.
  • Pangolin-centric documentation. Standalone Traefik users may encounter documentation gaps for non-Pangolin configurations.
  • Requires Traefik baseline knowledge. The UI doesn’t abstract Traefik concepts — it surfaces them. Middleware chains, router priorities, provider merging — you need to understand these before the UI is useful.
  • No external validation. No public reviews, no community comparisons, no independent security audits available. You’re trusting the code on its own merits.

Who should use this / who shouldn’t

Use Middleware Manager if:

  • You run Pangolin or standalone Traefik and manually editing dynamic configuration YAML is becoming your bottleneck.
  • You’re applying middlewares (rate limiting, auth headers, redirects) across multiple services and want a single place to see and manage what’s applied where.
  • You understand Traefik’s configuration model and want faster iteration, not an abstraction layer.
  • You’re comfortable managing the container-dependency risk with a proper restart policy and monitoring.

Skip it if:

  • You’re new to Traefik. Learn Traefik first — this tool clarifies the interface, not the concepts.
  • Configuration resilience is critical. File-based Traefik config on disk is more robust than an HTTP-served config with a container dependency.
  • You want a large, well-established community around your infrastructure tooling. This is a small project.
  • You’re not running Traefik. This tool has no value in nginx, Caddy, or HAProxy stacks.

Consider the alternative first if:

  • You manage fewer than five services with infrequent middleware changes — editing YAML once a month is faster than maintaining an additional container.
  • You’re already using Portainer — evaluate whether its stack and container management reduces enough friction before adding a Traefik-specific tool.

Alternatives worth considering

  • Manual Traefik YAML/Docker labels — The default. Zero tooling overhead. Right choice for small, stable setups where config changes are rare.
  • Traefik Enterprise — Official UI and RBAC features from Traefik’s own team. Paid, enterprise-positioned, not available for the self-hosting audience on a cost basis.
  • Nginx Proxy Manager — Entirely different stack (nginx-based) but the closest in philosophy: a web UI for reverse proxy management. 25K+ stars, large community, no Traefik middleware support. If you’re not committed to Traefik, worth evaluating before choosing a stack.
  • Portainer — Broad container management UI. Doesn’t surface Traefik middleware specifically, but reduces overall infrastructure friction for Docker-based setups.
  • Traefik Kop — Syncs Traefik config from Redis for distributed setups. Different approach (config replication vs. UI management), more DevOps-oriented.

There’s no direct equivalent of Middleware Manager — a Traefik middleware management UI — in any comparable project at this license and price point. The realistic alternative for most users is file-based config management.


Bottom line

Middleware Manager solves a real problem in a narrow niche. If you’re running Traefik or Pangolin and find yourself SSHing into servers to adjust middleware configuration, the value proposition is clear: a free, MIT-licensed UI that makes those changes faster and less error-prone. The non-destructive override model is thoughtful. The plugin management integration is useful. The architecture works.

The container-dependency caveat is the one thing to think hard about before committing. File-based Traefik config is resilient by default; this tool introduces a liveness dependency into your traffic routing. That’s a manageable operational risk with proper monitoring and restart policies, but it’s not zero risk. Test it in a non-critical environment, build a restart policy, set up health checks, then decide if the workflow improvement is worth the dependency.

For Pangolin users specifically, this is an easy recommendation — the teams are the same, the integration is first-class, and you’re already accepting similar architectural decisions by running Pangolin. For standalone Traefik users, it’s a useful tool from a small project that deserves scrutiny before production use.


Sources

  1. hhftechnology/middleware-manager — GitHub repository and README (primary documentation, MIT license, deployment guide, feature overview). https://github.com/hhftechnology/middleware-manager
  2. Middleware Manager Official Documentation (setup guides, configuration reference). https://middleware-manager.hhf.technology
  3. Docker Hub — hhftechnology/middleware-manager (container registry, pull stats). https://hub.docker.com/r/hhftechnology/middleware-manager

Features

Integrations & APIs

  • Plugin / Extension System
  • REST API