Gitpod provides on-demand, secure cloud development environments or CDEs. These environments include everything a developer needs, including tools, code, and dependencies, and can seamlessly be shared and cloned across the team.
There are two ways to consume the product: Via Gitpod Cloud, available via gitpod.io and via Gitpod Dedicated that is cloud development environment that is hosted by you and managed by Gitpod. This documentation walks through Gitpod Dedicated.
In both deployments models, a control plane keeps the installation up-to-date. The system polls for updates every minute. Once a new one is available, it pulls the package down. The system is built so that no downtime is needed for updates, and workspaces are never affected.
- Getting Started
- (Not) modifying your AWS Account
- Updating the Gitpod Dedicated Infrastructure
- Getting Access to the Instance for Debugging
- Using Custom Domains
- Using a Custom or Private CA
- Using Private VPC Resolvers
- Accessing data exported from your instance
- Reserving AWS Instances to Save Cost
- Deleting your Gitpod installation
Gitpod Cloud is a multi-tenanted solution that provides isolation and security by operating developer workspaces in their own set of Linux namespaces, such that they cannot interfere with others. The details of this setup have been shared publicly. Gitpod Cloud is best for teams who are ready to get started right away and prefer no installation.
Gitpod Dedicated is a single-tenant solution also maintained and operated by Gitpod. The entire application is deployed within a customer’s cloud account, acting like an outpost of Gitpod within their cloud organization, very similar to the way a self-hosted solution would behave. The Gitpod Dedicated Control Plane is only responsible for monitoring the status of the instance and managing updates:
Running Gitpod Dedicated within the customer’s infrastructure ensures that Gitpod does not have direct access to source code, running workspaces or other confidential resources. This satisfies many regulatory and compliance-related policies around data residency and access.
Gitpod Dedicated is best for organizations who have more stringent security requirements.
|Gitpod Cloud||Gitpod Dedicated|
|Deployment||No customer input required - sign up and start for free||Hosted within customer’s cloud account, requires setting up a new AWS account and executing a CloudFormation template within it|
|Management||Deployed and operated by Gitpod||Deployed and operated by Gitpod|
|Data Isolation||Data (e.g. workspace backups) is isolated at the application layer, and is stored in Gitpod’s cloud account||Data (e.g. workspace backups) is isolated at the infrastructure level and stays within the cusomter’s network and cloud account|
|Compute Isolation||Shared infrastructure||Dedicated infrastructure running in the customer AWS account|
|Observability||Health info and metrics sent to Gitpod||Health info and metrics sent to Gitpod|
|Region||Fixed regions||Choose an AWS region|
|Cost||Cheaper due to shared infrastructure||More expensive due to single-tenant infrastructure - but existing cloud discounts/credits can be used to cover compute cost|
Gitpod Dedicated is deployed into the customer AWS account using a CloudFormation template. The actual deployment process itself takes around 30 minutes. To begin, create a new AWS account within the customer’s AWS organization. Then, execute a CloudFormation template that creates the necessary infrastructure. After that, the instance will register itself with the Dedicated Control plane and installs the latest version of Gitpod.
Gitpod Dedicated is deployed into the customer AWS account using a CloudFormation template. To begin, create a new AWS account within the customer’s AWS organization. Then, execute a CloudFormation template that creates the necessary infrastructure. After that, the instance will register itself with the Dedicated Control plane and installs the latest version of Gitpod.
Once deployed, the instance is able to connect to a source control management system (SCM) and other development resources on a corporate network privately (using a Transit Gateway attachment).
To start the first Gitpod workspace, navigate to the instance and configure an integration to an SCM system. Gitpod will then manage and operate the instance. For more information on how updates are handled, please see the Deployment and Updates section.
To begin, follow the Getting Started guide.