Support Portless-style networking for Development Containers

[phr34k]

Feature Request: Support Portless-style networking for Development Containers

Development Containers work particularly well with Git worktrees, since each worktree can have its own isolated development environment. However, running multiple worktrees concurrently becomes awkward when each container needs to publish services on fixed host ports.

For example:

worktree-a → localhost:3000
worktree-b → localhost:3001
worktree-c → localhost:3002

This requires manually allocating ports, configuring applications to use those ports, and keeping track of which port belongs to which worktree.

What we'd ideally like is:

worktree-a → worktree-a.localhost
worktree-b → worktree-b.localhost
worktree-c → worktree-c.localhost

while allowing every container to continue listening on its normal internal port (e.g. 3000).

This is particularly important for Git worktree-based development, where running several branches simultaneously is a natural workflow.

Existing VS Code support

Visual Studio Code has had experimental support for a Portless-style development workflow for some time, but that support is tied to the IDE.

This means the functionality is not available when using Development Containers through the devcontainer CLI or other tooling independently of VS Code.

It seems that the underlying capability would be better placed at the Development Containers specification / runtime layer, rather than being exclusively an IDE feature.

Proposed Feature

Support hostname-based access to ports exposed by Development Containers, without requiring each container to bind a unique host port.

The implementation could take several forms. For example:

• A reverse proxy running on the host that routes hostnames to container ports.
• An overlay/networking mechanism that makes container services directly addressable from the host.
• Integration with Docker networking that allows containers to be addressed by a stable hostname.
• Integration with Portless or a similar protocol/tool where appropriate.

The exact implementation is less important than exposing a standard capability through the Development Containers ecosystem.

For example, a container could declare that port 3000 should be accessible using a hostname, and the tooling could provide:

https://my-worktree.localhost
        ↓
development container
        ↓
localhost:3000

without requiring:

localhost:3001
localhost:3002
localhost:3003
...

Git Worktree Example

Consider three worktrees:

project/
├── .devcontainer/
├── worktree-feature-a/
├── worktree-feature-b/
└── worktree-feature-c/

Each environment runs the same application on port 3000.

Currently, they need different host port mappings:

feature-a → 3000:3000
feature-b → 3001:3000
feature-c → 3002:3000

With hostname-based routing, they could all use the same container port:

feature-a → feature-a.localhost → container:3000
feature-b → feature-b.localhost → container:3000
feature-c → feature-c.localhost → container:3000

This would make parallel worktree development considerably simpler.

Why this belongs in Dev Containers / Docker support

Portless is a useful example of the desired developer experience, but the underlying problem is broader than Portless itself.

The Development Containers specification already describes how development environments expose ports. It would be useful if that abstraction could support service identity and routing independently of host port allocation.

Likewise, Docker/container networking could potentially provide the underlying primitive needed to make a container's service addressable from the host without requiring traditional port publishing.

Ideally, this would allow tools such as:

• VS Code
• devcontainer CLI
• other Dev Container-compatible IDEs
• CI/development automation

to provide the same behavior.

Desired outcome

The goal is not necessarily to make Portless a mandatory dependency.

Rather, the goal is to support a standard mechanism whereby:

1. A container can expose a service on its normal internal port.
2. Multiple containers can expose the same internal port simultaneously.
3. The host can access those services using distinct hostnames.
4. The hostname can be derived from the container, workspace, or worktree identity.
5. No manual host-port allocation is required.
6. The functionality works independently of a particular IDE.

Portless could potentially be one implementation of this, but a native Docker networking mechanism, reverse proxy, or Dev Containers abstraction may be a better long-term solution.

Use case

The primary motivation is running multiple Git worktrees simultaneously while using Development Containers. This is becoming an increasingly useful workflow for parallel feature development, AI-assisted development, code review, and comparing branches. Port conflicts should ideally not be a reason to require per-worktree application configuration.