Changelog

Standardized JetBrains plugin management via devcontainer.json

You can now configure JetBrains IDE plugins directly in your devcontainer.json file, enabling fully standardized plugin management across development environments.

This update lets teams pre-install essential plugins from the JetBrains Marketplace using their plugin IDs, ensuring consistent tooling for all team members. It eliminates the need for manual plugin installation, reducing setup time and improving onboarding speed.

Key capabilities

• Plugin installation: Specify plugin IDs from the JetBrains Marketplace for automatic installation.
• Team consistency: Guarantee the same set of plugins across every developer environment.
• Faster onboarding: Remove the manual step of plugin setup for new contributors.

Example configuration

Add plugins to your devcontainer.json using marketplace plugin IDs

1{
2	"name": "My Project",
3	"image": "mcr.microsoft.com/devcontainers/base:ubuntu",
4	"customizations": {
5		"jetbrains": {
6			"plugins": ["org.intellij.plugins.hcl", "com.intellij.kubernetes"]
7		}
8	}
9}

This enhancement removes the previous limitation of non-customizable JetBrains plugin setups, bringing a consistent, repeatable configuration to the entire Dev Container ecosystem.

See the JetBrains documentation to learn more.

HTTPS support for environment services via port sharing

You can now expose environment services over HTTPS using Gitpod’s port sharing feature. This enables secure communication with applications running in your environment, which is ideal for testing HTTPS-only setups or integrating with services requiring encrypted transport.

What’s new?

• UI integration: Select https as the protocol in the port sharing dialog
• CLI support: Use --protocol https with gitpod environment port open to expose environment service ports securely.

Use cases:

• Applications with HTTPS-only redirects or policies
• Streaming APIs requiring secure connections

See port sharing documentation for setup instructions.

Support for multiple region-aware environment classes per project

We’re excited to announce that Gitpod now supports Multiple environment classes for a project, a highly requested feature that enhances reliability and flexibility for organizations.

With this new feature, you can:

• Configure up to 30 environment classes per project, providing built-in regional redundancy
• Set a default environment class while offering alternatives for user selection
• Avoid creating multiple projects for the same repository across different regions
• Benefit from automatic fallback options when a preferred environment class is unavailable

Highlights:

• Enhanced Resilience: Eliminate single points of failure with multiple region support in a single project
• User Flexibility: Users can select their preferred environment class through an intuitive UI
• Intelligent Fallback: When a selected environment class is unavailable, users receive informative error messages and alternative options
• Preference Persistence: The system remembers user preferences for future project launches
• Simplified Project Management: Reduce project proliferation by consolidating multi-region support

Learn how to configure multiple environment classes for a project in our documentation.

Archive & Auto-delete for Environments

We’re excited to announce Archive & Auto-delete, a new feature that automatically manages your environment lifecycle to help reduce storage costs.

With this new feature, you can:

• Automatically archive inactive environments after 7 days of inactivity
• Configure auto-deletion policies to remove archived environments after 1, 2, or 4 weeks
• Set organization-wide retention limits to ensure consistent storage management

Highlights:

• Two-stage lifecycle: Environments are archived first (reversible), then auto-deleted based on your preferences
• Flexible policies: Users can set preferences within organization-defined limits
• Bulk management: Delete all archived environments at once with safety controls
• Visual indicators: Archive badge shows when you have archived environments

This feature helps reduce storage costs while maintaining control over environment retention. Organization-wide auto-delete policies are available for Enterprise customers.

Learn how to configure Archive & Auto-delete in our documentation.

Organization Secrets support

We’re excited to announce that Gitpod now supports Organization secrets, alongside existing User and Project secrets.

With this new feature, you can:

• Configure organization-wide secrets for all Environments in the organization
• Ensure consistent access to shared credentials and API keys for all team members

Highlights:

• Files: Secrets can be mounted as files for complex structures e.g. JSON.
• Environment Variables: Inject secrets as environment variables.

What’s the benefit of files? Files offer better security by avoiding issues like process visibility, crash logging leaks, and unintentional inheritance by child processes.

Learn how to configure organization secrets in our documentation.

VPC endpoint support for Enterprise AWS runners

Enterprise AWS runners now support VPC endpoints, allowing you to connect to Gitpod’s management plane using AWS PrivateLink.

This enhancement provides:

• Increased security - All traffic between your runner and Gitpod stays within AWS’s network backbone
• More reliable connectivity - Eliminates dependency on internet routing and potential connectivity issues
• Compliance ready - Ideal for customers with strict security requirements that prohibit internet-bound traffic

How it works

With VPC endpoints enabled, your Enterprise AWS runner connects to Gitpod’s management plane through AWS PrivateLink:

1. DNS resolution - app.gitpod.io automatically resolves to VPC endpoint IP addresses within your VPC
2. AWS PrivateLink - Traffic flows through Amazon’s network infrastructure via VPC endpoints
3. Seamless integration - No changes required to your existing runner configuration

Getting started

To enable VPC endpoints for your Enterprise AWS runner:

1. Create an Interface VPC Endpoint in your AWS account pointing to Gitpod’s service
2. Configure the endpoint in the same VPC where your runner is deployed
3. Enable DNS names for automatic resolution

The runner dashboard will automatically detect and display “via VPC endpoint” as the connection type once configured.

Learn more about setting up VPC endpoints in our Enterprise runner setup documentation.

Availability: This feature is available to Enterprise customers using AWS runners.

Enterprise AWS runner with AI agent and direct connectivity

Enterprise AWS Runners are now available for Enterprise customers, providing additional capabilities beyond our AWS Runners.

Key features

• Ona AI Agent Integration: AI-powered assistance for automatic Dev Container generation and environment setup
• Direct Connectivity: Bypass Gitpod’s central gateway using your own Network Load Balancer with custom domain and SSL/TLS certificate
• Advanced Networking: Custom VPC configurations with flexible subnet architecture for internal-only or internet-facing deployments
• Flexible Deployment: Deploy behind corporate firewalls with future HTTP proxy support

Availability

Enterprise AWS Runners are exclusively available to Enterprise customers. If you’re on the Enterprise tier, contact your Gitpod account manager to get started.

Coming soon

We’re continuing to enhance the Enterprise Runner with additional enterprise-focused features:

• HTTP Proxy Support: Custom HTTP proxy configuration for environments behind corporate firewalls
• Custom CA Certificate Support: Integration with enterprise certificate authorities and custom certificate chains

Learn more about setting up your Enterprise AWS Runner in our documentation.

Introducing our AI powered Development Environment setup workflow

Ona’s Enterprise SWE agent, Ona agent, now automatically analyzes repositories and generates Dev Container and automations configurations, helping you discover the value of Gitpod much faster.

When developers open an environment without existing Dev Container configurations, Gitpod offers to run our AI powered workflow to generate the configuration automatically.

Ona works reletently, rebuilding and testing the generated configuration until it is confident it gives you a productive setup.

How it works

1. Open an environment in Gitpod without an existing Dev Container configuration
2. Gitpod offers to run our Ona powered setup agent automatically
3. Ona generates devcontainer.json and automations.yaml based on detected dependencies and best practices
4. Review and commit configurations for your team
5. All subsequent environment launches use the optimized configuration

Availability

This feature is available to our enterprise customers. Contact sales.

Gitpod now supports Windsurf editor

Gitpod now supports Windsurf as an editor option for your development environments. Windsurf integrates advanced AI capabilities directly into your development workflow, enhancing productivity through natural language interaction and intelligent code assistance. Experience features like Tab-to-Import, real-time linting, and the powerful Cascade AI assistant to streamline your coding process.

Using Windsurf with Gitpod

To get started with Windsurf in Gitpod, simply select Windsurf from the editor selector dropdown by clicking on the dropdown arrow next to the editor button on the action bar.

Check our documentation for more details on how to use Windsurf with Gitpod.

Faster development environment start times for AWS with Dev Container build caching

Development environment starts are now faster for organizations using AWS Runners with the addition of a new Dev Container build cache Runner setting that uses Amazon ECR.

With this setting enabled you get:

• Faster startup times from minutes to seconds for environments with identical Dev Container configurations
• Reclaimed developer time: Convert 5 minute development environment startup delays into 30-second starts
• Automatically optimized start times performance without any configuration changes required

How does it work?

With the setting enabled on your AWS runner, the first environment created from a project will cache the built Dev Container image. Any changes to the Dev Container configuration will trigger a new cache build on the next environment creation.

• All subsequent starts using the same project will benefit from significantly faster startup times.
• Images are cached for 30 days before automatically expiring to manage storage costs.
• The cache is restricted to users of the project and can be disabled in runner settings if needed.

The build cache speeds up developers workflows and incentivizes developers to use secure short-lived development environments.

Getting started

For new AWS runners: The Dev Container image cache is enabled by default.

For existing AWS runners:

To enable the cache:

1. Update your CloudFormation stack to the latest version that supports the cache
2. Go to Settings → Runners in your Gitpod organization
3. Select your AWS runner and toggle Dev Container image cache to enabled

Note: Upgrading CloudFormation templates from January 2025 or earlier will cause existing environments to become inaccessible due to SSH port changes. Before upgrading, either stop existing environments or manually update the security group after the upgrade. Check the documentation below for more details.

Learn more about configuration, security considerations, and troubleshooting in our Dev Container image cache documentation.

Analyze your organization's Gitpod usage with Insights

We’re excited to announce the launch of Gitpod Insights, a powerful analytics dashboard that helps Enterprise organizations understand and optimize their Gitpod usage and cloud cost.

With Gitpod Insights, you can:

• Analyze environment usage across your entire organization
• Optimize cloud costs by identifying opportunities to right-size resources
• Monitor adoption by tracking active users and environment metrics

The Insights dashboard provides key metrics, including:

• Active Users: Track weekly active users and engagement patterns
• Environment Usage: Monitor total environments and runtime hours
• Resource Distribution: View usage by projects, users, and environment classes

Organization administrators can access Insights directly from the Gitpod dashboard by selecting “Insights” from the left navigation menu. The dashboard offers flexible time range options from daily to yearly views, with automatically adjusted data granularity for optimal analysis.

Learn more about Gitpod Insights in our documentation.

Create development environments from scratch without a Git repository

You can now create development environments from scratch directly from the environment creation modal. This new option allows you to:

• Start with a clean slate using your organization’s default environment image
• Start an environment without requiring a git provider configured on a runner
• Begin development immediately without needing to clone an existing repository

To create a blank environment:

1. Click the “Create Environment” button
2. Select “Create Environment From Scratch”
3. Choose your preferred environment class
4. Click “Create” to start your new environment

Read more about setting your organization’s default environment image here.

Organization policies to manage cost, security and developer experience

Organization policies are now available on our Enterprise plan for organizations, giving administrators centralized controls to manage security, developer experience, and resource costs.

With Organization policies, you can:

• Enhance security - Restrict development environments to only run in the cloud (e.g. not locally) and control which editors developers can use to access your code
• Standardize experience - Create a consistent “golden path” by defining allowed editors and default container images
• Control costs - Set environment timeout limits and maximum environment counts to prevent unexpected resource usage
• Enforce governance - Require environments to be created only from approved projects
• Manage resources - Limit concurrent running environments per user for optimized resource allocation

Discover how to configure Organization Policies in our documentation.

Gitpod now supports VS Code in the Browser

Gitpod now supports VS Code in the browser as well as regular desktop IDEs and editors. Giving developers access to secure development environments without installing any local tools, cloning any source code or managing any dependencies. Development environments that are fully automated and standardized.

With Gitpod and VS Code in the Browser, you can:

• Drive down your developer onboarding times by eliminating all manual setup for your development teams.
• Empower developers to review code easily by launching new development environments running in their browser tab.
• Drive down incident response times with SREs able to do on-the-go incident response direct from their mobiles.
• For secure enterprises, Gitpod paired with a secure browser (like Island) is a secure and performant alternative to traditional VDI.

Getting started

To get started, simply click the “Open in VS Code in the Browser” button when starting a Gitpod environment. Check our documentation for more details on features and capabilities.

Gitpod now supports JetBrains Toolbox App

The JetBrains Toolbox App, a desktop application that helps you manage JetBrains IDEs and projects, now supports remote development in Gitpod environments.

This means you can:

• Use the familiar Toolbox App interface to manage your IDEs in Gitpod
• Connect to Gitpod environments from your desktop
• Install and update JetBrains IDEs in your remote environment

To get started, install the latest JetBrains Toolbox App (2.6+) and connect it to your Gitpod environments. Check our documentation for setup instructions.

Learn more about the JetBrains Toolbox App 2.6 release in the official announcement.

User Secrets support

We’re excited to announce that Gitpod now supports User secrets, alongside existing Project secrets.

With this new feature, you can:

• Configure personal secrets for all of your Environments
• Integrate against 3rd party systems which use Personal Access Tokens to authenticate seamlessly, and even use atuin to have persistent terminal history in your Environments.

Highlights:

• Files: Secrets can be mounted as files for complex structures e.g. JSON.
• Environment Variables: Inject secrets as environment variables.

What’s the benefit of files? Files offer better security by avoiding issues like process visibility, crash logging leaks, and unintentional inheritance by child processes.

Learn how to configure your personal secrets in our documentation.

AWS ECR private registry support

We’re excited to announce that Gitpod now supports AWS ECR private registries with IAM-based authentication when using AWS EC2 runners.

With this new feature, you can:

• Securely access private ECR repositories without manually managing credentials
• Simplify authentication workflows using EC2 runner’s IAM role
• Seamlessly work with private container images in your development environment

This native integration works automatically when:

1. You’re using AWS EC2 runners for your environments
2. Your ECR registry and EC2 runners are in the same AWS account (or have appropriate cross-account access)

Setting up ECR registry access is straightforward through the Project Secrets interface. Simply select Container Registry Basic Auth, enter your ECR registry hostname, and the system will automatically configure runner-native authentication.

Learn how to configure IAM permissions and set up your ECR registry in our documentation.

Linux Host-based Runner

You can now run Gitpod development environments on bare metal Linux infrastructure allowing you to re-use any existing infrastructure and eliminating the requirement to run in the cloud, AWS or on MacOS.

Now you can:

• Accelerate evaluation: Go from zero to fully operational CDE in minutes without AWS credentials or specialized hardware
• Control infrastructure costs: Replace unpredictable cloud spending with fixed, predictable costs using your existing hardware
• Maintain flexibility: Easily scale by adding additional runners or transition to cloud-based solutions as your needs evolve

Ideal for: Small teams conducting a CDE evaluation and/or developers seeking cost-effective setups.

Important: Linux runners operate on single machines without horizontal scaling, unlike the AWS runner. For larger teams (20+ developers) or enterprise-scale deployments consider the AWS Runner. Both AWS and Linux runner types can operate simultaneously within the same organization.

See Runner Introduction and Linux Runner Guide for more.

Domain Verification for SSO

Domain Verification is now available, allowing organization admins to verify ownership of their email domains through DNS TXT records. This feature strengthens security by confirming domain ownership before enabling SSO functionality. This ensures that only authorized users can access your organization using the specified domain.

Learn how to verify your domain from our documentation.

Private container registry support

We’re excited to announce that Gitpod now supports Container Registry Secrets, allowing you to securely authenticate with private container registries.

With Container Registry Secrets, you can now:

• Pull Dev Container images from private registries
• Authenticate with container registries during your development workflow
• Work with private images in your Flex environment without exposing credentials

This feature supports all major container registries using basic authentication, including:

• Docker Hub
• GitHub Container Registry
• GitLab Container Registry
• Azure Container Registry

Setting up Container Registry Secrets is straightforward through the Project Secrets interface. You’ll need to provide the registry hostname, username, and password/token to create the authentication secret.

Learn how to set up and use Container Registry Secrets in our documentation.

Note: This initial release supports basic authentication only. Support for AWS ECR and other authentication methods will be coming in future updates.

Dotfiles Support for Gitpod

Gitpod now supports dotfiles. Dotfiles are a way to customize your developer environment according to your personal needs.

Just configure what dotfiles repository to use and Gitpod will clone and install the dotfiles in every environment, ensuring everything is just the way you like it.

Head over to the documentation to learn how to get started.

Introducing Gitpod SSO

We’re excited to announce that Gitpod now supports Single Sign-On (SSO), making it easier than ever to manage access for your team. With SSO, your team can log in using their existing accounts with trusted Identity Providers like Okta, Azure AD, or Google using OpenID Connect (OIDC) integration.

This feature simplifies authentication by eliminating the need for separate credentials, enhances security by centralizing user management, and streamlines access across your organization. As an admin, you can easily set up SSO in your organization’s settings using your IdP credentials and manage access with just a few clicks.

Learn how to set up SSO in our documentation.

Introducing Gitpod secrets & environment variables

Gitpod now supports secrets and environment variables. Securely store and inject sensitive data such as API keys and access credentials into your development environment. Secrets are encrypted using AES256-GCM and stored securely. Only environments launched from an associated project can access it’s secrets.

Highlights:

• Environment Variables: Inject secrets as environment variables.
• Files: Secrets can be mounted as files for complex structures e.g. JSON.

What’s the benefit of files? Files offer better security by avoiding issues like process visibility, crash logging leaks, and unintentional inheritance by child processes.

See secrets docs for more.

Organization-wide Desktop settings

We now support organization administrators with enhanced control over Gitpod Desktop settings.

What’s new?

• Disable local environments: Restrict Gitpod Desktop usage for local environments, ensuring only self-hosted runners are used.
• Support for self-hosted source control providers: This allows administrators to configure self-hosted source control providers (e.g. GitHub Enterprise or a self-hosted GitLab instance), such that Gitpod Desktop can start environments from repositories hosted on these providers.

Learn more in the Gitpod Desktop organization settings documentation.

Migrate from .gitpod.yml to devcontainer.json

We recently announced that Gitpod now supports Dev Container. To help ease your migration you can run the following command directly from a Gitpod environment:

1gitpod env migrate

See migrating from Gitpod Classic to Gitpod for more.