Dev Containers & Nix Environments

Dev Containers & Nix Environments provides configuration guidance for reproducible development environments. It covers container-based workspaces, Nix development shells, and Devbox as a simpler interface to Nix. The goal is to reduce environment drift while keeping development tool versions aligned across a team and close to production.

Dev Container configuration brings together a base image, language features, forwarded ports, setup commands, and editor settings. A Docker Compose workspace connects an application service with PostgreSQL and Redis, while a custom Dockerfile adds system packages and development tools. Nix Flakes defines a development shell containing language runtimes, container and Kubernetes utilities, cloud tooling, and database packages. Devbox expresses packages, environment variables, initialization hooks, and project scripts in a JSON configuration.

Use this skill for developer onboarding, shared toolchains, local environments that resemble CI, or disposable project workspaces. Its comparison distinguishes the lower learning curve of Dev Containers and Devbox from the greater complexity of Nix Flakes. Container workspaces support VS Code and JetBrains, while Nix and Devbox workflows operate through a terminal.

Do not assume a lockfile guarantees offline operation: all required dependencies and artifacts must already be available locally. Inspect features, lifecycle commands, shell hooks, direnv configuration, and dependency installers before activating them because they execute code. Avoid privileged Docker-in-Docker and host sockets for untrusted repositories, and do not pass production credentials into development by default.

The working inputs are workspace configuration, package choices and versions, project scripts, and locked dependencies. The resulting environment can expose application and database ports, configure editor extensions, initialize dependencies, and provide commands for development, tests, or database management. A Nix development shell is entered with:

nix develop

The development-shell configuration does not define the separate outputs needed by Nix build or run operations. Devbox can also generate a Dockerfile or direnv integration. Automatic activation requires reviewing and allowing the environment configuration rather than treating directory changes as inherently safe.

The skill connects Dev Containers with Docker Compose and GitHub Codespaces. It covers GitHub Actions workflows using Devbox or Nix, with caching through Cachix or the GitHub cache. Explicit tool versions and committed flake.lock or devbox.lock files support reproducibility.

Troubleshooting addresses initial Nix build latency, Docker disk space and rebuilds, packages missing from Nixpkgs, and direnv shell hooks. A hash mismatch requires verifying publisher, version, and integrity; deleting or recreating state is not an acceptable substitute for that verification. Moving downloaded installers likewise require review before use.

This documentation-only skill is adapted from BagelHole/DevOps-Security-Agent-Skills under MIT. Upstream scripts and templates are not bundled. Confirm the target, impact, and rollback plan before applying environment changes, and obtain explicit approval before production deployment.