- Introduction
- Getting started
- Configuration
- Dev Container
- Automations
- Editors
- VS Code
- Cursor
- JetBrains
- Zed
- Gitpod Desktop
- Self-Hosted Runner
- AWS
- Azure
Coming soon
- GCP
Coming soon
- Linux
Coming soon
- Source Control
- GitHub
- GitLab
Coming soon
- Bitbucket
Coming soon
- Integrations
- Port sharing
- Personal access tokens
- Administration
- Organizations
- Projects
- Billing
- Reference
- CLI
Self-Hosted Runner
Runners are single-tenant, self-hosted, flexible orchestrators of remote development environments. They are self-hosted in order to compartmentalize any sensitive information related to your development environments. Runners are responsible for operational tasks like
- Scaling
- Backup
- Caching
To reduce operational overhead, runners offload all non-sensitive administration responsibilities to the management plane.
Currently, Gitpod has one self-hosted runner than can be deployed on AWS using a CloudFormation template and it can be shared across your organization. Organizations can have as many runners as needed, and deploy them in any region or availability zone to support remote teams in different timezones, adhere to data sovereignty, and other compliance requirements.
To create or modify runners, you must have an admin role inside the Gitpod organization.
Once deployed, you don’t need to interact with the infrastructure directly. Through Gitpod Desktop you can configure:
- which repositories a runner can access
- what environment classes are supported
- share it with your organization to allow any member to use it when creating environments