Development Container Features

The docker-outside-of-docker Feature connects to the host's Docker (or Moby) engine. Users should be aware of the following constraints:

• Engine Compatibility: Designed for Docker or Moby. Other container engines are untested.
• Architecture: The host and the container must share the same chip architecture (e.g., you cannot use an emulated x86 image on Apple Silicon via Docker Desktop).
• Bind Mounts: By default, this approach does not enable bind mounting the workspace folder and cannot support folders outside the workspace. If you require bind mounting, consider using the Docker-in-Docker Feature instead.
• VS Code Volumes: The ${localWorkspaceFolder} variable is unavailable when using the Clone Repository in Container Volume command in the VS Code Dev Containers extension.

The Nix Dev Container Feature supports two installation models. Choose based on your container's user configuration and security requirements.

Multi-User (Default)

• Pros: Works with any user (including root) and is resilient to UID/GID changes.
• Cons: Requires Nix 2.11+; requires the container to run as root OR include sudo for the remoteUser. If the container is not running as root, automated nix-daemon startup requires passwordless sudo.

Single-User

• Pros: Does not require root or sudo in the image.
• Cons: Only works for the specific user defined in remoteUser (or the auto-detected user). If that user's UID/GID changes, Nix will stop working for them.

When using this feature, be aware of the following constraints:

• Host Engine Requirement: The host must be running Docker or an OSS Moby container engine. It is not tested with other container engines.
• Architecture Match: The host and the container must share the same chip architecture (e.g., you cannot use an emulated x86 image on an Apple Silicon Mac).
• Bind Mount Restrictions: By default, this feature does not enable bind mounting the workspace folder. It cannot support folders outside of the workspace folder. If you need full bind mount support, consider using the Docker-in-Docker Feature.

When referencing a Feature in devcontainer.json, you can control which version of the Feature itself is used by appending a version label to the Feature ID. This follows semantic versioning conventions:

• Major version: feature-id:1 (implicitly defaults to :latest if no label is provided)
• Minor version: feature-id:1.0
• Patch version: feature-id:1.0.0

"features": {
    "ghcr.io/devcontainers/features/go:1.0.0": {
        "version": "1.18"
    }
}

The desktop uses Fluxbox as its window manager. You can access the application menu by right-clicking anywhere on the desktop.

To apply custom configurations:

1. Place your configuration files in the $HOME/.fluxbox directory of the user connecting to the container.
2. If you include custom content in your base image or Dockerfile at this location, the Feature will automatically prioritize your files over the default configuration.

The Ruby Feature installs components using the following directory structure and permissions:

• Ruby Installations: Located under /usr/local/rubies/<version> (managed by ruby-build).
• Default Ruby: The active Ruby version is accessible via the /usr/local/rubies/current symlink. This path is automatically added to the PATH environment variable via containerEnv.
• ruby-build: The ruby-build tool is cloned to /usr/local/share/ruby-build and symlinked to /usr/local/bin/ruby-build, allowing you to install additional Ruby versions manually later.
• Permissions: A shared ruby group owns the /usr/local/rubies directory. The configured non-root user is automatically added to this group, enabling gem install to write to the active Ruby tree without requiring sudo.

The desktop uses the Fluxbox window manager. You can customize it by providing your own configuration files in the $HOME/.fluxbox directory of the user connecting to the container.

If you include custom files in this location within your base image or Dockerfile, the Feature will automatically prioritize them over the default configuration.

Usage Tips:

• Right-click anywhere on the desktop to see the application menu.
• Any GUI-based commands executed in the VS Code terminal will automatically open on the desktop.

This feature supports two installation models. Choosing the right one depends on your container's user configuration and security requirements.

Multi-User (Default)

• Pros: Nix can be used by any user (including root); works even if user UIDs/GIDs change.
• Cons: Requires Nix 2.11+; the container must run as root (with a non-root remoteUser) or include sudo. Automated daemon startup requires passwordless sudo if the container user is not root.

Single-User

• Pros: Does not require the container to run as root or include sudo in the image.
• Cons: Only works for the specific remoteUser or auto-detected user; if that user's UID/GID changes, Nix will stop working for them.

This feature installs the conda package manager. You can install additional packages via Conda, which will be downloaded from the Anaconda repository or other configured repositories. To use alternative repositories, you must configure Conda channels.

Licensing Note: Use of the Anaconda repository is subject to the Anaconda Terms of Service. While some organizations may require a commercial license, all users are permitted to use the Anaconda Repository when using GitHub Codespaces or GitHub Actions.

The Conda feature includes the conda package manager from the Anaconda Distribution.

Licensing Note: Access to the Anaconda repository is subject to the Anaconda Terms of Service. While some organizations may require a commercial license, all users are permitted to use the Anaconda Repository when using GitHub Codespaces or GitHub Actions.

To use alternative repositories, you must configure Conda channels.

The docker-in-docker Dev Container Feature is based on the official Moby dind wrapper script and has the following constraints:

• Host Engine: It is designed to work when the host is running Docker or the Moby container engine. Compatibility with other container engines is untested.
• Architecture Matching: The host and the container must run on the same chip architecture. For example, you cannot use this feature with an emulated x86 image on an Apple Silicon Mac (e.g., using FROM --platform=linux/amd64 ...).