Gitpod: Cloud Development with AI Rules
Gitpod: cloud development environments that launch from a git URL. Click a button: a workspace opens with the repository cloned, dependencies installed, and the development server running. Gitpod differs from GitHub Codespaces: it works with GitHub, GitLab, and Bitbucket (not just GitHub), uses .gitpod.yml for configuration (not devcontainer.json, though devcontainer support is available), and runs workspaces on Gitpod's infrastructure (or self-hosted on your cloud).
AI rules in Gitpod: the CLAUDE.md file is in the repository and available in the workspace automatically. AI tools: need to be installed via .gitpod.yml tasks. Extensions: configured in the .gitpod.yml vscode section. The setup: similar to Dev Containers but uses Gitpod's configuration format. For teams that use Gitpod as their primary development environment: configuring AI tools in .gitpod.yml ensures every workspace starts AI-ready.
The Gitpod advantage: prebuilds. Gitpod pre-builds the workspace in the background when the repository changes. When a developer opens a workspace: dependencies are already installed, tools are already configured, and the environment is ready in seconds. For AI tools: the prebuild installs Claude Code CLI and configures extensions. The developer: starts coding with AI rules immediately.
Step 1: .gitpod.yml Configuration for AI Tools
The .gitpod.yml file: defines the workspace configuration. Add AI tool installation to the init task (runs during prebuild) and extension configuration to the vscode section. Example: tasks: - init: npm install -g @anthropic-ai/claude-code. vscode: extensions: - GitHub.copilot - GitHub.copilot-chat. The init task: runs during the prebuild, so Claude Code is already installed when the developer opens the workspace.
Environment variables: Gitpod supports workspace-level and user-level environment variables. For API keys: set as a user-level variable in Gitpod settings (gitpod.io/variables). This is the Gitpod equivalent of Codespaces secrets. The variable: available in every workspace without per-workspace configuration. Set the scope to the repository or the entire organization. AI rule: 'Set ANTHROPIC_API_KEY as a Gitpod user variable. Every workspace: has the key automatically. No per-workspace configuration.'
Custom Docker image: for advanced setups, define a custom Dockerfile in .gitpod.yml: image: file: .gitpod.Dockerfile. The Dockerfile: pre-installs AI tools, language runtimes, and development dependencies. The prebuild: builds the image once. Every workspace: uses the pre-built image. This is faster than installing tools in the init task because the image is cached. AI rule: 'For large projects with many tools: use a custom Dockerfile. For simple projects: init task is sufficient.'
Go to gitpod.io/variables. Add: Name: ANTHROPIC_API_KEY, Value: your key, Scope: your-org/* (applies to all repositories in your org). Done: every Gitpod workspace for any repo in your org has the API key. You set it once. It works in every workspace. No per-repo configuration. No per-workspace setup. The Gitpod equivalent of GitHub Codespaces secrets — but with flexible scoping (per repo, per org, or global).
Step 2: Prebuilds for Instant AI Workspaces
Gitpod prebuilds: run the init tasks when the repository changes (on push to the default branch). The result: a pre-built workspace image with dependencies installed and tools configured. When a developer opens a workspace: Gitpod loads the pre-built image. The workspace: ready in 5-15 seconds instead of 2-5 minutes. For AI tools: Claude Code is pre-installed, dependencies are cached, and the workspace is immediately productive.
Enable prebuilds: in .gitpod.yml, add: github: prebuilds: master: true pullRequests: true pullRequestsFromForks: false addComment: false addBadge: true. This enables prebuilds for pushes to master and for pull requests. The prebuild: runs the init task, creating a snapshot of the ready workspace. Pull request prebuilds: ensure PR review workspaces are also instant.
Prebuild with AI validation: add rule file validation to the init task. The init task: installs dependencies, installs AI tools, AND validates CLAUDE.md. If validation fails during the prebuild: the prebuild is marked as failed. The team: notified that the prebuild failed due to invalid rules. Fix the rules: the next prebuild succeeds. AI rule: 'Prebuild validation: catches rule issues before any developer encounters them. The prebuild: is the first consumer of your rules after every repository change.'
You push code to main. Gitpod: automatically runs the prebuild (install dependencies, install AI tools, validate rules). 5 minutes later: you open a workspace. Instead of waiting for the init task: the workspace loads from the prebuild snapshot. Ready in 5-15 seconds. The prebuild: happened in the background while you were doing other work. You never waited. This is why prebuilds are the killer feature for AI-assisted development on Gitpod.
Step 3: Gitpod Workflow for AI-Assisted Development
Opening a workspace: navigate to the repository on GitHub/GitLab, prefix the URL with gitpod.io/# (or use the Gitpod browser extension button). Gitpod: opens a workspace with VS Code in the browser (or connects to your desktop VS Code via SSH). The workspace: pre-built, AI tools installed, rules loaded. The developer: starts their first AI prompt within 30 seconds of clicking the button.
Multi-repository workspaces: Gitpod supports multi-root workspaces (multiple repositories in one workspace). For monorepo or multi-service development: each repository has its own CLAUDE.md with rules specific to that service. The AI tool: reads the CLAUDE.md closest to the file being edited. The developer: works across services with the correct rules applied per service. AI rule: 'Multi-repo workspaces: each repo has its own rules. The AI context switches automatically based on which file is open.'
Ephemeral workspaces: Gitpod workspaces are ephemeral — they can be stopped and restarted, but changes not committed to git are lost when the workspace is deleted. This is actually an advantage for AI rules: the workspace always starts from the repository's current state. No configuration drift. No stale local settings. Every workspace: a fresh start with the latest rules. AI rule: 'Ephemeral workspaces = zero configuration drift. Every workspace starts clean. The repository is the single source of truth for everything: code, rules, and tool configuration.'
Gitpod workspaces are designed to be ephemeral: stop → start (changes preserved). Stop → delete (changes lost unless committed). A developer makes local CLAUDE.md edits to test a rule change. Workspace is deleted. The edits: lost. Rule: always commit rule changes to the repository — do not rely on the workspace persisting. The repository is the only durable storage. This is actually a feature for AI rules: every workspace starts with the repository's rules, never with stale local modifications.
Gitpod AI Rules Summary
Complete Gitpod + AI rules setup.
- .gitpod.yml: init task for Claude Code installation. vscode section for Copilot extensions
- API keys: Gitpod user variables (gitpod.io/variables). Available in every workspace automatically
- Custom Dockerfile: pre-install AI tools for faster workspace launches. Optional for simple setups
- Prebuilds: init tasks run on repository changes. Workspaces ready in 5-15 seconds, not 2-5 minutes
- Prebuild validation: validate CLAUDE.md during prebuild. Catch rule issues before developers encounter them
- Multi-repo: each repository has its own CLAUDE.md. AI applies correct rules per file context
- Ephemeral: workspaces start fresh every time. Zero configuration drift. Repository is source of truth
- Workflow: prefix URL with gitpod.io/# → AI-ready workspace in 30 seconds