Using DevContainers in JetBrains IDEs

DevContainers aren't VS Code-only — JetBrains IDEs support the same spec. This page opens a devcontainer from a JetBrains IDE using the identical committed .devcontainer/, so a mixed-editor team shares one environment definition regardless of who uses which IDE.

Prerequisites

You need a JetBrains IDE with Gateway/dev containers support and an engine.

  • A recent JetBrains IDE (or JetBrains Gateway).
  • A container engine reachable by the IDE.
  • A committed .devcontainer/devcontainer.json.

JetBrains prerequisitesYou need a supporting IDE, the same config, and a container backend.JetBrains IDEdev containers supportSame config.devcontainer/Build + attachIDE backend incontainerVerifytools resolve

Step-by-Step Implementation

  1. Open the project's devcontainer from the IDE (Remote Development → Dev Containers) using the committed config.

  2. Keep the config editor-agnostic — Features and hooks are shared; editor extensions differ.

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu@sha256:PINNED",
  "features": { "ghcr.io/devcontainers/features/java:1": { "version": "21" } },
  "remoteUser": "vscode"
}

  1. Let the IDE run its backend in the container (JetBrains client/backend split, analogous to VS Code).

  2. Verify the toolchain resolves inside the container.

Shared vs editor-specificThe container definition is shared; only editor plugins/settings differ per IDE.Shared (in config)Base imageFeaturesLifecycle hooksEditor-specificVS Code extensionsJetBrains pluginsIDE settings

Common Pitfalls

JetBrains issues are editor-specific customizations or an unreachable engine. The JetBrains model mirrors VS Code's: a thin host client and a backend running inside the container against the real toolchain, driven by the identical .devcontainer/.

JetBrains triageA triage path from an editor-specific failure to a shared environment across IDEs.Does the IDE reach the engine?NOConfigure the container backendDo Features/hooks apply?YESEditor plugins are separateShared env, any IDE

SymptomRoot CauseRemediation
VS Code extensions don't load in JetBrainscustomizations.vscode is VS Code-onlyUse JetBrains plugins for that IDE
IDE can't reach the engineBackend not configuredPoint the IDE at the container engine
Toolchain missingFeature not appliedConfirm the config builds the same Features
Config drift between editorsEditor-specific baked into shared partsKeep base/Features/hooks editor-agnostic

Conclusion

DevContainers are a spec, not a VS Code feature — JetBrains IDEs consume the same .devcontainer/. Keep the base image, Features, and hooks editor-agnostic, and let each IDE layer its own plugins, so a mixed-editor team shares one reproducible environment.

One env, many editorsThe container is shared across IDEs; each editor brings its own plugins.Any IDE getsSame base imageSame FeaturesSame hooksPer IDEIts own pluginsIts own settingsIts own client

FAQ

Do devcontainers only work with VS Code? No. DevContainers are an open spec, and JetBrains IDEs (via Gateway/Remote Development) consume the same .devcontainer/devcontainer.json. The base image, Features, and lifecycle hooks apply identically; only the editor layer — extensions vs plugins — differs per IDE.

What about the customizations.vscode block in JetBrains? It's ignored by JetBrains, since it's VS Code-specific. The container definition (image, Features, hooks) still applies. Configure JetBrains plugins and settings through the IDE for that editor, keeping the shared parts of the config editor-agnostic.

Can a team mix VS Code and JetBrains on one repo? Yes — that's a strength of the spec. Everyone builds the same container from the committed config; each developer's editor adds its own plugins on top. Keep the base image, Features, and hooks free of editor-specific assumptions and both work.