Self-hosting Gitpod: a shared operational model

Lou Bichard Product Manager at Gitpod

Mar 11, 2024

Gitpod for enterprises is a single-tenant, managed installation of Gitpod. It is self-hosted in your cloud account but vendor-managed and operated for you.

Think of it as having ‘Gitpod on-call to ensure the system’s reliability, quality and security - instead of your team. In fact, that’s exactly what it is. You enjoy all the benefits of CDEs, with minimal operational overhead.

Since Gitpod integrates with various systems, from image registries to secrets managers, it’s important to understand your operational responsibilities versus those Gitpod handles. This article covers exactly that.

Gitpod for enterprise architecture recap

Let’s understand Gitpod’s core architecture. Gitpod is a cloud development environment. At the heart of Gitpod, we have workspaces which are the development environments where your developers write their code. A workspace is based on one, or sometimes many git repositories and are designed to automatically connect with necessary registries, artifacts or secret managers, ensuring developers have all the tools they require to do their work.

Developers can use multiple workspaces, which automatically time out after inactivity. Workspace file systems are preserved until reactivation, with backups eventually being recycled. Workspaces can be scripted to install tools, or can be based on Docker images, necessitating connections to image registries. While most integrations are out-of-the-box, some require a bit of configuration:

1. Source control management like: GitHub, BitBucket or GitLab.
2. Identity providers for SSO like Okta or Google.
3. Image Registries like ECR or DockerHub.

The above overview only covers the core Gitpod application. However, we do need to also take into account where Gitpod is deployed. With Gitpod for enterprises, this deployment happens in your cloud account. More specifically, your AWS account. But, how does it work?

Above is a detailed architecture of Gitpod for enterprises.

Gitpod is installed through a CloudFormation template which runs in your AWS account. At the heart of the architecture, we have two Kubernetes clusters. One cluster manages the workspaces, while the other hosts Gitpod’s meta aspects, like the dashboard and API. The controllers periodically poll for software updates, and emit just enough telemetry from the installation to ensure it can be operated remotely by Gitpod. Again, a lot of these configurations work out-of-the-box, but some of the main customisations are:

1. Configuring your network setup and VPC integrations.
2. Attaching a custom domain, or resolving private DNS.
3. Granting permission for image registries at the infrastructure level.

With that context in mind, let’s outline the dimensions of operational ownership, detailing what Gitpod manages and what falls under your responsibility.

What Gitpod is responsible for

1. Application feature releases

Gitpod manages all feature releases on behalf of the customer. New updates are released automatically for customers, roughly once-per-day, and without downtime. Application updates are polled for by the controllers in the installation via an outgoing AWS PrivateLink connection. When an update is found, a controller inside the Gitpod cell applies the update to the application. All releases are rigorously tested, and Gitpod makes heavy use of feature flagging for releases.

2. Operations & telemetry

Gitpod selectively transmits events from its installation to facilitate operation. Gitpod is responsible for ensuring sanitizing any telemetry events for personally identifiable or sensitive information. If required, Gitpod can provide access to a copy of the data emitted from the through a Gitpod data store. While optional, this access offers customers additional reassurance that data emitted from the cell aligns with their expectations and understanding.

3. Workspace backup & restore

Gitpod automatically handles the backup and restoration of workspaces on behalf of customers. Those backups are persisted to S3 within the customer’s AWS accounts, and can be viewed, if required. Customers are not required to configure the backup process. Gitpod will also handle the cleanup of stale backups.

4. Application scaling & provisioning

Gitpod manages the scaling of the underlying nodes necessary for its operation. Customers do not need to specify scaling rules or worry about unused capacity for the underlying instances and nodes. Customers can manage workspace class sizing and timeout settings directly within the Gitpod application, providing control over these aspects without the complexity of managing underlying infrastructure.

5. Security updates

Gitpod is responsible for security updates in the installation, including timely patches of the nodes and other software components running in the installation. All dependencies required for Gitpod to run will be managed via the regular infrastructure or application update cycle.

6. Managed workspace image updates

Gitpod provides a number of workspace images that are useful to help customers get started quickly. Gitpod is responsible for updating these images. However, these default images may not include all necessary tools or configurations for every project. Therefore, Gitpod encourages customers to create and maintain their own workspace images, utilizing their image pipelines and automation to ensure their workspaces are fully equipped with the specific tools and settings their projects require.

What you are responsible for

1. The AWS account

The AWS account used for Gitpod is the responsibility of the customer. Gitpod is designed to operate without needing additional resources deployed into the AWS account, avoiding variability that could hinder its operational capabilities. Customers are required to configured AWS quotas,a step required only once during installation. Customers can also customize the CloudFormation template to apply tags and adhere to any cost attribution best practices.

2. TLS and custom CA certificate validity

When customers opt to customize the domain name of the Gitpod installation, they also take responsibility for the associated TLS certificate’s validity, including any necessary re-issuing. This also applies tofor any custom or private certificate authorities.

3. Workspace sizing

Gitpod manages the scaling of the underlying infrastructure, allowing users the freedom to select workspace sizes that best suit their needs from a list of options enabled for their organization. . Organization owners should view their billing data (available inside Gitpod) to ensure usage is inline with their needs.

4. Workspaces lifecycles (timeouts)

By default, Gitpod workspaces timeout to save cost. Timeouts can be managed by users, and via organization owner policies inside the application. Longer timeouts mean workspaces are running for longer, which can be useful for some types of workloads or use cases. Managing this variable cloud spend is the responsibility of the customer.

5. Custom workspace image updates

Gitpod provides out-of-the-box workspace images. However, workspaces can have their own custom workspace images. Customers who choose to create their own images will need to stay up-to-date with any patches or updates to those base images. In addition, maintaining a connection to an external registry.

6. Cost management

Within Gitpod, infrastructure costs are managed via AWS billing. You can use the out-of-the-box functionality from AWS for cost management. As mentioned, you can also apply custom tags to Gitpod architecture for finer-grained cost attribution.

7. Applying infrastructure updates

Application updates are released on an ongoing basis. Infrastructure updates, however, must be accepted and applied by the customer, though the process is swift. . Customers will receive a CloudFormation patch link for review before application.. Infrastructure changes are made sparingly, aiming for updates every few months rather than weeks, to minimize disruptions.

The power of a CDEs—but with very little to manage.

Gitpod for enterprises is designed to remove operational burden from our customers, and give them the full power of a CDE with as little as possible overhead. You can always try Gitpod for free or if you want to get started with Gitpod for enterprises right away, let our team know and we can talk through any questions that you might have!