The first 30 minutes of a new teammate's day getting eaten by environment setup is a familiar scene. When I first started using Antigravity, I had a stretch where the same agent prompt produced different outputs across team members because of small toolchain version drift on each laptop.
Pairing Antigravity with DevContainers has more or less eliminated that class of problem for me. Wrap the whole project in a Docker container and a new teammate just clicks "Reopen in Container" once in VS Code and lands inside the same environment I have. This article walks through the configuration I run with and the corners I tripped over getting there.
Why Antigravity and DevContainers fit together well
An Antigravity project tends to involve more than the source code: agent configs (.antigravity/), tool scripts, dependency manifests, credential bootstrap, all touching each other. To stop the "works on my machine" trap, locking those into a container is the simplest answer.
Containerizing buys you:
- Pinned Node and Python versions
- Globally installed tools (
gcloud,gh,direnv) reliably present - Predictable working directory and environment variables when agents run
- Insulation from host OS variation across macOS / Linux / WSL
This matters extra for a tool like Antigravity that delegates execution to agents. Agents accidentally probing host-specific paths becomes much rarer.
A minimal .devcontainer/devcontainer.json
Start small. Drop this at the project root.
{
"name": "Antigravity Project",
"image": "mcr.microsoft.com/devcontainers/base:ubuntu-24.04",
"features": {
"ghcr.io/devcontainers/features/node:1": {"version": "20"},
"ghcr.io/devcontainers/features/python:1": {"version": "3.12"},
"ghcr.io/devcontainers/features/github-cli:1": {}
},
"postCreateCommand": "npm install && pip install -r requirements.txt",
"remoteUser": "vscode",
"mounts": [
"source=${localEnv:HOME}/.config/gcloud,target=/home/vscode/.config/gcloud,type=bind,consistency=cached"
],
"customizations": {
"vscode": {
"extensions": [
"google.gemini-cli",
"ms-azuretools.vscode-docker"
]
}
}
}This brings up Ubuntu with Node 20, Python 3.12, and GitHub CLI. The mounts line passes through your gcloud credentials, so gcloud auth list works out of the box inside the container.
Antigravity-specific additions
This is enough to get going, but a serious Antigravity setup wants a few more knobs.
Install the Antigravity CLI. Move setup into a script so it can grow.
"postCreateCommand": "bash .devcontainer/setup.sh"And setup.sh:
#!/bin/bash
set -e
# Node packages
npm ci
# Python deps
pip install -r requirements.txt
# Antigravity CLI
curl -fsSL https://antigravity.google/install.sh | bash
echo 'export PATH="$HOME/.antigravity/bin:$PATH"' >> ~/.bashrc
# Validate shared agent configs
antigravity agents validate
echo "Setup complete."The trick here is the antigravity agents validate call. When somebody commits a broken agent config, the schema check trips on every teammate's container creation, which catches the problem early.
Handling API keys and tokens
Authentication is always the awkward part. You cannot commit secrets but you do not want everyone typing them in by hand either.
I run a three-layer approach.
Layer 1: a local .env.local (gitignored) loaded by the container.
"runArgs": ["--env-file", ".env.local"]Layer 2: shared team auth via Google Secret Manager or Doppler — fetched in postCreateCommand and exported as environment variables.
Layer 3: personal API keys for individual experimentation in .env.personal, owned by each developer.
This keeps somebody's personal key from accidentally being used in someone else's verification run.
Pin agent model versions
Once .antigravity/agents/*.yaml is in the repo, also pin the model version it depends on.
# .antigravity/agents/reviewer.yaml
name: reviewer
model: gemini-3-flash-2026-04
# ^ specific version, not "gemini-3-flash-latest"Using latest means a Google-side update can change behavior under your team without warning. Pin until you intentionally upgrade.
VS Code and Antigravity extensions
customizations.vscode.extensions is where you bake in editor setup. The extensions I keep in an Antigravity project:
"customizations": {
"vscode": {
"extensions": [
"google.gemini-cli",
"google.antigravity-vscode",
"ms-azuretools.vscode-docker",
"redhat.vscode-yaml",
"github.vscode-pull-request-github"
],
"settings": {
"yaml.schemas": {
"https://antigravity.google/schemas/agent.json": ".antigravity/agents/*.yaml"
}
}
}
}The yaml.schemas line gives you completion and error highlighting while editing agent configs. This alone removes most of the time lost to typos in property names.
Trip-up #1: file ownership
When using Docker on a Linux host, files created inside the container can come out owned by root, which makes editing from the host annoying.
In addition to remoteUser, turn on updateRemoteUserUID.
"remoteUser": "vscode",
"updateRemoteUserUID": trueThis aligns the container's vscode user with your host UID.
Trip-up #2: slow bind mounts on macOS
macOS bind mounts are slow with lots of small files. consistency: cached measurably improves the feel.
"workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind,consistency=cached",
"workspaceFolder": "/workspace"Heavy write directories like node_modules are good candidates for named volumes instead of bind mounts.
Trip-up #3: GitHub Codespaces compatibility
DevContainers also run on GitHub Codespaces, but with constraints. Host-path mounts like ${localEnv:HOME} do not work in Codespaces.
For both environments, prefer a postCreateCommand that branches on environment.
# setup.sh
if [ -n "$CODESPACES" ]; then
# Codespaces: pull credentials from secrets
gcloud auth login --cred-file=/tmp/gcp-key.json
else
# Local: rely on the mounted gcloud directory
echo "Using mounted gcloud credentials"
fiRollout to the team
Forcing DevContainers on the whole team day one usually backfires. The cadence I followed:
Week 1: opt-in. Commit the config but leave existing local setups alone.
Week 2: I move fully to DevContainer. Fix any issues immediately. Slack-announce as the recommended path.
Week 3: new teammates start DevContainer-only. Strongly encourage existing members to migrate.
Week 4: archive the old local-setup docs and make DevContainer the canonical procedure.
At this pace nobody gets left behind.
What to try first
If you are starting now, take an empty Antigravity project, drop in the minimal devcontainer.json from the top of this article, and run a single agent inside the container. That is enough to see the appeal. Then layer in API key management, agent validation, and editor extensions as you go. About a week of incremental work and you have a setup the whole team can lean on.
A day's investment up front, and a year of saved onboarding pain.