DevContainer/Q/Do I need an IDE to use a devcontainer in practice

• Do I need an IDE to use a DevContainer in practice?

  • For example, could I make it so that from my terminal, I launch my devcontainer, and then I'm now using the terminal inside my devcontainer?

• Answer

  • Short answer: no, you do not need an IDE to use a devcontainer.
  • A devcontainer is just Docker + conventions + metadata. IDEs like VS Code or JetBrains are merely clients that automate the lifecycle.
  • You can absolutely launch and live inside it from a plain terminal.

  • Mental model

    • A devcontainer is basically:
      • Dockerfile or image
      • optional docker-compose.yml
      • .devcontainer/devcontainer.json (metadata + setup hooks)
    • IDE features = convenience only:
      • build
      • start
      • exec into container
      • mount source
      • forward ports
      • run postCreate/postStart commands
    • All of that can be done manually or via CLI.

  • Option 1 — Pure Docker (simplest, zero tooling)

    • If you already have a Dockerfile:
    • bash

      docker build -t my-dev .
      docker run -it --rm \
        -v $PWD:/workspace \
        -w /workspace \
        my-dev bash

    • Now you are literally inside the container terminal.
    • This is effectively what VS Code does under the hood.

  • Option 2 — Use the official Dev Containers CLI (recommended)

    • There is a first-party CLI from Microsoft: Dev Containers CLI
    • Install:
    • bash

      npm install -g @devcontainers/cli

    • Docs: https://containers.dev/implementors/json_reference/

    • build + start + attach

      • bash

        devcontainer up --workspace-folder .
        devcontainer exec --workspace-folder . bash

      • This drops you into the container shell.
      • Or one-shot:
      • bash

        devcontainer exec --workspace-folder . bash

    • what this gives you automatically

      • It respects:
        • .devcontainer/devcontainer.json
        • features
        • mounts
        • lifecycle hooks (postCreateCommand, etc.)
        • docker-compose
        • forwarded ports
        • env vars
      • So you get the exact same environment your IDE users get, just headless.

  • Option 3 — docker compose (common for multi-service)

    • If your devcontainer uses compose:
    • bash

      docker compose up -d
      docker compose exec app bash

    • Totally fine. Very standard for backend stacks.

  • Practical recommendation (terminal-first workflow)

    • Since you're comfortable with CLI / dev-containers / automation:
    • bash

      alias dcu='devcontainer up --workspace-folder .'
      alias dce='devcontainer exec --workspace-folder . bash'

    • Then:
    • bash

      dcu
      dce

    • Now you're "inside" instantly.

  • When an IDE actually helps

    • Only for:
      • language servers
      • debugging
      • test runners
      • file navigation
      • remote UI
    • None of this is required for the container itself.
    • For CI/CD or AI agents, CLI is actually cleaner.

  • TL;DR

    • You can:
      • build → devcontainer up
      • shell → devcontainer exec bash
    • No IDE needed.
    • Devcontainers are just Docker with conventions.

• Related

  • DevContainer/CLI