Gitpod relies on certain components and services for it to function. By default, most of these can be automatically installed in-cluster during installation. However, you can also configure Gitpod to use your own version of these that may or may not live inside the cluster.
|Bucket Storage||Use default or bring your own|
|Database||Use default or bring your own|
|Image Registry||Use default or bring your own|
|Source Control Management System||Use default or bring your own|
By default, MinIO is installed in the cluster to store static content and to back an in-cluster image registry. During the installation, process you can also configure Gitpod to use your own storage provider. Support storage services are:
- AWS S3
- Azure Blob Storage
- Google Cloud Storage
Gitpod uses a MySQL database to store user data. By default Gitpod ships with a MySQL database built-in and data is stored using a Kubernetes PersistentVolume. For production settings, we recommend operating your own MySQL database (version v5.7 or newer). Which database is used can be configured during installation.
Gitpod relies on an image registry to store images used to start workspaces. By default, a docker based image registry backed by MiniIO is installed in the cluster (this can be configured during the installation). However, Gitpod is also compatible with any registry that implements the Docker Registry HTTP API V2 specification.
Using Amazon Elastic Container Registry (ECR)
Amazon ECR does not implement this spec fully. The spec expects that, if an image is pushed to a repository that doesn’t exist, it creates the repository before uploading the image. Amazon ECR does not do this - if the repository doesn’t exist, it will error on push.
To configure Gitpod to use Amazon, you will need to use the in-cluster registry and configure it to use S3 storage as the backend storage.
containerRegistry: inCluster: true s3storage: bucket: <name of bucket> certificate: kind: secret name: s3-storage-token
The secret expects to have two keys:
Gitpod expects to be connected to a Source Control Management System (SCM) such as GitLab in order to function. You can find out more about which SCMs are supported and how to connect to them in the Integrations section. You will also be guided through connecting your SCM once you access your Gitpod installation for the first time.
Cert-manager must be installed in your cluster before you can install Gitpod. It is used to create and manage certificates needed to secure communication between the various internal Gitpod components. See the getting started guide for details on how to install cert-manager.
On this page