Every docker-compose project on your Mac gets its own real HTTPS domain — shop.coding9.test instead of localhost:8081, :8082, :8083. MultiDocker never edits your compose files. It generates an override that strips host port mappings, attaches the containers to one shared Traefik edge proxy and issues locally trusted certs via mkcert. Secure cookies, redirects and OAuth callbacks behave like production. Three commands: init, up, open. Native macOS app with self-update included.
Framer AI AgentsDesign and publish professional sites with AI
Promoted
Maker
📌
Hey Product Hunt 👋
We build client projects for a living, which means a dozen stacks on one Mac: a Shopware shop, a Strapi site, an old monolith. Every one of them wants port 80. So you do what everyone does — 8081, 8082, 8083 — and you edit compose files you don't own, which then blow up on the next git pull.
The port juggling was annoying. The real problem was that localhost is not production: Secure cookies, OAuth callbacks and anything cross-subdomain behave differently there, so bugs show up in staging that never showed up locally.
MultiDocker fixes this at the edge instead of in your files. "mdocker init" writes a separate override file next to your project, strips the host port mappings, attaches the containers to one shared Traefik network and gets a locally trusted certificate from mkcert. Your compose file is never touched — git status stays clean. You get https://shopware-shop.coding9.test, and everything behaves the way it will in production.
It's macOS-native (SwiftUI) with the CLI as its backend, works with both OrbStack and Docker Desktop, and installs its own runtime on first launch.
This is a beta and I would genuinely like to hear where it breaks — especially with unusual compose setups. Ask me anything.