fix(dx): configure devcontainer to use the host network

[lebalz]

Add "--network=host" to tell docker to re-use the network connections of the host machine. Otherwise the host system can't reach the dev-server inside the devcontainer (what is the default on Windows+WSL2, in which case the browser spins forever loading localhost:3000).

Motivation

Devcontainers are an easy way to get started with the project. The --network=host was missing s.t. it did not work for a Windows+WSL setup.

[netlify]

✅ [V2]

Built without sensitive environment variables

Name	Link
🔨 Latest commit	686eecb
🔍 Latest deploy log	https://app.netlify.com/projects/docusaurus-2/deploys/695663f2e72c36000822267d
😎 Deploy Preview	https://deploy-preview-11640--docusaurus-2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[slorber]

Can you please assume I don't know anything about devcontainers / Docker and tell me why this change improve things and how to test that you are right?

(that's actually true, I did not write this config file)

LLMs disagree with this PR 😅

[lebalz]

I honestly don't know how to prove this to you. It took me more than an hour to figure it out the first time i came accross this issue, so i thought it could be handy for others too. According to the docker docs:

the host network mode for a container, that container's network stack isn't isolated from the Docker host (the container shares the host's networking namespace), and the container doesn't get its own IP-address allocated. For instance, if you run a container which binds to port 80 and you use host networking, the container's application is available on port 80 on the host's IP address.

And the available network modes described here.

Adding --network=host means, the devcontainer can now access the full network of the hostmachine, what could be potentially a security risk (on linux/wsl machines only, since this option is ignored for docker desktop/docker osx). But since it is a dev container and not a production container, it should not be a problem.

Links related to devcontainer setup describing this "workaround":

• Specify docker network(s) in devcontainer.json microsoft/vscode-remote-release#4272 (comment)
• How to make docker in VS Code devcontainer use the host network
• Connecting to the Host Machine's Localhost from a Docker Container: A Practical Guide
• Github Projects using this setting

---

Asking AI depends how it was prompted 😉

GPT-4.1 Review

### Prompt A pr was made to add the runArgs to a devcontainer to work properly for wsl too. Should i accept it? /* (code of the new devcontainer.json) */

---

Response

Short answer:
Yes, you should accept this PR as long as you want to support reliable network access to host services when running the devcontainer in WSL2.

---

Details:
Adding

"runArgs": ["--network=host"]

is a common practice to make networking (especially accessing host ports) work smoothly in WSL2 environments with Docker.

• In WSL2, port forwarding between host and container sometimes fails or is unreliable without "--network=host".
• Using --network=host can also reduce networking issues for tools like Jest tests that may spin up servers and expect to access localhost.

Risks/Considerations:

• --network=host only works on Linux (includes WSL2); it will be ignored/unsupported on Docker Desktop for Windows/Mac (so it does not break, just has no effect).
• If you have processes bound to the same port on the host and container, there could be conflicts, but that's rare in dev environments.

Bottom line:
Merging this change will improve the WSL developer experience and should not negatively impact other environments.

Action:
✅ Accept the PR.

Anyway, i'm fine adding this config for my local dev setup.

[slorber]

Adding --network=host means, the devcontainer can now access the full network of the hostmachine, what could be potentially a security risk (on linux/wsl machines only, since this option is ignored for docker desktop/docker osx). But since it is a dev container and not a production container, it should not be a problem.

In my experience, these kind of things are not to take so lightly. People using Docker expect the configs we provide to reduce risk by default. This new default would opt-out of one layer of security. In case of a vulnerability in our dev server (including transitive dependencies), this would likely expose the vulnerability more broadly. This already happened in the past ,see for example this RCE vulnerability in React Native dev server: GHSA-399j-vxmf-hjvr

Since I'm not 100% sure about the risk of this change, so I'd rather not merge it. I understand it adds friction for some users, but I'd rather keep the friction and being more secure by default. This is also why we don't bind to 0.0.0.0 by default. See also #11005 (comment)

If someone come up with a different solution that doesn't relax security, I'd be happy to consider it.