Running Antigravity in a DevContainer: A Setup Your Whole Team Can Share

When you start collaborating with others on Antigravity, you hit a familiar set of problems: "works on my Mac, breaks on the new teammate's Windows," "dependency conflict broke another project." I lost the first week of an external collaboration to exactly this.

A DevContainer lets you declare the Antigravity environment as a Dockerfile and freeze it in version control. New teammates open the repo in VS Code, click "Reopen in Container," and get an identical environment. This guide walks through the .devcontainer setup I use in production, starting from minimum and building up.

Minimum Viable Setup: Just Get It Running

Two files are enough to start: .devcontainer/devcontainer.json and .devcontainer/Dockerfile.

// .devcontainer/devcontainer.json
{
  "name": "Antigravity Dev",
  "build": {
    "dockerfile": "Dockerfile"
  },
  "features": {
    "ghcr.io/devcontainers/features/git:1": {},
    "ghcr.io/devcontainers/features/github-cli:1": {}
  },
  "customizations": {
    "vscode": {
      "extensions": [
        "ms-python.python",
        "ms-python.vscode-pylance",
        "google.antigravity"
      ],
      "settings": {
        "python.defaultInterpreterPath": "/usr/local/bin/python",
        "editor.formatOnSave": true
      }
    }
  },
  "postCreateCommand": "pip install -r requirements.txt && antigravity init",
  "remoteUser": "vscode"
}

# .devcontainer/Dockerfile
FROM mcr.microsoft.com/devcontainers/python:3.12
 
# Install the Antigravity CLI
RUN curl -fsSL https://antigravity.google.com/install.sh | bash
 
# Extra tools commonly needed during development
RUN apt-get update && apt-get install -y --no-install-recommends \
    jq \
    httpie \
    && rm -rf /var/lib/apt/lists/*
 
WORKDIR /workspace
 
# Cache the Python deps layer separately so rebuilds stay fast
COPY requirements.txt /tmp/
RUN pip install --no-cache-dir -r /tmp/requirements.txt
 
# Pre-install Antigravity plugins
RUN antigravity plugins install agentkit lm-link

Open the repo in VS Code, run Cmd+Shift+P → Dev Containers: Reopen in Container. The first build takes a few minutes; subsequent reopens are nearly instant from cache.

Handling Credentials Safely

This is where many people get stuck. Antigravity needs API keys and OAuth tokens, but baking them into the Dockerfile leaves them in image layers — and a stray push exposes them.

I use one of three patterns.

Pattern 1: Forward Local Environment Variables (Solo Dev)

Use remoteEnv in devcontainer.json to pass host environment variables into the container.

{
  "remoteEnv": {
    "ANTIGRAVITY_API_KEY": "${localEnv:ANTIGRAVITY_API_KEY}",
    "OPENAI_API_KEY": "${localEnv:OPENAI_API_KEY}"
  }
}

Set export ANTIGRAVITY_API_KEY=YOUR_API_KEY on the host (in ~/.zshrc for example), and the same value reaches the container.

Pattern 2: Mount Host Config Files (Recommended)

Avoid putting keys in the container at all — bind-mount the host's auth files read-only.

{
  "mounts": [
    "source=${localEnv:HOME}/.config/antigravity,target=/home/vscode/.config/antigravity,type=bind,consistency=cached,readonly"
  ]
}

antigravity login writes credentials to ~/.config/antigravity on the host. Mounting that directory means destroying the container loses nothing, and multiple projects can share the same credentials.

Pattern 3: Fetch from a Secrets Manager (Team Dev)

For team development, fetch from HashiCorp Vault, AWS Secrets Manager, or similar at container startup.

# .devcontainer/postCreate.sh
#!/bin/bash
set -e
 
# Fetch via AWS CLI
export ANTIGRAVITY_API_KEY=$(aws secretsmanager get-secret-value \
  --secret-id antigravity/dev/api-key \
  --query SecretString --output text)
 
# Persist as env var (container only)
echo "export ANTIGRAVITY_API_KEY=$ANTIGRAVITY_API_KEY" >> ~/.bashrc
echo "export ANTIGRAVITY_API_KEY=$ANTIGRAVITY_API_KEY" >> ~/.zshrc

Wire this from devcontainer.json's postCreateCommand as bash .devcontainer/postCreate.sh.

GPU Passthrough for Agent Workloads

If you run local LLMs (Ollama, etc.) alongside Antigravity, you need GPU passthrough. Configuration differs between Docker Desktop (macOS/Windows) and Linux native.

Linux (NVIDIA GPU)

{
  "runArgs": [
    "--gpus=all",
    "--shm-size=8gb"
  ],
  "containerEnv": {
    "NVIDIA_VISIBLE_DEVICES": "all",
    "NVIDIA_DRIVER_CAPABILITIES": "compute,utility"
  }
}

The host needs nvidia-container-toolkit installed first.

# Ubuntu
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit
sudo systemctl restart docker

macOS (Apple Silicon)

Apple Silicon does not currently support GPU passthrough from Docker. The practical workaround: run Ollama on the host and connect from inside the container via host.docker.internal:11434.

{
  "runArgs": ["--add-host=host.docker.internal:host-gateway"]
}

# From code inside the container
import ollama
client = ollama.Client(host="http://host.docker.internal:11434")

File Performance Tuning

DevContainers handling lots of files can feel sluggish at default settings, especially on macOS.

{
  "mounts": [
    "source=${localWorkspaceFolder},target=/workspace,type=bind,consistency=cached"
  ]
}

Adding consistency=cached makes host-to-container reads dramatically faster (3–5x perceived improvement on Mac). Container-to-host writes get slightly slower in exchange, so put build artifacts on a Named Volume instead.

A README That Onboards New Members in Under 10 Minutes

Once DevContainer is set up, this README pattern keeps onboarding short:

## Development Environment Setup
 
### Prerequisites
- VS Code (latest)
- Docker Desktop (Mac/Win) or Docker Engine (Linux)
- VS Code extension: Dev Containers
 
### Steps
1. Clone the repo
2. On the host: `cp .env.example .env` and fill in API keys
3. Open the repo in VS Code
4. `Cmd+Shift+P` → `Dev Containers: Reopen in Container`
5. Wait 5–10 minutes for the initial build
6. In the terminal, `antigravity --version` should work
 
### Common Issues
- "Build fails": raise Docker Desktop memory allocation to 8GB+
- "Auth error": run `antigravity login` on the host first, then reopen the container

Honest Take: When to Use a DevContainer

To be candid, for a small solo project, DevContainer is overkill. I reach for it only when one of these applies:

• Two or more people will work on the codebase (especially across OSes)
• Production runs Linux but development is on macOS / Windows
• The project handles sensitive API keys you do not want sitting on hosts
• You want your local environment to match CI exactly

If your local venv is working and nothing hurts, you do not need to retrofit DevContainer for its own sake. "Possible to do" and "worth doing" are different questions.

Next Steps

Once your DevContainer config stabilizes, the same .devcontainer works with GitHub Codespaces — that means external collaborators can start from a browser without installing Docker at all. The onboarding window shrinks even further.