Problem
When running multiple projects/branches in parallel (e.g. git worktrees), host port collisions force manual port juggling (3000, 3001, 3002…), and it quickly becomes unclear which port maps to which project.
OrbStack solves this elegantly: every container automatically gets a hostname like <container>.orb.local (and <service>.<project>.orb.local for Compose), reachable from the host browser with no port mapping and automatic HTTPS. This is one of the main reasons people stay on the proprietary, commercial-licensed OrbStack instead of Colima.
Colima is uniquely positioned to offer this on the OSS side because it already owns the pieces: the internal dnsmasq resolver (#1381), Lima's hostResolver, and the Docker context/socket.
Proposal
Add an opt-in feature (e.g. colima start --domains / config autoDomains: true) that:
- Watches the container runtime (
docker events / containerd) for start/stop.
- Registers DNS records dynamically in the existing internal dnsmasq:
<name>.colima.local -> container IP (Compose: <service>.<project>.colima.local). Records are released on stop.
- Runs a lightweight reverse proxy (Caddy/Traefik-style) so that
http(s)://<name>.colima.local reaches the container's exposed port without host port publishing, with an internal CA for automatic HTTPS.
- Wires host resolution via Lima's
hostResolver so the host OS resolves *.colima.local to the VM with no /etc/hosts edits.
- (Optional) Honor a label such as
dev.colima.domains=myapp.local for custom domains, mirroring OrbStack's dev.orbstack.domains.
Why here, not Lima
Lima is intentionally container-runtime-agnostic; the container-watching + proxy logic belongs in the layer that owns the Docker context (Colima). Lima already provides the host-resolver primitive this would build on.
Prior art
Happy to help prototype this (the watcher + dnsmasq updater + Caddy config generator) if maintainers are open to the direction.
Problem
When running multiple projects/branches in parallel (e.g. git worktrees), host port collisions force manual port juggling (
3000,3001,3002…), and it quickly becomes unclear which port maps to which project.OrbStack solves this elegantly: every container automatically gets a hostname like
<container>.orb.local(and<service>.<project>.orb.localfor Compose), reachable from the host browser with no port mapping and automatic HTTPS. This is one of the main reasons people stay on the proprietary, commercial-licensed OrbStack instead of Colima.Colima is uniquely positioned to offer this on the OSS side because it already owns the pieces: the internal
dnsmasqresolver (#1381), Lima'shostResolver, and the Docker context/socket.Proposal
Add an opt-in feature (e.g.
colima start --domains/ configautoDomains: true) that:docker events/ containerd) for start/stop.<name>.colima.local-> container IP (Compose:<service>.<project>.colima.local). Records are released on stop.http(s)://<name>.colima.localreaches the container's exposed port without host port publishing, with an internal CA for automatic HTTPS.hostResolverso the host OS resolves*.colima.localto the VM with no/etc/hostsedits.dev.colima.domains=myapp.localfor custom domains, mirroring OrbStack'sdev.orbstack.domains.Why here, not Lima
Lima is intentionally container-runtime-agnostic; the container-watching + proxy logic belongs in the layer that owns the Docker context (Colima). Lima already provides the host-resolver primitive this would build on.
Prior art
dnsHosts(dns: support for custom hosts #512, net: propagate custom dns hosts to gvproxy #543)Happy to help prototype this (the watcher + dnsmasq updater + Caddy config generator) if maintainers are open to the direction.