Changelog

Simplified repository management

We’ve simplified how you configure repositories in Gitpod by replacing projects with repository settings, and introduced a new prebuilds activity page that aggregates all prebuilds across all repositories in your organization in a single view.

The new repositories page is using a compact list for all the repositories you’ve added to your organization, and you can now glance over the list and quickly filter for repositories that have prebuilds enabled. Repository settings also come with an intuitive settings layout, following the layout of other settings in Gitpod.

The organization-wide prebuilds page now lists all prebuilds that are happening in your organization and lets you filter prebuilds for a specific repository, as well as filter by status.

Both pages are accessible to all organization members, except the ones with collaborator access. Learn more in our documentation.

Collaborator Role for restricted access to Gitpod

Organization owners can now invite individuals as Collaborators to an organization with restricted access to only start workspaces. Collaborators cannot access any other organization resources like usage, members, or projects. To change the role of a member to a Collaborator, visit the members page in your organization.

See Members for more.

Restrict the Workspace classes available in your Gitpod Organization

Organization owners can now restrict the workspace classes that are available to their organization. Restricting workspace classes can be useful for preventing unexpected costs, or simply for removing workspace classes which are not useful in a specific organization’s context. Members of the organization will then no longer see the workspace class as an option in the various Gitpod interfaces.

See Workspace Classes and Organization Policies for more.

Take Gitpod to your local command line

Workspaces that include all the tools developers need to start work and become ready-to-code are even more accessible and flexible, with the new Gitpod CLI for personal workspace management.

For developers you can now start and manage workspaces directly from your terminal, composing with your other favorite command-line utilities, and writing custom scripts.

For platform engineers you can now incorporate the CLI into your own internal developer platform to bring ready-to-code workspaces to your developers through deeper integrations.

Please note: The Gitpod CLI is an additional CLI to the existing CLI (gp) that is available in all Gitpod workspaces. In future these two experiences will be aligned.

Getting Started

To get started, install the CLI with the following command:

bash

brew install gitpod-io/tap/gitpod

Everything installed? Let’s login and start using the CLI to create and manage workspaces.

Login to your Gitpod host

Using browser-based or token-based authentication:

1. gitpod login to login to Gitpod.
2. gitpod login --host="yourcompany.gitpod.cloud" for Gitpod Enterprise.
3. gitpod login --token <access-token> to authenticate with an Access Token.

Note: Access tokens are generated from your User Settings in the Gitpod dashboard.

Tip: Use gitpod whoami to see your authenticated organization, host, etc.

Create and open a workspace in your editor

bash

gitpod workspace create https://github.com/gitpod-io/empty --open

Or, create and open a workspace with SSH

bash

gitpod workspace create https://github.com/gitpod-io/empty --ssh

Tip: Use --editor to override your default editor selection. Use gitpod workspace list-editors to see a list of possible editor options.

Managing workspaces

There’s a lot more you can do with the Gitpod CLI including listing and deleting workspaces. We suggest you explore the CLI using the help pages. Start by typing gitpod to start exploring.

See Gitpod CLI for more.

Frequently Asked Questions

Can the CLI be used in automation? Yes. You can install and use the Gitpod CLI in CI pipelines, bash scripts or other automation by logging in via access token based authentication.

Does this mean Gitpod now has two CLIs? Gitpod will continue to support the gp CLI within Gitpod workspaces alongside this new Gitpod CLI. The gp CLI will now be referred to as the “workspace CLI”. We intend to merge these two CLIs in future, but not today.

How does this new Gitpod CLI relate to the existing ‘Local Companion’? The Local Companion tool will now no longer be supported by Gitpod. Since we originally announced the Local Companion, we have since introduced other features which allow you to achieve similar behaviors previously offered by the Local Companion. See the Local Companion documentation for more.

Is the CLI compatible with all Gitpod IDEs and editors? Yes. The CLI allows you to open workspaces directly through SSH, the Browser Terminal, VS Code Desktop and Browser, or with any of the JetBrains IDEs.

You can now specify the exact SCM hosts in your Gitpod browser extension settings

We recently updated the browser extension to allow self-hosted source control management (SCM) like Bitbucket and GitLab. We implemented this change by updating the browser extension to run on all hosts, which caused concern for some of our users. We heard your feedback, and have now updated the extension so that you can customize the hosts where the Gitpod browser extension should run. The latest browser extension version enables (by default) the following hosts: github.com, gitlab.com and bitbucket.org. You can now also to opt-in to enable additional hosts, such as a self-hosted SCM. Here’s what you need to know:

1. Users who already have the extension installed - Any previously allowed hosts will persist, including those who allowed all websites. You can now update the opt-in hosts in your browser extension settings.
2. Users who do not have the extension installed - Install the extension as normal, and opt-in to enable any relevant SCM hosts, if self-hosted support is required.

For more, see the browser extension documentation.

Local Companion (as an SSH connection method) for VS Code Desktop is now retired

Over the past few months we have continued to introduce more stable and reliable methods of connecting to workspaces via SSH. The previously supported method of establishing an SSH connection using the Local Companion app is now retired. No action is required by users, VS Code will automatically switch to the new connection method. For troubleshooting, consult our guide.

Please ensure that your Gitpod VS Code Extension, Remote SSH extension and VS Code is up-to-date. You can learn more about these connection methods in connecting to VS Code Desktop.

Please note: This deprecation does not apply to the Local Companion App.

Blazing fast workspace starts are now easier than ever, with simplified default settings for prebuilds

Enabling prebuilds to increase the performance of workspace starts should be simple. With prebuilds enabled you unlock more of the developer velocity potential of Cloud Development Environments for your organization.

To make prebuilds simpler and easier to use, we’ve drastically simplified the default prebuild settings. We’ve removed the previous settings for “incremental prebuilds”, “use last successful prebuild” and “cancel prebuild on outdated commits” and instead created a set of simpler and more intuitive defaults that just work™.

If you do need more advanced fine-tuning of your prebuild settings, you can also now filter when your prebuilds are triggered across all of your git providers (GitHub, GitLab and Bitbucket) through project settings.

Simplified default prebuild settings

The previous prebuild settings for “incremental prebuilds”, “use last successful prebuild” and “cancel prebuild on outdated commits” have now been removed and simplified. By default, all prebuilds:

1. Skip 20 commits by default (if no previous setting was applied)
2. Search the past 100 commits for a successful prebuild to base a workspace on
3. No longer prevent users from accessing workspaces if a prebuild is executing

These settings should work well for most projects out-of-the-box, without the need to apply additional filters. By increasing the Commit Interval you can balance freshness of prebuilds against the frequency of their execution.

Note: These setting defaults apply to all new and existing projects automatically.

Branch filters for prebuilds on project settings

The improved prebuild defaults should work well for most projects. However, if your project requires more fine-tuning of when prebuilds are triggered, the following prebuild settings are now available for all git integrations:

1. All branches (the default setting)
2. Default branch only (e.g. main)
3. Only the branches specified (via glob pattern)

Previously only the GitHub integration could filter prebuilds—configured through the .gitpod.yml. All other providers, e.g. (GitLab and Bitbucket) ran prebuilds on every commit push, with limited control.

Prebuild settings in the .gitpod.yml are deprecated. All existing .gitpod.yml settings will apply until prebuilds are manually enabled in project settings.

See configuring Prebuilds via .gitpod.yml for archived documentation.

The way init tasks work is changing, here’s what you need to know:

When you open a workspace and Gitpod finds an existing prebuild for an older commit, Gitpod will start the workspace and then run the init steps from the .gitpod.yml again on top of the existing prebuild. Gitpod will only use prebuilds that have an identical .gitpod.yml as your current commit. This new behavior works best for you when your init steps:

1. Can be executed repeatedly, while always producing the same end-state in the file system for a given reposiotry state.
2. Execute quickly when executed the second time (e.g. process changes incrementally).

For more, see Repositories and Prebuilds.

Start workspaces faster with the Gitpod Browser Extension v2

The Gitpod browser extension has now been updated with the following changes:

1. Start new workspaces faster - To save time, the default browser extension action will open your workspaces using either your preferences for the repository, or your user settings. To override this behavior and choose your settings manually, you can use the “Open with options…” secondary option on the Gitpod button.
2. Support for Self-Hosted BitBucket and GitLab - The browser extension is now compatible with both Bitbucket Datacenter and GitLab Self-hosted installations. No special steps are required: with the extension installed navigate to your BitBucket or GitLab instance to see the Gitpod button appear within the interface.

Getting Started:

1. Update or install the extension - If you do not have the extension already installed, you can download it from the Chrome Web Store or the Firefox Add-ons page. If you have already had the extension installed your browser will automatically update it.
2. Update the host setting (optional) - For Gitpod Dedicated customers you can update your extension host setting by clicking the Gitpod icon in your browser bar and adding your Dedicated installation URL e.g. your-company.gitpod.cloud.

Important: If you already had the browser extension installed, you may have to re-enable the extension and accept new permissions. Why? We removed host name restrictions to allow for self-hosted SCM support.

For more, see the browser extension documentation.

Set a default Workspace Image for your Gitpod Organization

With Gitpod you can now set a workspace image across your Organization. Previously, Gitpod would use the default workspace-full image when starting new workspace where there was no image setting added in the .gitpod.yml. Setting the default image is useful when you want to create a default workspace experience out-of-the-box for users in your Gitpod Organization without needing to create a .gitpod.yml in every repository.

Please note:

• The Organization workspace image setting is only a default and the workspace image can still be overwritten at the repository level by adding a workspace image reference into the repositories .gitpod.yml file.
• Authentication for the images is based on what the Gitpod installation can access. For Gitpod Cloud users, only public images are currently supported. For Gitpod Dedicated, the authentication is inherited from the installation. For instance, if you are using ECR private registry support that will work with the Organization setting.
• Only Organization owners can update the setting. All Organization members can view the setting.

Getting started

1. Ensure you are the Owner of the relevant Gitpod Organization (see Members).
2. Navigate to the Organization settings page.
3. Navigate to the “Workspace Image” section to update the workspace image reference.
4. To test, start a new workspace based on a repository without a workspace image.

See Workspace Image for more.

Gitpod Dedicated expands regional availability

Gitpod Dedicated now supports three additional AWS regions.

New AWS Regions:

• eu-west-2 (London)
• eu-west-3 (Paris)
• sa-east-1 (Sao Paulo)

Comprehensive list of currently supported regions

Why It Matters:

These added regions allow for instances to be positioned closer to users, resulting in reduced latency. Additionally, this update allows a broader range of companies to meet data residency requirements that mandate instances and data to be situated in specific regions.

Get started: Interested in leveraging Gitpod Dedicated or looking to have Gitpod in a region not listed here? Contact our Sales team to discuss your options.

Instead of trying to quit vim, just close the tab

With Gitpod you now have a new editor option for your workspaces: a terminal in the browser.

The terminal in the browser is good for full-time coding with Vim or Emacs, or simply making quick edits. A minimalistic, flexible experience to enhance your productivity using the tools that work best for you.

Customise the browser terminal with your own dotfiles or connect via SSH for added flexibility.

Getting started

• Select the terminal as the editor when you start a workspace (try gitpod.new for a blank workspace)
• You can also Set the browser terminal as your default editor in your user preferences.

See Browser Terminal for more.

Secretless Authorization (Using OIDC)

With Gitpod you can use OIDC to connect Gitpod workspaces to cloud providers or third parties such as AWS, Azure, GCP, or secret management services like Vault. Using OIDC integration eliminates the need to manually distribute access credentials, secrets, and other key material via other methods such as environment variables.
Use gp idp token in any workspace (works in .gitpod.yml and with prebuilds) to retrieve the workspace JWT token for exchange with the OIDC supporting 3rd party.

Getting started

The following shows how you can connect AWS to a Gitpod Cloud workspace. Steps can vary based on the 3rd party you are integrating and the domain of your Gitpod installation, see the documentation below for details.

1. Setup Gitpod as an AWS Identity Provider (Using https://api.gitpod.io/idp as the Audience).
2. Create an AWS role with permissions to perform sts:AssumeRoleWithWebIdentity.
3. Update your .gitpod.yml to exchange your workspace JWT token for an access token.

bash

gp idp login aws --role-arn <your-iam-role-arn>
aws secretsmanager get-secret-value --secret-id database_connection_string

See Workspace OIDC and the AWS Integration Guide for more.

Workspaces forward ports using the HTTPS protocol

In Gitpod, you can now expose ports from your workspace running with HTTPS.

Previously, HTTPS ports exposed in a workspace would show a “port not found” page when accessed. You can configure the port protocol either in your gitpod.yml or via the Gitpod CLI.

Configuring a port protocol in .gitpod.yml

To ensure a port is always configured with a specific protocol you can update the ports definition block in .gitpod.yml as below. Updating your .gitpod.yml is the preferred approach to using the gp CLI (see below), as the .gitpod.yml is declarative and ensures workspaces are created repeatably.

yml

ports:
    - name: Frontend Application
      port: 3000
      protocol: https

Dynamically updating port protocols with gp

You can dynamically change the protocol of a port using the gp ports protocol command.

For example, gp ports protocol 3000:https will change port 3000 to use https.

Or, gp ports protocol 3000:http will change port 3000 to use http. By default, ports are set as HTTP.

See configuring ports, Gitpod CLI gitpod.yml for more.

New Workspace Creation Page ✨

We’ve enabled the ability to select the organization, editor, and workspace class used when opening a workspace. Giving you the ability to:

• Select which organization will be billed.
• Change editor and scale resources per workspace.
• Be certain about how many credits per hour will be consumed.

We look forward to hearing your feedback! github.com/gitpod-io/gitpod/issues/17215

Validate your .gitpod.yml without committing ! 🤘

TL;DR; - You can now validate a Gitpod configuration—both the .gitpod.yml and the workspace image—by running gp validate without needing to restart, leave your workspace, or commit your configuration.

• With gp validate can now validate a configuration within the workspace without committing. This works in a very similar way to a regular Gitpod workspace start, allowing you to catch configuration mistakes earlier.
• Using gp validate --prebuild you can create run a workspace just as a Prebuild would, which makes it easier to debug a Prebuild configuration by re-creating the exact state inside a running workspace.

The power of a CDE comes with a well-defined configuration. Because, when your workspace is configured, you can make use of ephemeral workspaces, multi-track development and other benefits of developing in the cloud.

To update a configuration, you would commit your .gitpod.yml and start a new workspace. This process would delay the time to finding out a configuration was incorrect, and in the mean time pollute your source control with commits like: ”updates”, ”next”, ”please work!”, ”please work this time” — yeah, we know how it feels!

Which is why we are “shifting left” and bringing errors, validation and suggestions closer to when you are actually developing on and iterating on your configuration. The new Gitpod command gp validate allows you to do exactly this: validate your configuration changes without committing, or leaving your workspace!

gp validate is included in every workspace. It works by creating a “workspace within your workspace” using Docker. The command mounts your /workspace directory, and pulls through all necessary information such as environment variables. By building a workspace within your existing workspace, we can heavily cache changes as Docker layers, making the update cycle to your configuration ⚡️ super, super fast ⚡️.

For more, see configuring workspaces.

FAQs

Does gp validate apply it’s changes to the currently opened workspace?

The gp validate command creates a workspace within your current workspace so you can quickly try our your configuration changes without committing or needing to do a full workspace restart. You do still need to commit and start a new workspace to apply the changes to your current (and future) workspaces. However, committing your configuration should now be more of a formality, as your configuration now be validated.

Does gp validate apply to all files and configurations in the workspace?

The gp validate command is compatible with .gitpod.yml and your workspace base image, whether a Dockerfile in the current workspace, or referencing an image hosted elsewhere. The workspace that gp validate creates shares the file system with the parent workspace, meaning all files and folders are copied into that workspace. This is especially useful when you install a tool, and want to execute or experiment with that tool immediately.

Workspace Images OS Update and Breaking Changes

On April 3rd, Gitpod will upgrade their workspace images to utilize the latest Long Term Support (LTS) version of Ubuntu, which is Ubuntu 22.04.2 (codenamed “Jammy Jellyfish”). As this is a significant release, there are some breaking changes that you should take into account. In case you encounter any problems with your workspaces as a result of this update, kindly submit an issue in the workspace-images repository.

What should you do

Consider which docker image tag is right for your team and repo(s).

Options to consider:

1. Continue using the latest tag. New workspace starts after the release will use Jammy.
2. Test Jammy before it is released using tag 2023-03-24-02-48-18.
3. Continue using Focal even after the release using tag 2023-01-16-03-31-28. Switch to Jammy at your leisure, after you’ve had more time to do testing.
4. Use a custom base image, and continue using Focal for a longer period of time.

Breaking changes

1. All maintained images have been updated from Focal to Jammy [1][2] at hub.docker.com/u/gitpod.
2. gitpod/workspace-ruby-2 is deprecated and will not be updated; Ruby 2.7 is EOL March 31, 2023.
3. Upgraded gitpod/workspace-mongodb to mongo v6. v5 doesn’t support OpenSSL 3, OpenSSL 3 comes out of the box with Jammy.
4. Updated gitpod/workspace-node-lts from Node 16 to Node 18, and also in gitpod/workspace-full.
5. Updated gitpod/workspace-node from Node 18 to Node 19.
6. Installed Python 3.9 in gitpod/workspace-yugabytedb*, changing its base ref from full. Refer to its dockerfile for background

Fixes

1. Bumped Rust to 1.67.1
2. Bumped Ruby patch versions for 3.0, 3.1, 3.2
3. Overrode OpenSSL for Ruby 3.0 to support Jammy
4. Bump Ruby in gitpod/workspace-full from 3.1 to 3.2
5. Bump Python in gitpod/workspace-full from Python 3.8 to 3.11
6. Bump nvm version from 0.39.0 to 0.39.3

New features

1. Use asdf version manager in gitpod/workspace-elixir to more easily manage erlang and elixir versions

FAQs

Is Gitpod still maintaining support for Focal in its images?

No. Please consider the above options to handle the update.

What else should I consider as part of the upgrade?

The GNU C Library (glibc) varies between Focal and Jammy.

OpenSSL varies between Focal and Jammy.

Both led to some of the breaking changes (above). Therefore, this may impact you and your team, depending on your related workloads.

Organizational Policy For Workspace Sharing 🔒

To give you more control over who has access to your development environments with Gitpod, Organization Owners can now restrict workspace sharing for workspaces created within their Organization using an Organizational Policy. Disabling workspace sharing prevents any user running a workspace in that organization from sharing their workspace with others.

To disable workspace sharing in your organization, go to settings.

For more information see:

• Organizational Policies
• Workspace Sharing Policy
• Workspace Collaboration

FAQs

What happens to previously shared workspaces?

Workspaces can stop sharing at any time, regardless of policy set. Access for workspaces shared before the policy is set will remain until workspace sharing is stopped for that specific workspace.

Does this always prevent the repository from being shared in a workspace?

Restricting workspace sharing only applies to workspaces that belong to the Organization that has the policy applied. Workspaces created in other organizations inherit policies related to that Organization.

Introducing Flexible Timeouts 🥳 !

You can now set your workspace timeout up to 24 hours using the command line, direct in your favorite editor or IDE or configure a global default! Setting a configurable timeout is useful if you’re working on a long running task, need to leave your workspace open for a while and then revisit it, or whilst collaborating or sharing previews with others.

To try out this feature, type: gp timeout set 1h to set the timeout for the currently running workspace to 1 hour. Or, go to your user preferences to set the default value for all future timeouts.

FAQs

Does this work for free users?

Only users on paid plan can set custom timeouts.

Can timeout defaults be restricted by an organisation owner or administrator?

Not currently.

January Changelog

Welcome to the January 2023 edition of the Gitpod Changelog!

Key Highlights

• Introducing Gitpod Enterprise
• Prebuild Workspace Class
• Workspace Images OS and Node versions update
• Start new workspace with more options
• Improvements to reliability
• RSS Feed for Gitpod Blog

Introducing Gitpod Enterprise

Gitpod Enterprise is our new enterprise cloud product - a secure installation of Gitpod managed by us for you. Gitpod exists to remove friction from the developer experience, and the best way to do that is with a managed product in the cloud. We no longer actively support self hosting Gitpod.

To read more, see Introducing Gitpod Enterprise

Prebuild Workspace Class

Prebuilds do a lot of work downloading dependencies, building projects, and getting everything ready so you are Always ready to code. Prebuilds often need more resources and power than the average workspace. Now you can configure different workspace classes for your project prebuilds. Check out your project settings for more details.

Workspace Images OS and Node versions update

On February 28th, Gitpod workspace images will be upgraded to use Ubuntu 22.04.1 LTS (Jammy Jellyfish). Additionally, gitpod/workspace-node and gitpod/workspace-node-lts workspace images will be upgraded to use Node 19.0.0 and Node 18.13.0, respectively.

If you’d like to continue using the current OS and Node versions, you may pin the workspace image version by changing the tag from latest to 2023-01-16-03-31-28 (e.g. gitpod/workspace-node-lts:2023-01-16-03-31-28) in your .gitpod.yml or Dockerfile.

Start new workspace with more options

Now you can start a new workspace with more options. You can choose the IDE, the workspace class, and any context url. 🎉

Improvements to reliability

Reliability improvements tend to go unnoticed. No news is good news. But we want to change that.

After countless improvements during the last months, our systems’ reliability show significant improvements according to both our internal metrics and direct customer feedback. 😎

RSS Feed for Gitpod Blog

We now have an RSS feed for the Gitpod blog. You can subscribe to it here: https://www.gitpod.io/blog/rss.xml. So you can now follow the latest news from the Gitpod blog in your favorite RSS reader. 📄😎

November Gitpod Release 2022

Welcome to the November 2022 edition of the Gitpod Changelog!

Key highlights

• Prebuilds require a project
• CLion and Rider are now out in beta! 🎉
• Configure JetBrains IDE Settings across workspaces
• Reliable VS Code extensions: Gitpod now hosting an Open VSX Mirror!
• Manage workspace ports without needing to leave your JetBrains UI
• Reduced IDE startup time & Custom Shells [Breaking Change]

Prebuilds require a project

In the past, it was possible to trigger prebuilds by prefixing the repository URL with gitpod.io/#prebuild/. This mechanism has been turned off, because projects provide much better visibility into your prebuilds.

Use the following steps to enable prebuilds on your repository:

1. Create a repository for the repository.
2. Define the prebuild steps in an init task in your gitpod.yml.

Since prebuilds are included in all our metered pay-as-you-go plans, configuring prebuild settings in your project should help with managing prebuild usage.

CLion and Rider are now out in beta! 🎉

1. First we announced IntelliJ IDEA, PyCharm, GoLand, and PhpStorm
2. Then it was the turn of RubyMine and WebStorm

Today—as part of our official partnership with JetBrains—we “complete the set” of JetBrains IDEs that integrate with Gitpod via JetBrains Gateway. Gitpod now has first-class IDE integration support for both Rider and CLion! 🤘

Getting started with CLion or Rider:

1. Install JetBrains Gateway - With the JetBrains Gateway and Gitpod plugin you can create and manage your latest 20 Gitpod workspaces.
2. Install the Gitpod plugin - Open JetBrains Gateway and you’ll see the Gitpod logo on the main page. Click “install” to install the Gitpod plugin for JetBrains Gateway.
3. Update your Gitpod preferences - Select CLion or Rider on the Gitpod preferences page which will set the IDE as your default for future workspace starts.
4. Start (or restart) your workspace - Either start a workspace directly from within JetBrains Gateway via the Gitpod plugin OR open a new workspace directly in Gitpod where on workspace start you will be prompted to open CLion or Rider for that workspace.

Configure JetBrains IDE Settings across workspaces

You can now configure your IDE settings at the project and user level. At the Project level, you can use your Workspace Image or commit settings to Git. At the user level, you can now configure settings by leveraging Dotfiles.

A common question we get from Gitpod users is ”how can I configure JetBrains IDE settings so that they’re saved across workspaces”. Without some way to sync IDE settings, you are missing out on fully embracing the power of Gitpod, ephemeral workspaces and cloud development environments.

For an example, see IntelliJ IDEA for how to configure IDE settings.

See your favorite JetBrains IDE page for more.

Reliable VS Code extensions: Gitpod now hosting an Open VSX Mirror!

Gitpod uses the Open VSX registry both for VS Code Extensions when using the VS Code in the browser integration, and when combined with Gitpod VS Code Settings Sync. In the unfortunate case that the main Open VSX registry was unavailable or unresponsive, regrettably Gitpod users could be exposed to downtime and see extensions failing to load in Gitpod workspaces. Whilst Gitpod has caching in place for Open VSX extensions, some extensions could still fail to fetch, causing disruption. To mitigate the issue, Gitpod is now running a full mirror of Open VSX, fully operated by Gitpod, allowing us to drastically improve the availability of Open VSX delivered extensions. 🎉

Nothing should prevent you from being “Ready To Code” with Gitpod.

Manage workspace ports without needing to leave your JetBrains UI

You can now view ports both in your JetBrains terminal, and in the JetBrains backend control center.

1. From the backend control center - In addition to performing many Gitpod actions from the JetBrains backend performance center you can now also view and manage your ports. See which ports are being forwarded or exposed. You can also add, remove and open URLs for your workspace ports without leaving the JetBrains UI.

1. From within the terminals view - You can now also see, and manage your ports from the terminal view direct in the JetBrains IDE, allowing you to manage any ports related to the current running terminal process all without leaving the terminal window in your IDE.

Running your IDE on your desktop means that all your ports are automatically forwarded, so you can use your localhost URL as usual. You can also manage ports from any IDE or Gitpod interface using the Gitpod CLI. For example, try running gp ports list in any workspace to see a list of your workspaces running ports.

Reduced IDE startup time & Custom Shells [Breaking Change]

If you don’t use custom shells such as zsh or fish, you just need to know that we made some changes to speed up the IDE startup time! 🎉

If you use a custom shell, and you rely on bash profile to configure your workspace, continue reading..

In an effort to speed-up the IDE startup time, we made some changes to how we launch IDEs inside workspaces. Previously, we would automatically source interactive login bash shell’s profile, but it was a side-effect of our method of launching the IDE. We now changed this behaviur and Gitpod uses the shell configured by the user via the SHELL env var. If you use a custom shell but you’re relying on configurations specified in bash profile, you might need to update your configuration, check out Configure a custom shell for examples.

If you have feedback about using custom shells within Gitpod, we’d love t hear it, leave your thoughts in #10105.

November Self-Hosted Release

We’ve released a new version of Self-Hosted Gitpod. Update instructions can be found in our update guide. You can read more about how to install it in our documentation. More details on this release can be found on GitHub.

If you are on a paid Self-Hosted plan, this release will be promoted to your release channel in one week.

For feedback, please raise an issue or chat with us.

Fixes and improvements

A full list of changes can be found in the release notes on GitHub.

October Gitpod Release 2022

Welcome to the October 2022 edition of the Gitpod Changelog!

Key highlights

• Even more power! ⚡ Try large workspaces with pay-as-you-go 🎉
• Start workspaces based on existing prebuilds ⚡️
• RubyMine and Webstorm IDEs now in beta 🚀
• New “exposed ports” view in VS Code Desktop 🔌
• Ports sorting now based on your gitpod.yml definition ⏬
• Easily find information about your workspace with gp info ℹ️
• VS Code ports view is now responsive ⏩
• Projects now only created under teams, not personal accounts ⚠️
• Using private workspace images (Alpha) 🔐

Even more power! ⚡ Try large workspaces with pay-as-you-go 🎉

Important: Prices and terms are subject to change.

With pay-as-you-go you get early access to workspace classes, allowing you to customize your workspace resources. To get access to pay-as-you-go either for teams or individual users, please contact us.

How does pay-as-you-go work?

• Gitpod usage is measured in credits, based on how long your workspaces run, and the resources consumed by different workspace classes. Metered usage also includes prebuilds.
• Individual users receive 500 free credits per month on the free plan, these credits are equivalent to 50 Standard workspace hours or 25 Large workspace hours.
• For users who upgrade to the personal paid plan at €/$ 9.00 per month, workspace usage allowance increases to 1000 credits.
• The standard pay-as-you-go rate for paid users, and for teams, is €/$ 0.036 per credit.
• Existing paid plans need to be cancelled for pay-as-you-go billing to work.

Start workspaces based on existing prebuilds ⚡️

Start a new workspace based on an existing prebuild

You can now start workspaces using existing prebuilds. This helps when you have a repo with many commits, so you’re not left waiting for the latest prebuild to finish. To get started, select a prebuild from your project prebuild list, and click ”New Workspace (with this prebuild)”

JetBrains RubyMine and WebStorm IDEs now in beta 🚀

We are continuing to expand support for JetBrains IDEs as part of our official partnership with JetBrains.

See the RubyMine & WebStorm announcement for more.

New “exposed ports” view in VS Code Desktop 🔌

To give you all the power of Gitpod, we’ve added a new tab, EXPOSED PORTS, which gives you additional functionality in addition to the regular ports view of Remote - SSH, like port visibility (public/private).

Due to constraints with Remote - SSH extension, we cannot extend the default VS Code ports view.

Ports sorting now based on your gitpod.yml definition ⏬

Ports shown in all Gitpod clients are now ordered based on:

1. The order of the ports definition in the .gitpod.yml
2. All other ports are numerically sorted in ascending order.

This change applies to all of VS Code, JetBrains IDEs, SSH and the Gitpod CLI.

Example output of gp ports list:

bash

| PORT  | STATUS         | URL                            | NAME & DESCRIPTION |
| ----- | -------------- | ------------------------------ | ------------------ |
| 3000  | open (public)  | https://3000-repo...gitpod.io  | Web Server Preview |
| 5900  | open (private) | https://5900-repo...gitpod.io  | Postgres Database  |
| 5555  | open (private) | https://5555-repo...gitpod.io  |                    |
| 36341 | open (private) | https://36341-repo...gitpod.io |                    |

See ports documentation for more.

Easily find information about your workspace with gp info ℹ️

You can now display information about the current workspace (such as the workspace ID and URL) and also the workspace class, using the new command from Gitpod CLI called gp info.

Example output:

bash

  Workspace ID    : gitpodio-gitpod-4q1200dvfcf
  Instance ID     : 8a6188a3-4c7f-49fe-aa4d-db968c11e183
  Workspace class : Large: Up to 8 vCPU, 16GB memory, 50GB disk
  Workspace URL   : https://gitpodio-gitpod-4q1200dvfcf.ws-eu67.gitpod.io
  Cluster host    : ws-eu67.gitpod.io

See the Gitpod CLI reference page for more.

Default environment variables will soon be deprecated, please update all scripts to use gp info --json.

VS Code ports view is now responsive ⏩

The ports view in VS Code is now responsive depending on the ports view width. The view defaults to the bottom VS Code navigation bar, however, the ports view can be drag-and-dropped to the sidebar if you prefer. You can access all port actions as normal on all views. In larger views, more information about your ports is shown.

For feedback let us know on the ports experience GitHub issue.

Projects now only created under teams, not personal accounts ⚠️

• You can no longer create Gitpod Projects under personal accounts.
• All projects must now be created as part of a team.
• Existing personal projects will continue to work.

Using private workspace images is now in alpha

Did you know that you can use a private Docker image with Gitpod? Private Docker image support for workspace images has been possible for some time, however it was an undocumented feature. We’ve now updated our documentation so that you can more easily give try out the feature. As the feature is currently alpha, please raise an issue for any feedback.

October Self-Hosted Release

We’ve released a new version of Self-Hosted Gitpod. Update instructions can be found in our update guide. You can read more about how to install it in our documentation. More details on this release can be found on GitHub.

If you are on a paid Self-Hosted plan, this release will be promoted to your release channel in one week.

For feedback, please raise an issue or chat with us.

Fixes and improvements

A full list of changes can be found in the release notes on GitHub.

September Self-Hosted Release

We’ve released a new version of Self-Hosted Gitpod. Update instructions can be found in our update guide. You can read more about how to install it in our documentation. More details on this release can be found on GitHub.

If you are on a paid Self-Hosted plan, this release will be promoted to your release channel in one week.

For feedback, please raise an issue or chat with us.

Security

This release includes security fixes addressing information leakage in logs; see the security announcement log for more information.

2022.09.2 hotfix (published on 21.7.2022)

This hotfix includes:

• #13934 Fix for an issue where secrets could end up in logs because the installer was logging the env var object. For more information, see the security announcement log
• #13959 This fix adds a checkbox to enable the HTTP proxy settings. Proxy settings were sometimes being incorrectly applied before this. Now, the values are still taken from the KOTS CLI input variables, but will not be applied until the option is configured in the UI.

2022.09.1 hotfix (published on 14.7.2022)

#13821 This hotfix includes a change to fix the regression caused by protected_secrets (see security announcement log for more information) when working with self-signed certs.

Highlights

Preflight checks on the Gitpod configuration

#12015 We know that some of you are using config patches to configure additional aspects of Gitpod, such as the resources that workspaces use. Up until now, there was no validation on these patches and thus it was difficult to debug if there was an issue with them. This has changed now - there is a preflight check that validates these (and the Gitpod configuration as a whole), and then informs you where to look to find any errors.

Additional safeguards during updates

#13215 During updates, we recommend that you do not have any workspaces running to prevent data loss (see update guide). There is now a preflight check that checks for running workspaces before you deploy and fails if it finds any running ones. If an update is deployed anyways, running workspaces will be stopped for you. Note that users will see their workspaces stopped arbitrarily.

Breaking changes

• Single Cluster Reference Architecture changes:
  • Regular workspaces and headless workspaces are isolated to separate node pools to help avoid noisy neighbor issues between the two and guarantee maximum performance for workspaces
  • Workspace Services (such as ws-manager) are deployed to the services nodepool to prevent potential service degradation from high ws-daemon memory use.
  • We’ve increased the default node size to 16 core / 64 GB nodes. This is to allow for more workspaces per node, and avoid the scenario where there is just one workspace per node. We’ve also added documentation to detail our recommendations around workspace resources.

Fixes and improvements

#12196 The KOTS installer script is used to generate a config file out of the values inserted into the KOTS UI. We’ve refactored large parts of it to turn it from a bash script into a part of the installer image. This improves reliability and predictability for you and maintainability for us. It also allows us to call this during preflight checks, enabling us to provide the preflight checks for config patches mentioned above.

A full list of changes can be found in the release notes on GitHub.

September Gitpod Release 2022

Welcome to the September edition of the Gitpod Changelog!

Key highlights

• JetBrains Backend Control Center - Gitpod workspace actions
• JetBrains Backend Control Center - Workspace Classes
• JetBrains Reconnect With Open Windows
• New Ports View in VS Code
• SSH Gateway default for Self-Hosted VS Code Desktop Users
• Configurable core dump behavior
• Faster startup times for large repositories
• Fixes and improvements

JetBrains Backend Control Center - Gitpod workspace actions

Caption: The Backend Control Center in JetBrains showing various Gitpod workspace actions

If you’re a Gitpod VS Code user, you know that in the command palette you can do things like:

1. Stop your workspace
2. Open the Gitpod dashboard
3. Open in VS Code Desktop

…and much more.

However, for JetBrains users, there was no way to access these common Gitpod commands without leaving the workspace. Or worse, opening your workspace using VS Code, rather than your preferred JetBrains IDE. It’s important that all the Gitpod editors and IDEs have a first-class experience for our users, no matter their preference, and our Jetbrains IDEs are no exception.

But now, we’ve added all of the Gitpod workspace actions you could do in VS Code into JetBrains.

You can now access these commands through:

• The Backend Control Center in JetBrains
• Or via the JetBrains IDE search menu

That means from within a JetBrains IDE you can directly:

1. Open the Gitpod Dashboard
2. Open your workspace context
3. Open your user settings
4. Manage workspace access control
5. Go to the Gitpod documentation
6. Report an issue on GitHub
7. Follow Gitpod on Twitter
8. Access our community server on Discord
9. Upgrade your Gitpod subscription
10. Stop your workspace
11. Extend your workspace timeout
12. Share your a snapshot of your workspace

All from the comfort of your IDE.

JetBrains Backend Control Center - Workspace Classes

Caption: The Backend Control Center in JetBrains showing workspace class information (e.g. 6 vCPU, 12GB memory)

Did you know that when you’re working with JetBrains IDEs in Gitpod you can monitor the performance of your workspace in real-time via the JetBrains Backend Control Center? This feature is useful when your workspace isn’t performing as you’d expect and you want to gather more information. In addition to our recent additions of Workspace CPU and Workspace Memory we’ve now added the actual workspace class to the information shown in the control center.

… but why? When you work in a cloud developer environment, you should have the flexibility to choose the right performance profile for your project. Recently we’ve been working to bring to Gitpod a feature we call “Workspaces Classes” #8261. With Workspaces Classes you’ll be able to select workspace specifications that better match your use case. For example, you will be able to get more powerful workspaces to run larger Java projects and IntelliJ.

So since we needed somewhere to show you this Workspace Class information, you can now find it in the JetBrains performance center.

Tip: You can run gp top to see performance info no matter the IDE or editor you’re using.

JetBrains Reconnect With Open Windows

Previously, with JetBrains if you tried to open your workspace twice, the Gitpod JetBrains Gateway plugin would allow you, sometimes leading to odd behaviors or bugs, since JetBrains Gateway is designed to only allow one window to open. Now, when you try to open an already opened window with JetBrains Gateway, you’ll get a prompt to remind you that the workspace is already opened.

New Ports View in VS Code

Caption: The new VS Code Browser ports view, shown at the bottom of VS Code alongside the terminals and output tabs

You might have seen in our last changelog that we mentioned a new ports view being added to VS Code (in the browser). At that time we were rolling out the feature to only subsets of our Gitpod users to see how users responded. However, after some good feedback from you (our users) we have pushed the feature out to all users! 🥳

We introduced the new ports view as we wanted to align our experiences on VS Code Desktop with VS Code Browser. We know lots of users like to use Gitpod in the browser sometimes for “smaller changes” like reviewing pull requests. But for more “deep work” many users opt for VS Code Desktop. However and wherever you choose to code, Gitpod will make that as much a comfortable and familiar experience as you’re used to.

SSH Gateway default for Self-Hosted VS Code Desktop Users

We have previously shared about how we updated the underlying connection method of VS Code Desktop to Gitpod for our new SSH Gateway approach. The feature was first released defaulted off for all users. We have since enabled this SSH access method for all users of gitpod.io, and now we’ve enabled the approach for all VS Code Desktop users of Gitpod everywhere, no matter which installation they’re using.

Configurable core dump behavior

Debugging applications in Gitpod that are written with C++, Rust, or Python just got easier.

We’ve added a new coreDump configuration property to the .gitpod.yml file, allowing you to configure your workspace core dump behavior. You can enable/disable core dumps, or set soft and hard limits for them. For information on how to configure this property, check out the core dump property of the .gitpod.yml

Faster startup times for large repositories

Are you working with a large git repository? You want to hear about this.

We have changed how files are fetched from git into Gitpod on workspace start, to make your experience faster. In our testing of the changes, we observed differences from around 2m30s down to 40s. If you’re using large repositories with Gitpod, give it a try and let us know about your experience 🚀

August Gitpod Release 2022

Welcome to the August edition of the Gitpod Changelog.

Key highlights:

• JetBrains now supports multiple task Terminals
• JetBrains now respects configured Java SDK (JDK) versions
• View Resource Consumption in JetBrains Backend Control Center
• Sync Local VS Code extensions
• VS Code Desktop reduced popups when opening
• All VS Code Desktop users on SaaS are now using SSH Gateway! 🎉
• gp tasks list shows your current tasks (as defined in the .gitpod.yml)
• gp tasks stop stops running tasks that (as defined in the .gitpod.yml)
• Improved OpenSSH compatibility and support for sha256/sha512

The following features are also accessible for users running the “latest” IDE or editor preference:

• New ports explorer in VS Code Browser - Aligning the port interface with VS Code Desktop.

Improvements for JetBrains IDEs

We are continuing to make progress with the JetBrains and Gitpod integration #7956 as part of our ongoing partnership with JetBrains. Whilst most of our efforts are mostly towards IntelliJ IDEA, a lot of the improvements we are making will still apply to our other supported JetBrains IDEs.

JetBrains now supports multiple task Terminals

A key part of “Gitpodifying” a project is adding any necessary tasks, such as starting servers or database to your .gitpod.yml. One advantage of declaring these processes in your .gitpod.yml configuration is that your commands are picked up by the IDE or editor and show on workspace start.

Previously, JetBrains with Gitpod only showed a single terminal, meaning that users needed to use gp tasks to interact with running terminals. Due to some improvements for JetBrains Remote Development that we are able to leverage, you can now see all of your terminals inside the IDE as you also can with VS Code.

JetBrains now respects configured Java SDK (JDK) versions

Previously, when opening a Java Workspace with JetBrains, the Gitpod IDE would select the latest Java SDK (JDK) version as the default.

This was problematic when we recently updated the Gitpod workspace-full image, to include both Java 11 and 17, which many users rely upon. When having multiple JDK versions, JetBrains would default to using the latest JDK version, which in the case of the workspace-full image was 17, and not 11, causing a minor regression. Now, Gitpod respects configured JDK versions in locations such as the PATH and JAVA_HOME.

JetBrains IDEs now picking up the correct SDK version by default

View Resource Consumption in JetBrains Backend Control Center

When using a Gitpod workspace you might experience performance issues caused by an application using more resources than expected, or due to resource consumption in adjacent containers on the node. Whatever the reason, you may want to investigate what’s going on within your workspace.

We’ve now extended the JetBrains Backend Control Center with two additional bits of information about your workspace: Workspace CPU and Workspace Memory. The additional performance information shown in the control center is for the node that your workspace is running on, and not the workspace itself. This information is also the same that can be found from running the command gp top in your workspace.

Viewing the workspace and node performance in the Backend Control Center

Improvements for VS Code Desktop

We have been continuing to invest in our desktop editor experiences, including VS Code #7184, with an emphasis on removing any barriers or friction in getting the VS Code editor open with a Gitpod workspace, establishing a stable connection via SSH, and improving the experience of restarting a timed out workspace.

Sync Local VS Code extensions

The underlying Microsoft VS Code - Remote SSH extension that powers the Gitpod VS Code Desktop integration does not automatically install local user extensions on remote machines, such as a Gitpod workspace. For users, because VS Code - Remote SSH does not automatically install local extensions, that means you’ll have to manually click “install” for each local extensions on every Gitpod workspace start. Installing extensions manually is cumbersome, especially when you have many extensions to install and is a barrier to utilising Gitpod ephemeral workspaces.

In an upcoming release, Gitpod will prompt you to enable VS Code Setting Sync with Gitpod, which will allow Gitpod to retrieve local extensions and automatically install them in your workspace. If for any reason you want to disable syncing of local extensions, you can do so via the gitpod.remote.syncExtension VS Code settings. If you have any feedback or thoughts, please add it to the GitHub issue: #7906.

Prompt to enable Setting Sync with Gitpod to sync local VS Code extensions

VS Code Desktop reduced popups when opening

Many users love Gitpod for how simple it can make working with your projects. However, for VS Code Desktop there were some cases where you needed to respond to specific popups when opening your workspace, for instance accepting the SSH fingerprint of the workspace, or accepting the browser redirect when opening a workspace.

The number of prompts you are now shown when opening VS Code Desktop is reduced.

You should see one browser redirect prompt (one for VS Code Desktop and one for JetBrains Gateway), marking “always allow” will suppress all future prompts. SSH fingerprints are also now automatically added to your known_hosts if you’re using SSH Gateway approach to opening VS Code Desktop.

Using the SSH Gateway approach for VS Code Desktop means no more SSH fingerprint prompts

For more information, check out our dedicated documentation for optimising VS Code Desktop.

All VS Code Desktop users on SaaS are now using SSH Gateway! 🎉

We have now completed a migration of all VS Code Desktop users on SaaS to our new SSH Gateway approach. This change brings improved stability, smoother restarting of workspaces, and more.

To get setup, we recommend you upload an SSH key to Gitpod. For full details on why we made this change to our SSH approach for VS Code Desktop, please check out our blog post VS Code Desktop and SSH explained.

If you cannot use the new approach for any reason, please reach out via the GitHub issue #7452.

Improvements for the Gitpod CLI (gp)

Over the last few months we’ve been making lots of updates to the Gitpod CLI (gp). Because the gp command-line-interface is bundled inside of all Gitpod workspaces, gp acts as a common way to run workspace actions regardless of what editor or IDE you’re using Gitpod with, whether that’s JetBrains, VS Code or directly via SSH.

Let’s say that you’re documenting your Gitpod setup, rather than detailing actions directly how to take some action in each of the Gitpod supported IDEs & editors, you can share gp commands knowing that the experience will be consistent across all workspace editing experiences.

gp tasks list shows your current tasks (as defined in the .gitpod.yml)

The gp tasks list command allows you to list any running commands that are defined in your .gitpod.yml. If you want, you can even attach to a given task using gp tasks attach which brings that current task into the foreground of your terminal. However, since there are situations where it might not be as easy to figure out which terminal you’re currently viewing, that’s why we now highlight your current task to make life a little easier for you

gp tasks stop stops running tasks that (as defined in the .gitpod.yml)

You can now run gp tasks stop to stop running tasks that have been defined in your .gitpod.yml. You can either stop a single task with gp tasks stop <id>, or terminate all tasks by running gp tasks stop --all.

See the gp Command Line Interface documentation for more.

Improvements for SSH connections to Gitpod

The SSH protocol is the primary method of connection to Gitpod workspaces for JetBrains IDEs, VS Code Desktop and users who directly SSH into Gitpod for editing, or working with their code. We’ve been working to ensure that Gitpod has a wide range of support for different SSH clients and SSH key versions.

Improved OpenSSH compatibility and support for sha256/sha512

Previously, Gitpod did not support OpenSSH clients >v8.8, nor did Gitpod support RSA sha256/sha512. For users using VS Code Desktop with the SSH Gateway approach, this could mean that in some cases users could not leverage SSH access to Gitpod due to incompatible keys or OpenSSH client’s, however this issue should now be resolved.

August Self-Hosted Release

We’ve released a new version of Self-Hosted Gitpod. Update instructions can be found in our update guide. You can read more about how to install it from scratch in our documentation. More details on this release can be found on GitHub.

If you are on a paid Self-Hosted plan, this release will be promoted to your release channel in one week.

For feedback, please raise an issue or chat with us.

Feature highlights

Automatic backups

We’ve added the ability to back up your Gitpod application config (no workspace or database data is backed up!) via the KOTS Installation UI under the “snapshots” tab. You can even configure automatically scheduled backups. You can learn more in our backup and restore guide.

Configure additional registry credentials to use (base) workspace images from private registries

You can now use workspace images that are stored in private registries different from the main registry configured for Gitpod in your gitpod.yml and as an installation-wide default. This is useful when, for example, you want to pull private base images from one registry and then store the built images in another. For more information visit the relevant guide.

Breaking changes

• 11954: remove custom labels from the pod selector labels. This removes this limitation so this is a long-term improvement. The impact of this should be handled transparently for you by the KOTS installer.
• 12336: Removal of PodSecurityPolicies. These were deprecated from Kubernetes 1.21 and removed from 1.25. This allows Gitpod to run on Kubernetes 1.25+, which is scheduled for imminent release. If you have PodSecurityPolicies enabled in your cluster, we suggest you disable them as soon as possible.

Please refer to the 2022.08 upgrade guide in the documentation for details.

Fixes and improvements

A full list of changes can be found in the release notes on GitHub.

New ports explorer, changelog view, and connection improvements for VS Code

Users of the latest release could notice that we were working on improvements to VS Code Browser and Desktop. Now they are available in stable release as well via VS Code settings. Key highlights are:

• Connection improvements for VS Code Desktop to bring stability and performance.
• New ports explorer in VS Code Browser to align interface with VS Code Desktop.
• Latest changelog view in VS Code to access the latest changelog directly from VS Code Browser or Desktop.

You can enable Latest Release in your preferences and try the latest updates as soon as they are available.

Connection improvements for VS Code Desktop

We developed a new SSH connection mode for VS Code Desktop which brings stability and performance improvements. This mode can be enabled by setting gitpod.remote.useLocalApp to false in VS Code settings and will be enabled by default in future releases.

You can learn more about new the approach in its announcement blog post. If you’re short of time:

1. Connection has improved stability, with fewer disconnections
2. Approach doesn’t overwrite the remote.SSH.configFile
3. No additional binary downloads required or background processes
4. Fewer requests from VS Code to accept the SSH fingerprint
5. Improved operating system support via OpenSSH

New ports explorer in VS Code Browser

We developed a new ports explorer in VS Code Browser to align the interface with VS Code Desktop. You can enable, or disable it via the gitpod.experimental.portsView.enabled in VS Code settings. Give the feature a try and we’d love to hear your feedback.

Latest changelog view in VS Code

The new VS Code command Gitpod: Show Release Notes let you access latest changelog directly from VS Code Browser or Desktop.

July Self-Hosted Release

We’ve released a new version of Self-Hosted Gitpod. Update instructions can be found in our update guide. You can read more about how to install it from scratch in our documentation. More details on this release can be found on GitHub.

If you are on a paid Self-Hosted plan, this release will be promoted to your release channel in one week.

For feedback, please raise an issue or chat with us.

Feature highlights

Here are the highlights of what is included in this new version of Gitpod Self-Hosted:

• Auto-cancel pending or running prebuilds on the same branch when new commits are pushed
• Upload your public SSH keys to access your workspace

Further, a lot has been improved on the documentation side of Gitpod Self-Hosted, specifically around operating Gitpod:

• How to backup and restore Gitpod
• Business continuity and disaster recovery considerations with Gitpod
• We’ve also restructured the Self-Hosted section in our documentation to have a clearer separation of concerns around the intent of the documentation.

Breaking changes

There are minor breaking changes regarding how you configure workspace resource limits and workspace image defaults. Please refer to the 2022.07 upgrade guide in the documentation for details.

Fixes and improvements

• You can now configure the service type of the proxy service in the installation UI - you do not need to upload a .yaml file as a config patch anymore to configure this. However, having it in the config patch will still work until December.

• We’ve improved the time to deploy an update by removing the need to restart the message queue every time we deploy. This has the side benefit of reducing the risk of running workspaces misbehaving during an update. For more information, see the related issue.

A full list of changes can be found in the release notes on GitHub.

Bring your own workspace SSH keys

SSH (secure shell) is a critical protocol for remote development. Both JetBrains IDEs and the VS Code editor use SSH as their remote development foundation. So, a big focus at Gitpod has been on improving performance and usability for connecting using SSH.

Which is why today we’re excited to announce that in Gitpod you can now upload your own public keys to access your workspace. In addition, we’ve also removed the requirement for a mandatory public key to be available when access Gitpod using SSH with an Access Token. With SSH public key upload you can now:

1. Re-connect to workspaces without needing to go back to the Gitpod dashboard.
2. Benefit from improved security when accessing your workspace with a private key.

See the announcement post for details on the use-cases, benefits and how to get started using your own key pair with Gitpod today.

Roadmap updates

Auto-cancel prebuilds on outdated commits

During development, sometimes a number of commits occur within a short period of time, which can trigger and queue multiple prebuilds for the same branch.

Gitpod will now auto-cancel pending or running prebuilds on the same branch when new commits are pushed, efficiently processing the queue and making sure workspaces always use prebuilds with the latest commits.

Auto-cancellation has been enabled by default for all projects, but you can disable this behavior in project settings.

Roadmap updates

June Self-Hosted Release

We’ve released a new version of Self-Hosted Gitpod. Update instructions can be found in our update guide. You can read more about how to install it from scratch in our documentation. More details on this release can be found in GitHub.

If you are on a paid Self-Hosted plan, this release will be promoted to your release channel in one week.

For feedback, please raise an issue or chat with us.

New way to try out Gitpod: Local Preview (alpha)

You can now try out Gitpod Self-Hosted without having to spin up a Kubernetes cluster - via a simple docker run command. This will spin up Gitpod locally on your machine and enable you to experience what developing on Gitpod is like. Note that currently, only Linux-based systems are supported (Windows and Mac(Intel) are being worked on) and that unfortunately prebuilds will not work. You can read up on how to get going in the Local Preview Guide. Local preview is still in alpha, so we would appreciate any feedback you may have!

More flexibility regarding registries for airgapped environments

If you are using Gitpod in an airgapped environment you can now specify the container registry you want to use to store workspace images that Gitpod builds for you. By default, it will use an in-cluster registry. Previously, it would always use the same registry that is used during installation to download the images related to Gitpod.

Fixes and improvements

• We have added a customer_id field to the telemetry that is sent from a self-hosted instance. This helps us map an installation to a customer for support purposes. Note that this field is not being populated for users using the community plan and is only relevant to those on a professional plan.

A full list of changes can be found in the release notes on GitHub.

Grouping of inactive workspaces

Did you notice any changes in your workspaces list? Inactive workspaces are now grouped below the active workspaces and also allow users to clean up (mass delete) all inactive workspaces, see relevant pull request

Feedback is welcome, feel free to raise an issue or chat with us.

Roadmap updates

Gitpod dashboard improvements

We have made some design changes to the navbar at the top of the Gitpod dashboard. It now includes an always-visible link to your workspaces on the right, and offers better color accessibility.

The team/personal selector at the top left takes you directly to your own projects, or to the projects for the selected team. If you would prefer the team/personal selection to be preserved when you visit the workspaces list, please upvote Gitpod issue #10496.

Always ready to code 🚀

Roadmap updates

May Self-Hosted Release

We’ve released a new version of Self-Hosted Gitpod. Update instructions can be found in our update guide. You can read more about how to install it from scratch in our documentation. More details on this release can be found in GitHub.

For feedback, please raise an issue or chat with us.

New License tab in the admin panel

You can now see details about the license used by your installation, how many seats it has left, and the features your license includes. You can navigate to this page by going to the admin dashboard (top right corner of the Gitpod dashboard, which requires you to be an admin user) and selecting License in the navigation menu.

Fixes and improvements

A full list of changes can be found in the release notes on GitHub.

Feedback widget for dashboard

Users are more likely to provide feedback, the easier we make it for them.

Inspired by the feedback form for Gitpod docs pages, we’ve added a similar Feedback feature in the Gitpod dashboard.

One click is enough to tell us how you feel, or write a quick note, all without leaving the page.

Roadmap updates

VS Code Desktop Settings Sync

Gitpod is built to be flexible. It’s important that our users can develop with the tools that make sense for their current task and use the tools they are most comfortable with. We “integrate, don’t dictate”. This design principle extends also to our IDE and editor integrations where we have multiple options in the browser and on desktop both VS Code and JetBrains (also see: our partnership with JetBrains).

We encourage Gitpod users to use one workspace per task, move their development configurations to code, and embrace ephemerality to really get the most out of Gitpod. However, those users who choose to swap between VS Code Desktop and VS Code in the browser for editing code will have noticed that their VS Code settings (themes, plugins, and fonts, etc) weren’t kept in sync.

But since we know just how important it is for our users to have their setups and configurations just as they like them, we’re excited to let you know that VS Code settings sync now works between VS Code Desktop and the browser in Gitpod

Note: VS Code browser settings are already synced by default.

To enable VS Code settings sync on your desktop:

1. Open your Gitpod workspace in VS Code Desktop
2. Use the command palette to select “Settings Sync: Enable signing in with Gitpod”
3. Restart your VS Code Desktop
4. Resolve any settings conflicts between your browser and desktop

And you’re set! All your theme, plugins, and other settings will be synced in real-time and be reflected also when you’re working in VS Code in the browser.

Check out the VS Code settings sync documentation for more details.

April Self-Hosted Release

We’ve released a new version of Self-Hosted Gitpod. You can read more on how to install it in our documentation. More details on this release can be found in GitHub.

For feedback, please raise an issue or chat with us.

Fixes and improvements

Self-signed certificates (beta)

You can now use self-signed certificates (certificates that are not signed by a known public certificate authority) for your self-hosted Gitpod installation. This is especially useful if you want to run Gitpod in a corporate environment that uses a corporate certificate authority. You can find out more about self-signed certs in our TLS configuration guide.

Note: Self-signed certs are currently not supported on Google Cloud Platform (GKE) because you cannot get containerd to trust other certificates without being restarted.

Support for installing Gitpod in air gapped Environments

We’ve made it easier to install Gitpod in air gapped environments (an environment that is isolated to and from the internet). You can now get everything that you need to install Gitpod in a single bundle that you can then install into your air-gapped environment. You can learn more about installing in air gapped environments in our documentation.

Improved Documentation

We’ve been working on our documentation which now includes a revamped installation guide and a more detailed explanation of requirements Gitpod has on the cluster it runs on, as well as which components are needed to support it.

A full list of changes can be found on GitHub.

Support for Bitbucket Server

Gitpod now works with repositories on your own instance of Bitbucket Server. To set this up, please follow our 2-step guide in the documentation.

For feedback, please use the dedicated feedback issue or chat with us.

Fixes and improvements

• #9438 - [ws-manager] fix a bug when opening workspace you would be signed out from git and not able to do git commands
• #9493 - [ws-daemon] Check blkio throttle exists
• #9488 - fix a dashboard bug where you might end up on a workspace without having access to it
• #9135 - Connect to self-managed Bitbucket Server in Git Integration modal.
• #9460 - fix and improve validation of user environment variables
• #9455 - [kots]: add an installation status pod
• #9462 - [server] Optimization: Map GitHub API repositories during pagination, not after
• #9458 - [kots]: move dropImageRepo config to when using local registry
• #9231 - Allow integrating with ‘github.com’ without a GitHub App
• #9445 - Allow to configure JB plugins on repo level per a product, i.e. specific for IntelliJ or GoLand.
• #9328 - [ws-daemon] Remove warning when cpu.stat does not exist
• #9338 - [registry-facade] Do not log warning from local store already exist error
• #9360 - [docker-up] Add docker-compose binary
• #9366 - Automatically block users that are running blacklisted workloads
• #9382 - Revert ”[ws-daemon] Fix CPU limit annotation”
• #9355 - [ws-manager] add metrics to track initialize and finalize of workspaces
• #9358 - [ws-proxy] Do not allow ACME challenge to be processed by workspaces to ensure no one can register TLS for gitpod.io through letsencrypt
• #9356 - [docker-up] Set the MTU using ceth0 value
• #9309 - [ws-daemon] Only limit storage device classes
• #9335 - Make image-builder available through ws-manager
• #9390 - ws-daemon: align to decide if cgroup v2 to fix cgroup v2 with fuse
• #9428 - Add I/O limit plugin for cgroup v1
• #9437 - [ws-daemon] Refactor configuration of I/O limits
• #9155 - [kots]: enable use of a local registry
• #9427 - Allow workspace timeouts to be extended when a user has workspaces in different regions.
• #9446 - fixed a bug around email address rendering
• #9443 - JetBrains IDEs now start with a terminal opened, displaying an introductory message about Gitpod CLI.
• #9385 - re-enables blocklisting of email domains
• #9409 - block abusers based on email domain suffixes
• #9361 - [werft] Improve findFreeHostPorts speed
• #9404 - Fixed a bug where IO limits were not applied to the workspace
• #9219 - Stop running prebuilds for projects that did not start a workspace in the last 10+ weeks
• #9094 - [installer] Disable definitely-gp by default
• #9381 - Update code to 1.66.2
• #9367 - Update OpenSSH to v9.0

SSH directly into workspaces

As of today, in Gitpod you can now get access to a Gitpod workspace directly via SSH with a one-liner copy/paste from the Gitpod dashboard. All you have to do is visit the Gitpod dashboard, click the more actions menu at the right-hand side of your workspace list, copy/paste the SSH command into a terminal, and voila!

Choice and flexibility for developers to choose the right tool for the job is essential. Currently, for editing your code with Gitpod, you can use VS Code in the browser, VS Code on desktop, and using JetBrains IDE’s via JetBrains Gateway. Adding copy/paste SSH support makes it easier to work directly in your terminal, or for those times you need to hop into a Gitpod workspace. To use this feature, please follow our guide our documentation

Fixes and improvements

• #9007 - Ensure uncommitted changes are displayed in dashboard when workspace was restored from backup
• #9212 - Use veth instead of slirp4netns without affecting the supervisor
• #9082 - Add custom CA cert support to Gitpod services
• #9185 - Update code to 1.66.1
• #8955 - Use a pair of veths instead of slirp4netns
• #9003 - upport direct connect workspace via ssh command
• #8783 - Display warning message when users choose latest IDEUpdate IDE choose preferences UI
• #9051 - [dashboard] Implement a PaymentContext and use it to hide payment features when payment is disabled
• #9152 - Transformer for MySQL BIGINT type to JS number
• #8630 - Allow to configure JetBrains plugins in .gitpod.yml
• #8841 - Prebuild Detail view buttons are based on Prebuild status, instead of WorkspaceInstance
• #8970 - [dashboard] It’s now even easier to contribute: set a couple variables once, contribute for as long as you like.
• #9108 - Bitbucket Server: implements token validation for Git operations.
• #9191 - [ws-manager-bridge] Skip stale prebuild events.
• #9218 - installer: make shortname configurable
• #9233 - [ws-manager-bridge] Fix statusVersion comparison.
• #9200 - [registry-facade] Fix IPFS/Redis validation
• #9186 - [image-builder-bob] Update buildkit to v0.10.1
• #9162 - [registry-facade] Revert removal of DisableKeepAlives[registry-facade] Check redis connection on start[registry-facade] Separate Redis manifest cache from IPFS[registry-facade] Check if the keys exist and use MULTI[registry-facade] Use sync.Pool as bufferInclude error in probe log
• #9176 - [ws-proxy] Deny HTTP ACME challenges
• #8576 - Allow setting custom workspace timeouts in the Gitpod Installer for self-hosted installations.
• #9004 - Fixed one frame running phase when starting workspaceFixed IDE options display incorrectly when restarting the workspaceFixed stopped workspace does not work again if it started in another place
• #9159 - [kots]: update the logo
• #9115 - Store WorkspaceInstance.status_version in d_b_prebuild_workspace and count prebuild stale events
• #9121 - [gitpod-db] Don’t consider garbage-collected prebuilds as potential bases for incremental prebuilds
• #8831 - Remove Prebuild action and log view from Project Settings view
• #9116 - ws-manager-bridge skips stale prebuild events
• #9081 - Add custom CA cert support to workspaces
• #9106 - [registry-facade] Configure credentials for Redis Sentinel
• #9125 - Added requirements to KOTS installation
• #9083 - [kots]: add a kernel version check to the preflights
• #9046 - Fixes missing login providers for Gitpod Self-Hosted.
• #9052 - [dashboard] Fix Settings menu colors in Dark theme
• #9045 - [dashboard] Remove prebuild error message from prebuild log view
• #8896 - Adding support for Projects and Prebuilds for Bitbucket Server.
• #9109 - Fixes incremental prebuilds by choosing the right prebuild base.
• #8824 - [server] For GitLab projects without an owner avatar, fall back to the namespace avatar, or generate the default GitLab avatar
• #8805 - Dashboard reports prebuild status consistently between list view and detail view.
• #9104 - [installer] Fix registry facade env variables for IPFS and redis
• #8769 - Enable the use of fuse device on cgroup v2 systems
• #9005 - Experimental IPFS support for cluster-local image caching
• #9063 - Improve workspace startup time through improved manifest assembly
• #9039 - Removed leftover workspace size limit which could prevent backups from being created.
• #9060 - [kots]: add distribution check to the KOTS preflights
• #8962 - [KOTS]: extract images from the Installer and put in the additionalImages array
• #8940 - Add workspace branch & creation timespan column for Gitpod Jetbrains Gateway plugin workspace panel
• #8941 - [image-bob-builder] Add support for stargz
• #8917 - JetBrains Gateway EAP version is now supported.

docker run --privileged

You can now run privileged containers in Gitpod!

bash

# example
docker run --privileged -it busybox sh

Prior to the fix, users were getting an error, and it prevented them from running privileged workloads.

The host file system, in this case, is your Gitpod workspace. Don’t worry, it’s ephemeral!

Fixes and improvements

• #8459 - Made the gitpod.io/cpuLimit annotation work again
• #8918 - [ws-proxy] Configure kube-rbac
• #8845 - Update buildkit to v0.10.0
• #8941 - [image-bob-builder] Add support for stargz
• #8878 - fix findPrebuildsWithWorkpace query
• #8875 - Remove truncation and overflow team invitation URL
• #8772 - Update team deletion confirmation modal
• #8890 - Added a new root cmd to Gitpod CLI. The tasks cmd allows listing tasks and attaching to them.
• #8914 - Add sudo permission to custom images, force NOPASSWD
• #8867 - [kots]: configure werft build command
• #8683 - Added first draft of a public API
• #8857 - [KOTS]: add recommended preflights
• #8892 - [kots]: escape golang template variables for Helm resources
• #8844 - [kots] Add a pre-flight check for `cert-manager
• #8835 - Rerunning prebuilds direct to the prebuild logs view, and rerunning is not allowed from the /prebuilds page.
• #8821 - fix missing index on Workspace (id, deleted)
• #8825 - [server] Improve GitHub Enterprise avatars handling
• #8854 - fix broken image builds
• #8858 - [gitpod-db] add index on workspaceDB.Type Column
• #8871 - [kots]: remove wait-for-jobs
• #8870 - [kots]: remove GCP DNS resolver
• #8827 - Allow use of the —privileged flag with docker.
• #8837 - [installer]: allow for minified config YAML
• #8785 - [kots] Remove cert-manager from the Gitpod package
• #8808 - [loadgen] Update benchmark images
• #8742 - Enable egress metrics for agent-smith
• #8822 - [kots]: removed the cert-manager issuers
• #8491 - [kots]: use Helm for the Installer job
• #8721 - Document ClusterService rpcs and messages
• #8699 - Clarified wording of “timeout” feature on the settings/plans page
• #8718 - ws-manager-bridge logs WorkspaceStatus events
• #8644 - Fix setting sync limit failure in some cases
• #8793 - fix caching of GitHub server-server queries
• #8593 - Make the licensing match what’s advertised
• #8770 - [kubecdl] Fix server name pattern
• #8741 - Update code to 1.65.2

Support for GitHub Enterprise Server

Gitpod now works with public, private, or internal repositories on your own instance of GitHub Enterprise (GHE). To set this up, please follow our 2-step guide in the documentation.

For feedback, please use the dedicated feedback issue or chat with us.

Fixes and improvements

• #8533 - Update k8s go dependencies to v1.23.4Update prometheus to v1.12.1 CVE-2022-21698Update containerd to v1.6.0
• #8578 - Support user-modifiable cgroupv2 structure
• #8583 - Remove unused pod labels
• #8580 - [installer] Registry facade should not use a port from node ports range
• #8555 - Add docker images for gpctl and kubecdl
• #8590 - Update the docs for cgroup v2
• #8471 - Support cpu limiting using cgroup v2
• #8629 - Disable cache reclaim when cgroup v2
• #8550 - Add support for private registries
• #8632 - Admins cannot search empty strings or partial matches on workspace search.
• #8574 - Support GitHub Enterprise
• #8689 - [kots]: create dev channels in KOTS and formalise the release process
• #8568 - Rate-limit workspace prebuilds to 50 per minute (rolling-window) by default, configurable through config.
• #8633 - [kots]: make the self-hosted cert more explicitly selectable
• #8486 - improve robustness of startWorkspaceimprove feedback for errors during cluster selectionimprove monitoring for cluster selection errors
• #8547 - [installer]: add annotation to make DB resources restart if changes
• #8622 - [installer] Add network policy for registry-facade access to coredns
• #8562 - Fix user detail bug that fetches all workspaces.
• #8558 - [dashboard] Don’t always print ‘Connecting to workspace logs…’ (it’s somewhat misleading)
• #8546 - Link to privacy policy from login page
• #8395 - [kots]: add the KOTS installation manifests
• #8503 - Free text search on workspace admin dashboard is not enabled anymore.
• #8363 - Remove ghost from the codebase
• #8477 - Renamed danger-use-unsupported-config flag in the installer to `use-experimental-config
• #8527 - [installer]: correct the stored config to include apiVersion
• #8519 - Try harder to update workspace annotation to prevent workspace from being marked as failed erroneously.
• #7831 - Git Integrations UI – improve handling of host name.
• #8428 - Deal with when cpu.cfs_quota_us is negative
• #8435 - Docker in workspaces now allows mapping the user id of a container user to the workspace gitpod user
• #8463 - Improve handling of an error when pod fails to start due to out of memory error on the node
• #8460 - [installer]: remove jaeger operator from the config
• #8402 - Admins can find teams, see team details, and change a team member’s role.
• #8211 - Add Replicated as a Gitpod license evaluator
• #8330 - Improve error handling for workspace cluster register & updateShow all admission constraints for workspace cluster list
• #8307 - Add max lifetime timeout for a workspace
• #8389 - [installer] Ensure multiple ws-proxy replicas are scheduled in different nodes
• #8401 - Make -c optional in installer, while allowing the passed config to be flexible
• #8373 - Show correct admin telemetry settings during first visit
• #8376 - Remove Jaeger operator
• #8266 - Make Open VSX upstream URL configurable in the installer for air-gap installations
• #8380 - Pre-populate Cmd+O modal and sort suggested context URLs by most-recently-used first

Making snapshots safer for sharing

Gitpod now restricts access to workspaces opened with snapshot URLs.

Users must have access to the git repository in the snapshot, in order to open it.

If a snapshot URL user does not have read access to the repo, Gitpod will now show an error message. Previously, any logged-in Gitpod user could open snapshot URLs for any workspace.

This change matches what happens when users open a new workspace on a private repository, using a prefixed context url. The change also helps to prevent leakage of sensitive or proprietary files via snapshots. To learn more about collaboration and sharing, please have a look at our documentation

Breaking change

This change may impact you if you are intentionally sharing a private repository using a snapshot, say for an interview.

Workarounds

• Use a public repository instead of a private one.
• Invite users to the private repository (or to the team on the org) as collaborators.
• Share a running workspace instead of a snapshot URL.

Feedback

As always, please contact Gitpod if you have any feedback to share with us.

Open in Gitpod

It’s even easier now to open a repository in a new Gitpod workspace.

Type cmd+O (ctrl-O on Windows) while on any page in the dashboard at gitpod.io.

This will pop up an input where you can paste a context URL for a git repository, and immediately open a workspace, just like you are used to with the gitpod.io/# prefix.

Instead of pasting a URL, you can start typing the name of a repository, and Gitpod will suggest repositories from recent workspaces, as well as from your connected git provider. Even our popular example template repositories can be opened this way.

Always ready to code 🚀

Fixes and improvements

• #8234 - Add stress test for mount proc
• #7523 - messagebus: remove cross-cluster dependency
• #8275 - Update the usage of nsinsider.
• #8288 - [installer] Installer does not set default nameserver settings for workspaces anymore
• #8289 - Improve handling of “Out of Memory” error when starting up workspaces
• #8067 - [server]: Add totalUsers, totalWorkspaces, and totalInstances fields to telemetry data
• #8270 - [self-hosted] Skip MinIO client configuration in the MinIO container because it breaks air-gap installations.
• #8086 - Bitbucket Server: Authorize with Bitbucket Server 7.20 and start workspaces.
• #8227 - [server] Disable perMessageDeflate on websockets

New workspace images built with Dazzle v2

By default, your Gitpod workspaces are based on a Docker image called gitpod/workspace-full. It contains all sorts of tools, SDKs and languages you may need — so you are ready-to-code with no friction.

What if you were only interested in Rust though, or Node.js LTS? You could create a custom Dockerfile, tell Gitpod about it and all would be fine. It would even be pretty simple to do.

At Gitpod, we are all about removing friction and frequently ask ourselves, “How can we improve?“. So we came up with an even easier solution. We are now in a position to create much more fine-grained workspace images!

To start this next era, we recently built a whole bunch of new images with Dazzle v2. Dazzle is a Docker/OCI image builder and its goal is to build independent layers where a change to one layer does not invalidate the ones sitting “above” it.

Compared to the previous version of Dazzle, the new v2 is about 5x faster, more reliable and less hacky 🔨.

Here is a list of what you can use today:

• gitpod/workspace-c
• gitpod/workspace-clojure
• gitpod/workspace-go
• gitpod/workspace-node
• gitpod/workspace-node-lts
• gitpod/workspace-python
• gitpod/workspace-ruby-2
• gitpod/workspace-ruby-3
• gitpod/workspace-rust

For an up-to-date list of available images, please refer to this list.

In your .gitpod.yml, all you need to do is add the following line:

yml

image: gitpod/workspace-xyz

As if this wasn’t exciting enough, this new solution lays the foundation for some very cool features you will be able to leverage directly to create custom images for your workspaces.

To tease this a bit more, imagine a future where you can pick & choose which tools you’d like to install in your workspace and Gitpod will automagically provide them to you at lightspeed, or thereabouts.

We are interested in your feedback and suggestions, please let us know in our dedicated feedback issue or chat with us.

Fixes and improvements

• #8119 - Added support for Git LFS during content init
• #8134 - Enable id check for seccomp notify
• #8139 - Improved workspace memory-pressure eviction resilience
• #8161 - Add workspace start request debug logging to ws-manager
• #8179 - A bit of improvements to cache_reclaim
• #8132 - [GitHub] Fix the user account picked for a prebuild.
• #8143 - Update code to 1.64.2
• #8112 - Autofix: upgrade-nvm-tools
• #8099 - fix dashboard contextURL handling
• #7569 - Support private dotfiles repo
• #8100 - Make ContextURL.parseToURL support the newly-accepted git@[host]:[user]/[repo].git format
• #8036 - Refactor dynamic CPU limiting to provide fairer scheduling.
• #8093 - Fix wrong token selection if multiple found for a profile.
• #7715 - [server][dashboard] Improve ‘New Workspace’ modal with a search input, keyboard navigation, and a new context URL suggestion API
• #7833 - Fix Bitbucket push event handling
• #8073 - configure basic rate-limiting for `startWorkspace
• #7727 - [installer]: add jaeger sampling options to the tracing object
• #7923 - Improved in-transit security of user environment variables
• #7968 - Fix missing status updates for prebuilds.
• #7940 - reduce idle DB load on SH installations
• #7978 - [gitlab] user-scoped env vars can now be filtered for nested repos on Gitlab
• #7882 - Admins can do a text search for projects and their associated prebuilds.
• #7951 - [server] Support ‘git@[host]:[user]/[repo].git’ format in context URLs
• #7839 - [installer]: put component ownership under webapp/workspace teams
• #7926 - [wa-manager] Refactor connectToWorkspaceDaemon helper

Project-level environment variables

It’s time to bring environment variables to Projects, and with that to Prebuilds as well!

Environment variables can now be set for individual Projects, which automatically makes them available when Gitpod runs a Prebuild for your project.

By default, these environment variables are not accessible in workspaces. You can, if you desire so, make them available in workspaces too. However, keep in mind that if you do so, anyone who starts a Gitpod workspace for your project will see the value of these environment variables.

To get started, make sure you have created a project at gitpod.io/new. You will then be able to visit its Settings page, where you find a new Variables section.

We are interested in your feedback and suggestions, please let us know in our dedicated feedback issue or chat with us.

Fixes and improvements

• #7895 - werft run github -j .werft/clean-up-werft-build-nodes.yaml -f
• #7873 - [Installer]: release 2022.01
• #7769 - [installer] Add missing kube-rbac-proxy container in ws-manager deployment
• #7774 - [installer] Do not start binaries in verbose mode
• #7362 - - Refactor JB integration to connect over SSH instead of CWM links.- Provide Gitpod integration in JB Gateway.
• #7732 - [Dashboard]: add send telemetry to admin settings
• #7801 - [installer]: add namespace to validate cluster command
• #7837 - Fix “token not found” issues.
• #7430 - Remove ws-scheduler component
• #7760 - Support heartbeats from SSH sessions
• #7591 - [server]: Create installation admin controller
• #7752 - [installer] Fix invalid tag name for image build template
• #7302 - [dashboard] Error messages on workspace creation when the repository is not found, will now also display the name of the repository
• #7753 - Improved feedback when content initialisation fails
• #7514 - Autofix: upgrade-nvm-tools
• #7730 - [installation-telemetry]: log data sent to Segment
• #7472 - [ws-manager] Improve workspaces PodAffinity
• #7657 - Make proc mounts more reliable which affects parallel Docker container startup
• #7623 - [installer] Fix ws-daemon image pull policy
• #7656 - [installer] Fix lifecycle PostStart label update
• #7670 - [installer] Fix registry-facade ClusterRoleBinding name
• #7660 - [installer] Switch default log level to info
• #7687 - [installer] Telemetry should not run in workspace clusters
• #7633 - Admin users can download the account statement.
• #7295 - Introduce Project-level environment variables
• #7659 - [dashboard] Don’t offer to add common email domains as a verified student domains in Admin
• #7625 - [installer] Fix mysql image pull policy
• #7642 - [Installer]: remove the deprecated TypeORM migration command

Dotfiles support in Beta

Happy new year from us at Gitpod 🥂!

We kick off 2022 with the availability of dotfiles support for anyone - currently in Beta.

If you are already familiar with dotfiles, configure it in your Gitpod preferences. All we need is a URL to your dotfiles repository. We will do the rest whenever you start a new Gitpod workspace. Enjoy 😊.

What are dotfiles, anyway?

You may have seen a .bashrc file or similar in a Unix environment. Basically, a place for you to configure and customize your shell. The operating system runs commands in these dotfiles automatically. This ensures your environment always has your customizations applied when you start your computer.

Dotfiles allow you to really customize your workflow and hence can increae your productivity significantly. It’s well worth looking into.

With today’s announcement, you can now leverage these exact same files in all your Gitpod workspaces! This removes one more friction for anyone who’s been on the fence as to whether or not cloud-based developer environments are worth exploring. Invest an hour today, you may like what you find. Start at gitpod.io/preferences.

Please try it out and share your experience with us and the Gitpod community. You can learn more about Dotfiles in the documentation.

We are interested in your feedback and suggestions, please let us know in our dedicated feedback issue or chat with us.

Fixes and improvements

• #7387 - Provide SLSA/in-toto provenance for the build
• #7606 - Removed “workspaces” from projects and teams and have a single global workspaces list, that shows all my workspaces.Made the single “workspaces” list the default landing place in the dashboard.
• #7504 - The GraphQL API has been removed
• #7241 - Route users to Discord for support
• #7503 - [installation-telemetry]: initial commit plus installer setup
• #7535 - [GitHub] Optionally prevent merging pull requests when prebuilds fail.
• #7578 - Add bottom padding for Projects, Branches, and Prebuilds pages
• #7596 - [installer] Adjust rabbitmq helm chart probes configuration
• #7156 - [Installer]: simplify container image mirroring
• #7508 - [installer]: use a pointer deref if the ssh gateway secret does not exist
• #7391 - Use repository org and name for workspace ids.
• #7512 - [ws-manager] Adjust probe InitialDelaySeconds
• #7510 - [installer] Adjust default MySQL value
• #7463 - Adds analytic tracking to git commands requiring the git credential manager (remote-facing commands)
• #7511 - [installer] Adjust mysql helm chart probes configuration

Self-managed k3s on GCP

Gitpod’s services run on Kubernetes and are what you would consider a “classic cloud-native application”. When you start a workspace for your project, we also run that on Kubernetes, but the requirements are very different from what Gitpod services need.

To run your workspaces, we deeply integrate with the Kernel, the container runtime and the Kubernetes control plane.

Up until recently, everything above ran on Google Cloud’s Kubernetes Engine (GKE). This continues to be the case for Gitpod’s services, but we moved user workspaces to self-managed k3s on GCP.

In short, this move brings better performance that will benefit your daily work, but also gets us closer to upstream and provides us with more flexibility. It is a foundation we put in place to build upon in the weeks and months to come!

Before you decide to follow our lead though, please see our CTO Chris’ in-depth explanation of benefits, gotchas and overall details of this migration.

Fixes and improvements

• #7312 - Profile of the user who already added a project is linked.
• #7177 - Allow auth provider secrets to be passed in via a secret
• #7012 - Allow setting a name and a description for each port on .gitpod.yml
• #7354 - Fix Team Workspace Success Criteria dashboard
• #7107 - [installer]: update docker-registry to allow for pod security policy application
• #6827 - 1. [installer] Add a namespace for the cert-manager self-signing issuer so it can be uninstalled using the configmap.2. [installer] Set EnableLocalApp to true by default.
• #7206 - [installer]: correct the starts_with validation on the config
• #7200 - [installer]: separate server and IDE components
• #7163 - Improved start page when a GitHub app is not installed.

JetBrains desktop available in beta

Gitpod currently has IntelliJ, GoLand, PhpStorm and PyCharm released in beta. The rest of the JetBrains IDE’s are all coming to Gitpod very soon, watch this space!

Previously, when you loaded a new Gitpod workspace, you would find yourself in a VS Code Browser experience. Using a browser editor like VS Code Browser is the main way Gitpod can get you “ready to code” instantly.

However, whilst we know that VS Code is the most widely adopted editor on the market (which is why we started with VS Code), Gitpod is not only built for VS Code users!

Gitpod is for teams, and companies of all shapes and sizes. We’re here to support, and integrate with as many of the different developer workflows used in modern software development. After all, it’s your dev environment, so you should be able to set it up your way.

And that’s why today, we’re happy to share that JetBrains desktop is now in beta!

You can get started using the JetBrains IDE’s today by: heading over to your Gitpod preferences page, enabling your favourite JetBrains desktop IDE’s, and restarting any running workspaces. The next time you start a workspace, you’ll be prompted about which editor to use: VS Code Browser, VS Code Desktop, or your preferred JetBrains IDE. However, even when you open a Gitpod workspace with a desktop editor, you still get the ease and developer experience of using VS Code Browser to edit and work on the same workspace and code at the same time, they’re entirely synced.

Work on your desktop if you like, share your workspace if you like, the choice is yours! To keep an eye on which editors we support at any given time, check the editors docs.

We are interested in your feedback and suggestions, please let us know in our dedicated feedback issue or chat with us.

Fixes and improvements

• #7004 - Add PyCharm desktop IDE.
• #6847 - The “Your Workspace is Ready” page for desktop IDEs now has “Stop Workspace” and “Go to Dashboard” actions.
• #6721 - When a user deletes their account, own projects will be deleted and made available to be added again.
• #6671 - Add VS Code Desktop in the preferences to always open your workspace in VS Code Desktop
• #6747 - [dashboard] Change default color theme from Light → System
• #6713 - Allow all team members to cancel a team prebuild
• #6505 - Open up JetBrains desktop IDE feature (BETA) for all users
• #6546 - Prebuilds can run for GitLab subgroup projects.
• #6464 - Switch to shallow git clone and add unshallow feature
• #6144 - make “snapshots” more reliable

Self-Hosted

• #6621 - Allow use of external container registry
• #6606 - Add support for GCP CloudSQL
• #6543 - Make the installer updatable

Gitpod Self-Hosted installers

If you prefer to install Gitpod in your own environment, we are pleased to announce this process has become a whole lot simpler.

Say hello to make install 🎉!

Yes really, our shiny new installer scripts take care of the heavy lifting while all we ask from you is to configure a file or two (depending on your hosting provider) and you’re up and running in no time.

Get started today with installer guides for:

• Amazon Elastic Kubernetes Service (EKS)
• Google Kubernetes Engine (GKE)
• Microsoft Azure Kubernetes Service (AKS)

Please let us know what you think via Twitter @gitpod or chat with us at https://www.gitpod.io/chat.

Fixes and improvements

• #6652 - Bitbucket-only users get an error message now on New Project page
• #6775 - make DB layer more robust against odd DB values
• #6847 - The “Your Workspace is Ready” page for desktop IDEs now has “Stop Workspace” and “Go to Dashboard” actions.
• #6031 - add GIT_AUTHOR_EMAIL to the environment variables mentioned in account settings
• #6883 - [dashboard][server] Make all project slugs unique within a team or user account by adding a unique suffix
• #6702 - Add container registry and database secret checks
• #6716 - Configure and validate the external database
• #6753 - [installer]: fix the auth provider config
• #6682 - [gpctl] Support forceful cluster de-registration
• #6760 - [installer]: fix jaeger operator misconfiguration
• #6733 - [ws-daemon] Fix resource leak during proc mounts
• #6745 - Configure Azure blob storage for installer
• #6860 - [image-builder] Fix authentication issues with external registries
• #6862 - Apply node affinities to components
• #6870 - [ws-proxy] Improve TLS default configuration
• #6893 - Set internal certs to 90 day duration
• #6892 - Change Minio to forked version

Improved workspace startup times

Speeeed 🚀! When you start a new workspace, we changed how we clone your repository. Going forward, we have a two step approach:

1. Clone the most recent commit only (with the depth=1 git flag)
2. About ten seconds later, we start to fetch 20 additional commits

Thanks to this, we let you start your work sooner while we fetch a few more commits. You can find the details of this change in the #6464 pull request.

Please let us know what you think via Twitter @gitpod or chat with us at https://www.gitpod.io/chat.

Fixes and improvements

• #6582 - Update VS Code Web to 1.62.0
• #6462 - [ws-proxy] Decouple ws-proxy from ws-manager
• #6546 - Prebuilds can run for GitLab subgroup projects.
• #6577 - Preserve team scope in dashboard
• #6505 - Open up JetBrains desktop IDE feature (BETA) for all users
• #6636 - GCP object storage bugfixes
• #6621 - Allow use of external container registry
• #6606 - Add support for GCP CloudSQL
• #6591 - Create config map to allow uninstallation of app
• #6144 - make “snapshots” more reliable
• #6376 - New GitLab projects will have a slugified Project url
• #6584 - allow img-builder ingress from server

Tailscale on Gitpod

With the availability of Tailscale support, you can connect Gitpod workspaces to other resources & services needed. Think of a database hosted behind a corporate firewall or in your on-prem data center.

Equally exciting is the possibility to connect multiple Gitpod workspaces with each other. Imagine a project with microservices which all have their own git repository. Configure Tailscale in each repository and once you start workspaces, the individual services will be able to communicate with each other.

You can learn more about this topic in our Network Bridging documentation. Alternatively, we have a template repository with the required configuration you can apply to your own projects.

Please let us know what you think via Twitter @gitpod or chat with us at https://www.gitpod.io/chat.

Fixes and improvements

• #5865 - Make it possible to cancel pending or running Prebuilds
• #6273 - Deleted team’s name can be reused.
• #6312 - /admin: Improve performance of workspace queries
• #6048 - Replace /workspaces → /projects as default landing page for both users and teams
• #6038 - Truncate workspace context in the workspace deletion modal
• #6409 - Experimental support for CAP_NET_ADMIN in workspaces
• #6234 - Validate the cluster is in a state for Gitpod to be installed to
• #6265 - Installation config validation
• #6338 - Automated workspace deployment framework and design proposal and prelim checkin for workspace cluster creation
• #6453 - [ws-manager]: Add check for IdeImage not being present in the spec
• #6348 - Switch from dropbear to OpenSSH
• #6389 - Always enable the New Workspace button on the Configuration Page.

Introducing Teams and Projects

Up until today, you must have felt at times that your Gitpod dashboard is a pretty empty place 😔. All you had, besides settings and stuff, was a list of your active workspaces (not even old ones without changing the filter - yep yep, we fixed that too 😉).

We are so stoked to announce Teams & Projects (& Prebuilds) available in beta 🎉

To get started right away, gitpod.io/new.

Teams

You can now create teams (as many as you want) and invite your co-workers, friends & family to collaborate on your projects.

Projects

Remember .gitpod.yml, checked in to your project’s root directory? It’s still the first place we look for Gitpod configuration, but when you create a project in the Gitpod dashboard, we now do our best to be smart and suggest a sensible default configuration for your project (insert something something machine learning - jk, there’s no magic).

Bonus - Prebuilds 🤩

Nobody asked me, but if they had I would have said the announcement should have been Teams, Projects & Prebuilds 😅. How come?

For the first time ever, we now show you each and every prebuild we run for your project! Check the status, view the logs or trigger new prebuilds from within the dashboard.

When you use the new onboarding workflow at gitpod.io/new, we help you kick off your first prebuild. With prebuilds, Gitpod builds your dev environment for each change you push to your repository. This means, when you’re ready to open a new workspace, it’ll already have all init start tasks executed.

You can learn more in the docs.

Expect more updates to all this over time. For now we’d love to hear about your experience. Please let us know in the feedback issue, contact us via Twitter @gitpod or chat with us at https://www.gitpod.io/chat.

Fixes and improvements

• #6171 - Enable setting of DB username with DB_USERNAME envvar
• #6185 - Add ‘New Workspace’ context menu option to all Projects cards
• #6187 - [projects] Fix Project card bottom row layout
• #6074 - Truncate commit message on branches and prebuilds
• #5802 - Update Kubernetes dependencies to v0.22.2Update controller-runtime to v0.10.1
• #6158 - Fix: Ensures that string-based env values defined in .gitpod.yml are not set with enclosing quotation marks.
• #6090 - [image-builder-mk3] Fix image build error “did not produce a workspace image”
• #6218 - [ws-manager] Introduce stoppedByRequest annotation marking workspaces explicitly stopped using a StopWorkspace call
• #6164 - Add admission constraints to support fine-grained cluster selection
• #6107 - Fix re-running a Prebuild with a different out-of-repo configuration
• #6166 - [gitpod-protocol] Adjust typescript GRPC options
• #6163 - Refactor GRPC TLS connection defaults
• #6069 - Allow importing of Helm dependencies
• #6095 - VS Code: Add a Get Started with Gitpod walk-through

Automatic preview page reloads

A small, but mighty improvement to your web application preview. No more manual page refresh when you open the preview before the application’s port is ready.

Gitpod now reloads the page every five seconds, automatically. Once your application listens on a port, the preview will reload and you’re ready to code.

Please let us know what you think via Twitter @gitpod or chat with us at https://www.gitpod.io/chat.

Fixes and improvements

• #5836 - Make it possible to re-trigger failed or timed out Prebuilds
• #5640 - [Teams & Projects] Ask for authorization when viewing a project of a provider without connection
• #5967 - [teams] Fix joining teams from different DB region
• #5572 - Refactor integration tests using sigs.k8s.io/e2e-framework
• #5935 - [dashboard] fix accumulating websocket connections
• #5897 - [workspace] Make the workspace stopping mechanism more deterministic
• #5918 - [prebuilds] fix prebuild logs with multiple tasks
• #5693 - [image-builder] Include environment variables in the built workspace image
• #5920 - [db] add missing index `d_b_prebuild_workspace.buildWorkspaceId
• #5899 - fix log format for meta components
• #5787 - improve websocket reconnection handling in the frontend

VS Code Desktop support

It’s here 🎉! Starting today, you can access Gitpod workspaces right from your locally installed VS Code - we call it “VS Code Desktop Support”. Yep, that’s right - keep your local settings¹ and benefit from Gitpod’s high-spec servers & automated prebuilds. As you would expect, your code continues to stay in an ephemeral Gitpod workspace which keeps each of your projects nicely isolated from one another.

To get started, all it takes is two steps:

1. Start a new Gitpod workspace (learn how in the docs).
2. Open the command palette ( CtrlCmd + Shift + P ), type “Open in VS Code” and hit Enter .

This opens your local VS Code, connects to the Gitpod workspace and let’s you develop, test & debug your application as if it was running locally.

We continue to enhance this feature, but for now we’d love to hear about your experience. Please let us know in the feedback issue, contact us via Twitter @gitpod or chat with us at https://www.gitpod.io/chat.

If you are already familiar with the Local Companion app we announced in June, note that VS Code Desktop Support is built on top of it and you can continue to use the Local Companion app independently of VS Code.

Fixes and improvements

• #5511 - Breaking Change: Remove Theia settings and point to Code image
• #5633 - Update code to 1.60.0
• #4997 - OpenVSX proxy cache
• #5568 - GitLab users who have not completed the auth process on GitLab will be notified with an error message
• #5362 - [gitlab] Accept ’#’ sign in branches / context URLs
• #5180 - [docker-up] Update docker-compose and slirp4netns
• #5513 - [code] Add open dashboard menu option to home menu
• #5456 - vscode desktop on windows

Faster workspace startup times

A key metric we deeply care about at Gitpod (and I’m sure you do, too) is workspace startup time. In a world where you create and dispose of workspaces many times per day, the last thing you want is waiting for a workspace to start 🐌.

In this release, we made significant progress in lowering startup times 🏎. What initially may sound like complex changes turned out to be a +4 -4 pull request (#4847). Yay simplicity!

To give you an idea of the magnitute of improvement we’re talking about, here’s a before / after comparison with 30 workspaces started twice:

Before	Now

Did you pay close attention to the y-axis? From between 20 to 60 seconds down to 5 to 20 seconds!

Great work team, let’s shift our focus to other features. These improvements are certainly worth celebrating 🎂, but we’re hungry to drop these times by at least the same magnitude once or twice more! Team, finish your cake and get back to work 😉.

Please do let us know if you notice any differences with your project startup times. You can find us at www.gitpod.io/chat.

Fixes and improvements

• #4844 - Provide better feedback when gitpod.yml is invalid
• #4816 - [gp] env: handle multi-word values without quotes
• #4813 - [server] Handle releases/tag/in GitHub context parser
• #4743 - [code] confirm sharing
• #4738 - [code] serve each webview from own origin
• #4734 - [#4699] Handle error situations around /headless-logs endpoint
• #4115 - [server] store separate email used for commits (GitHub and GitLab). Thanks to @philschatz.