Chapter 6. Advanced configuration options

The following section describes advanced deployment and configuration methods for Red Hat CodeReady Workspaces.

6.1. CodeReady Workspaces configMaps and their behavior

The following section describes CodeReady Workspaces configMaps and how they behave.

A configMap is provided as an editable file that lists options to customize the CodeReady Workspaces environment. Based on the CodeReady Workspaces installation method, configMaps can be used to customize the working environment. The type of configMaps available in your CodeReady Workspaces environment varies based on the method used for installing CodeReady Workspaces.

6.1.1. CodeReady Workspaces installed using an Operator

Operators are software extensions to OpenShift that use custom resources to manage applications and their components.

CodeReady Workspaces installed using the Operator provides the user with an automatically generated configMap called codeready.

The codeready configMap contains the main properties for the CodeReady Workspaces server, and is in sync with the information stored in the CheCluster Custom Resource file. User modifications of the codeready configMap after installing CodeReady Workspaces using the Operator are automatically overwritten by values that the Operator obtains from the CheCluster Custom Resource.

To edit the codeready configMap, edit the Custom Resource manually. The configMap derives values from the CheCluster field. User modifications of the CheCluster Custom Resource field cause the Operator to change the attributes of the codeready configMap accordingly. The configMap changes automatically trigger a restart of the CodeReady Workspaces Pod.

To add custom properties to the CodeReady Workspaces server, such as environment variables that are not automatically generated in the codeready configMap by the Operator, or to override automatically generated properties, the CheCluster Custom Resource has a customCheProperties field, which expects a map.

For example, to overrride the default memory limit for workspaces, add the CHE_WORKSPACE_DEFAULT__MEMORY__LIMIT__MB property to customCheProperties:

apiVersion: org.eclipse.che/v1
kind: CheCluster
metadata:
  name: eclipse-che
  namespace: che
spec:
  server:
    cheImageTag: ''
    devfileRegistryImage: ''
    pluginRegistryImage: ''
    tlsSupport: true
    selfSignedCert: false
    customCheProperties:
      CHE_WORKSPACE_DEFAULT__MEMORY__LIMIT__MB: "2048"
  auth:
...

Previous versions of the CodeReady Workspaces Operator had a configMap named custom to fulfill this role. If the CodeReady Workspaces Operator finds a configMap with the name custom, it adds the data it contains into the customCheProperties field, redeploys CodeReady Workspaces, and deletes the custom configMap.

6.2. Configuring namespace strategies

Note

The term namespace (Kubernetes) is used interchangeably with project (OpenShift).

The namespace strategies are configured using the CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT environment variable.

Warning

CHE_INFRA_KUBERNETES_NAMESPACE and CHE_INFRA_OPENSHIFT_PROJECT are legacy variables. Keep these variables unset for a new installations. Changing these variables during an update can lead to data loss.

6.2.1. One namespace per workspace strategy

The strategy creates a new namespace for each new workspace.

To use the strategy, the CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT variable value must contain the <workspaceID> identifier. It can be used alone or combined with other identifiers or any string.

Example 6.1. One namespace per workspace

To assign namespace names composed of a che-ws prefix and workspace id, set:

CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT=che-ws-<workspaceID>

6.2.2. One namespace for all workspaces strategy

The strategy uses one predefined namespace for all workspaces.

To use the strategy, the CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT variable value must be the name of the desired namespace to use.

Example 6.2. One namespace for all workspaces

To have all workspaces created in che-workspaces namespace, set:

CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT=che-workspaces

Important

To run more than one workspace at a time when using this strategy together with the common PVC strategy, configure persistent volumes to use ReadWriteMany access mode.

6.2.3. One namespace per user strategy

The strategy isolates each user in their own namespace.

To use the strategy, the CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT variable value must contain one or more user identifiers. Currently supported identifiers are <username> and <userId>.

Example 6.3. One namespace per user

To assign namespace names composed of a che-ws prefix and individual usernames (che-ws-user1, che-ws-user2), set:

CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT=che-ws-<username>

Important

To run more than one workspace at a time when using this strategy together with the common PVC strategy, configure persistent volumes to use ReadWriteMany access mode.

To limit the number of concurrently running workspaces per user to one, set the CHE_LIMITS_USER_WORKSPACES_RUN_COUNT environment variable to 1.

To limit the number of concurrently running workspaces per user to one (1):

For Operator deployments: set the spec.server.cheCustomProperties.CHE_LIMITS_USER_WORKSPACE_RUN_COUNT variable of the CheCluster Custom Resource (CR) to 1.

6.2.4. Allowing user-defined workspace namespaces

CodeReady Workspaces server can be configured to honor the user selection of a namespace when a workspace is created. This feature is disabled by default. To allow user-defined workspace namespaces:

For Operator deployments, set the following field in the CheCluster Custom Resource:
```
allowUserDefinedWorkspaceNamespaces
```

6.3. Deploying CodeReady Workspaces with support for Git repositories with self-signed certificates

This procedure describes how to configure CodeReady Workspaces for deployment with support for Git operations on repositories that use self-signed certificates.

Prerequisites

Git version 2 or later

Procedure

Configuring support for self-signed Git repositories.

Create a new configMap with details about the Git server:
```
$ oc create configmap che-git-self-signed-cert --from-file=ca.crt \
  --from-literal=githost=<host:port> -n {prod-namespace}
```
In the command, substitute <host:port> for the host and port of the HTTPS connection on the Git server (optional).
Note
- When githost is not specified, the given certificate is used for all HTTPS repositories.
- The certificate file must be named ca.crt.

Configure the workspace exposure strategy:

Update the gitSelfSignedCert property. To do that, execute:

$ oc patch checluster codeready-workspaces -n workspaces --type=json \
  -p '[{"op": "replace", "path": "/spec/server/gitSelfSignedCert", "value": true}]'

Create and start a new workspace. Every container used by the workspace mounts a special volume that contains a file with the self-signed certificate. The repository’s .git/config file contains information about the Git server host (its URL) and the path to the certificate in the http section (see Git documentation about git-config). For example:
```
[http "https://10.33.177.118:3000"]
        sslCAInfo = /etc/che/git/cert/ca.crt
```

6.4. Adding self-signed SSL certificates to CodeReady Workspaces

When a CodeReady Workspaces user attempts to authenticate with RH-SSO that is using OpenShift OAuth, the authentication fails if the RH-SSO does not know the certificates needed for authorization.

To fix this problem, configure CodeReady Workspaces to authorize HTTPS communication with various components, such as identity and Git servers, by adding information about the self-signed SSL certificates to the CodeReady Workspaces configuration.

Prerequisites

The OpenShift command-line tool, oc is installed.

Procedure

Save the desired self-signed certificates to a local file system.
Create a new configMap with the required self-signed SSL certificates:
```
$ oc create configmap <configMap-name> --from-file=<certificate-file-path> -n=<che-namespace-name>
```
To apply more than one certificate, add another --from-file=<certificate-file-path> option to the above command.
Define a name for the newly created configMap.
Note
Use these steps with existing instances of CodeReady Workspaces. To install a new instance of CodeReady Workspaces with self-signed SSL certificates, create a new Che Custom Resource or Helm Chart property, based on the installation method selected, instead of updating the existing configuration.
- For a CodeReady Workspaces Operators deployment:
  Define a name for the newly created configMap by editing the spec.server.ServerTrustStoreConfigMapName Che Custom Resource property to match the previously created configMap:
  $ oc patch checluster codeready-workspaces -n che --type=json -p '[{"op": "replace", "path": "/spec/server/serverTrustStoreConfigMapName", "value": "<config-map-name>"}]'
Verification
If the certificates have been added correctly, the CodeReady Workspaces server starts and obtains RH-SSO configuration over HTTPS with a self-signed SSL certificate, allowing user to:
- Access the CodeReady Workspaces server.
- Log in using OpenShift OAuth.
- Clone from a Git repository that has a custom self-signed SSL certificate over HTTPS.

6.5. CodeReady Workspaces configMaps fields reference

6.5.1. `server` settings related to the CodeReady Workspaces server

Property	Default value	Description
`airGapContainerRegistryHostname`	omit	An optional host name or URL to an alternative container registry to pull images from. This value overrides the container registry host name defined in all default container images involved in a CodeReady Workspaces deployment. This is particularly useful to install CodeReady Workspaces in an air-gapped environment.
`airGapContainerRegistryOrganization`	omit	Optional repository name of an alternative container registry to pull images from. This value overrides the container registry organization defined in all the default container images involved in a CodeReady Workspaces deployment. This is particularly useful to install CodeReady Workspaces in an air-gapped environment.
`cheDebug`	`false`	Enables the debug mode for CodeReady Workspaces server.
`cheFlavor`	`codeready-workspaces`	Flavor of the installation.
`cheHost`	The Operator automatically sets the value.	A public host name of the installed CodeReady Workspaces server.
`cheImagePullPolicy`	`Always` for `nightly` or `latest` images, and `IfNotPresent` in other cases	Overrides the image pull policy used in CodeReady Workspaces deployment.
`cheImageTag`	omit	Overrides the tag of the container image used in CodeReady Workspaces deployment. Omit it or leave it empty to use the default image tag provided by the Operator.
`cheImage`	omit	Overrides the container image used in CodeReady Workspaces deployment. This does not include the container image tag. Omit it or leave it empty to use the default container image provided by the Operator.
`cheLogLevel`	`INFO`	Log level for the CodeReady Workspaces server: `INFO` or `DEBUG`.
`cheWorkspaceClusterRole`	omit	Custom cluster role bound to the user for the workspaces. Omit or leave empty to use the default roles.
`customCheProperties`	omit	Map of additional environment variables that will be applied in the generated `codeready-workspaces` config map to be used by the CodeReady Workspaces server, in addition to the values already generated from other fields of the `CheCluster` custom resource (CR). If `customCheProperties` contains a property that would be normally generated in `codeready-workspaces` config map from other CR fields, then the value defined in the `customCheProperties` will be used instead.
`devfileRegistryImage`	omit	Overrides the container image used in the Devfile registry deployment. This includes the image tag. Omit it or leave it empty to use the default container image provided by the Operator.
`devfileRegistryMemoryLimit`	`256Mi`	Overrides the memory limit used in the Devfile registry deployment.
`devfileRegistryMemoryRequest`	`16Mi`	Overrides the memory request used in the Devfile registry deployment.
`devfileRegistryPullPolicy`	`Always` for `nightly` or `latest` images, and `IfNotPresent` in other cases	Overrides the image pull policy used in the Devfile registry deployment.
`devfileRegistryUrl`	The Operator automatically sets the value.	Public URL of the Devfile registry that serves sample, ready-to-use devfiles. Set it if you use an external devfile registry (see the `externalDevfileRegistry` field).
`externalDevfileRegistry`	`false`	Instructs the Operator to deploy a dedicated Devfile registry server. By default a dedicated devfile registry server is started. If `externalDevfileRegistry` set to `true`, the Operator does not start a dedicated registry server automatically and you need to set the `devfileRegistryUrl` field manually.
`externalPluginRegistry`	`false`	Instructs the Operator to deploy a dedicated Plugin registry server. By default, a dedicated plug-in registry server is started. If `externalPluginRegistry` set to `true`, the Operator does not deploy a dedicated server automatically and you need to set the `pluginRegistryUrl` field manually.
`nonProxyHosts`	omit	List of hosts that will not use the configured proxy. Use \|` as delimiter, for example `localhost\|my.host.com\|123.42.12.32` Only use when configuring a proxy is required (see also the `proxyURL` field).
`pluginRegistryImage`	omit	Overrides the container image used in the Plugin registry deployment. This includes the image tag. Omit it or leave it empty to use the default container image provided by the Operator.
`pluginRegistryMemoryLimit`	`256Mi`	Overrides the memory limit used in the Plugin registry deployment.
`pluginRegistryMemoryRequest`	`16Mi`	Overrides the memory request used in the Plugin registry deployment.
`pluginRegistryPullPolicy`	`Always` for `nightly` or `latest` images, and `IfNotPresent` in other cases	Overrides the image pull policy used in the Plugin registry deployment.
`pluginRegistryUrl`	the Operator sets the value automatically	Public URL of the Plugin registry that serves sample ready-to-use devfiles. Set it only when using an external devfile registry (see the `externalPluginRegistry` field).
`proxyPassword`	omit	Password of the proxy server. Only use when proxy configuration is required.
`proxyPort`	omit	Port of the proxy server. Only use when configuring a proxy is required (see also the `proxyURL` field).
`proxyURL`	omit	URL (protocol+host name) of the proxy server. This drives the appropriate changes in the `JAVA_OPTS` and `https(s)_proxy` variables in the CodeReady Workspaces server and workspaces containers. Only use when configuring a proxy is required.
`proxyUser`	omit	User name of the proxy server. Only use when configuring a proxy is required (see also the `proxyURL` field).
`selfSignedCert`	`false`	Enables the support of OpenShift clusters with routers that use self-signed certificates. When enabled, the Operator retrieves the default self-signed certificate of OpenShift routes and adds it to the Java trust store of the CodeReady Workspaces server. Required when activating the `tlsSupport` field on demo OpenShift clusters that have not been setup with a valid certificate for the routes.
`serverMemoryLimit`	`1Gi`	Overrides the memory limit used in the CodeReady Workspaces server deployment.
`serverMemoryRequest`	`512Mi`	Overrides the memory request used in the CodeReady Workspaces server deployment.
`tlsSupport`	`false`	Instructs the Operator to deploy CodeReady Workspaces in TLS mode. Enabling TLS requires enabling the `selfSignedCert` field.

6.5.2. `database` configuration settings related to the database used by CodeReady Workspaces

Property	Default value	Description
`chePostgresDb`	`dbche`	PostgreSQL database name that the CodeReady Workspaces server uses to connect to the database.
`chePostgresHostName`	the Operator sets the value automatically	PostgreSQL Database host name that the CodeReady Workspaces server uses to connect to. Defaults to `postgres`. Override this value only when using an external database. (See the field `externalDb`.)
`chePostgresPassword`	auto-generated value	PostgreSQL password that the CodeReady Workspaces server uses to connect to the database.
`chePostgresPort`	`5432`	PostgreSQL Database port that the CodeReady Workspaces server uses to connect to. Override this value only when using an external database (see field `externalDb`).
`chePostgresUser`	`pgche`	PostgreSQL user that the CodeReady Workspaces server uses to connect to the database.
`externalDb`	`false`	Instructs the Operator to deploy a dedicated database. By default, a dedicated PostgreSQL database is deployed as part of the CodeReady Workspaces installation. If set to `true`, the Operator does not deploy a dedicated database automatically, you need to provide connection details to an external database. See all the fields starting with: `chePostgres`.
`postgresImagePullPolicy`	Always` for `nightly` or `latest` images, and `IfNotPresent` in other cases	Overrides the image pull policy used in the PostgreSQL database deployment.
`postgresImage`	omit	Overrides the container image used in the PostgreSQL database deployment. This includes the image tag. Omit it or leave it empty to use the default container image provided by the Operator.

6.5.3. `auth` configuration settings related to authentication used by CodeReady Workspaces installation

Property	Default value	Description
`externalIdentityProvider`	`false`	By default, a dedicated Identity Provider server is deployed as part of the CodeReady Workspaces installation. But if `externalIdentityProvider` is `true`, then no dedicated identity provider will be deployed by the Operator and you might need to provide details about the external identity provider you want to use. See also all the other fields starting with: `identityProvider`.
`identityProviderAdminUserName`	`admin`	Overrides the name of the Identity Provider admin user.
`identityProviderClientId`	omit	Name of an Identity provider (Keycloak / RH SSO) `client-id` that must be used for CodeReady Workspaces. This is useful to override it ONLY if you use an external Identity Provider (see the `externalIdentityProvider` field). If omitted or left blank, it will be set to the value of the `flavor` field suffixed with `-public`.
`identityProviderImagePullPolicy`	`Always` for `nightly` or `latest` images, and `IfNotPresent` in other cases	Overrides the image pull policy used in the Identity Provider (Keycloak / RH SSO) deployment.
`identityProviderImage`	omit	Overrides the container image used in the Identity Provider (Keycloak / RH SSO) deployment. This includes the image tag. Omit it or leave it empty to use the default container image provided by the Operator.
`identityProviderPassword`	omit	Overrides the password of Keycloak admin user. Override it only when using an external Identity Provider (see the `externalIdentityProvider` field). Omit or leave empty to set an auto-generated password.
`identityProviderPostgresPassword`	the Operator sets the value automatically	Password for The Identity Provider (Keycloak / RH SSO) to connect to the database. This is useful to override it ONLY if you use an external Identity Provider (see the `externalIdentityProvider` field).
`identityProviderRealm`	omit	Name of an Identity provider (Keycloak / RH SSO) realm. Override it only when using an external Identity Provider (see the `externalIdentityProvider` field). Omit or leave empty blank to set it to the value of the `flavor` field.
`identityProviderURL`	the Operator sets the value automatically	Instructs the Operator to deploy a dedicated Identity Provider (Keycloak or RH SSO instance). Public URL of the Identity Provider server (Keycloak / RH SSO server). Set it only when using an external Identity Provider (see the `externalIdentityProvider` field).
`oAuthClientName`	the Operator sets the value automatically	Name of the OpenShift `OAuthClient` resource used to setup identity federation on the OpenShift side. See also the `OpenShiftoAuth` field.
`oAuthSecret`	the Operator sets the value automatically	Name of the secret set in the OpenShift `OAuthClient` resource used to setup identity federation on the OpenShift side. See also the `OAuthClientName` field.
`openShiftoAuth`	`true` on OpenShift	Enables the integration of the identity provider (Keycloak / RHSSO) with OpenShift OAuth. This allows users to log in with their OpenShift login and have their workspaces created under personal OpenShift namespaces. The `kubeadmin` user is not supported, and logging through does not allow access to the CodeReady Workspaces Dashboard.
`updateAdminPassword`	`false`	Forces the default `admin` CodeReady Workspaces user to update password on first login.

6.5.4. `storage` configuration settings related to persistent storage used by CodeReady Workspaces

Property	Default value	Description
`postgresPVCStorageClassName`	omit	Storage class for the Persistent Volume Claim dedicated to the PostgreSQL database. Omitted or leave empty to use a default storage class.
`preCreateSubPaths`	`false`	Instructs the CodeReady Workspaces server to launch a special Pod to pre-create a subpath in the Persistent Volumes. Enable it according to the configuration of your K8S cluster.
`pvcClaimSize`	`1Gi`	Size of the persistent volume claim for workspaces.
`pvcJobsImage`	omit	Overrides the container image used to create sub-paths in the Persistent Volumes. This includes the image tag. Omit it or leave it empty to use the default container image provided by the Operator. See also the `preCreateSubPaths` field.
`pvcStrategy`	`common`	Available options:`common` (all workspaces PVCs in one volume), `per-workspace` (one PVC per workspace for all declared volumes) and `unique` (one PVC per declared volume).
`workspacePVCStorageClassName`	omit	Storage class for the Persistent Volume Claims dedicated to the workspaces. Omit or leave empty to use a default storage class.

6.5.5. `k8s` configuration settings specific to CodeReady Workspaces installations on OpenShift

Property	Default value	Description
`ingressClass`	`nginx`	Ingress class that defines which controller manages ingresses.
`ingressDomain`	omit	Global ingress domain for a K8S cluster. This field must be explicitly specified. This drives the `is kubernetes.io/ingress.class` annotation on CodeReady Workspaces-related ingresses.
`ingressStrategy`	`multi-host`	Strategy for ingress creation. This can be `multi-host` (host is explicitly provided in ingress) and `default-host`(no host is provided, path-based rules).
`securityContextFsGroup,omitempty`	`1724`	FSGroup the CodeReady Workspaces Pod and Workspace Pods containers will run in.
`securityContextRunAsUser`	`1724`	ID of the user the CodeReady Workspaces Pod and Workspace Pods containers will run as.
`tlsSecretName`	omit	Name of a secret that is used to set ingress TLS termination if TLS is enabled. See also the `tlsSupport` field.

6.5.6. `installation` defines the observed state of CodeReady Workspaces installation

Property	Description
`cheClusterRunning`	Status of a CodeReady Workspaces installation. Can be `Available`, `Unavailable`, or `Available, Rolling Update in Progress`.
`cheURL`	Public URL to the CodeReady Workspaces server.
`cheVersion`	Currently installed CodeReady Workspaces version.
`dbProvisioned`	Indicates whether a PostgreSQL instance has been correctly provisioned.
`devfileRegistryURL`	Public URL to the Devfile registry.
`helpLink`	A URL to where to find help related to the current Operator status.
`keycloakProvisioned`	Indicates whether an Identity Provider instance (Keycloak / RH SSO) has been provisioned with realm, client and user.
`keycloakURL`	Public URL to the Identity Provider server (Keycloak / RH SSO).
`message`	A human-readable message with details about why the Pod is in this state.
`openShiftoAuthProvisioned`	Indicates whether an Identity Provider instance (Keycloak / RH SSO) has been configured to integrate with the OpenShift OAuth.
`pluginRegistryURL`	Public URL to the Plugin registry.
`reason`	A brief CamelCase message with details about why the Pod is in this state.

6.5.7. Limits for workspaces

Property	Default value	Description
`che.limits.workspace.env.ram`	`16gb`	The maximum amount of RAM that a user can allocate to a workspace when they create a new workspace. The RAM slider is adjusted to this maximum value.
`che.limits.workspace.idle.timeout`	`1800000`	The length of time that a user is idle with their workspace when the system will suspend the workspace and then stopping it. Idleness is the length of time that the user has not interacted with the workspace, meaning that one of our agents has not received interaction. Leaving a browser window open counts toward idleness.

6.5.8. Limits for the workspaces of an user

Property	Default value	Description
`che.limits.user.workspaces.ram`	`16gb`	he total amount of RAM that a single user is allowed to allocate to running workspaces. A user can allocate this RAM to a single workspace or spread it across multiple workspaces.
`che.limits.user.workspaces.count`	`1800000`	The maximum number of workspaces that a user is allowed to create. The user will be presented with an error message if they try to create additional workspaces. This applies to the total number of both running and stopped workspaces.
`che.limits.user.workspaces.run.count`	`1`	The maximum number of running workspaces that a single user is allowed to have. If the user has reached this threshold and they try to start an additional workspace, they will be prompted with an error message. The user will need to stop a running workspace to activate another.

6.5.9. Limits for for the workspaces of an organization

Property	Default value	Description
`che.limits.organization.workspaces.ram`	`-1`	The total amount of RAM that a single organization (team) is allowed to allocate to running workspaces. An organization owner can allocate this RAM however they see fit across the team’s workspaces.
`che.limits.organization.workspaces.count`	`-1`	The maximum number of workspaces that a organization is allowed to own. The organization will be presented an error message if they try to create additional workspaces. This applies to the total number of both running and stopped workspaces.
`che.limits.organization.workspaces.run.count`	`-1`	The maximum number of running workspaces that a single organization is allowed. If the organization has reached this threshold and they try to start an additional workspace, they will be prompted with an error message. The organization will need to stop a running workspace to activate another.

Chapter 6. Advanced configuration options

6.1. CodeReady Workspaces configMaps and their behavior

6.1.1. CodeReady Workspaces installed using an Operator

6.2. Configuring namespace strategies

6.2.1. One namespace per workspace strategy

6.2.2. One namespace for all workspaces strategy

6.2.3. One namespace per user strategy

6.2.4. Allowing user-defined workspace namespaces

6.3. Deploying CodeReady Workspaces with support for Git repositories with self-signed certificates

6.4. Adding self-signed SSL certificates to CodeReady Workspaces

6.5. CodeReady Workspaces configMaps fields reference

6.5.1. `server` settings related to the CodeReady Workspaces server

6.5.2. `database` configuration settings related to the database used by CodeReady Workspaces

6.5.3. `auth` configuration settings related to authentication used by CodeReady Workspaces installation

6.5.4. `storage` configuration settings related to persistent storage used by CodeReady Workspaces

6.5.5. `k8s` configuration settings specific to CodeReady Workspaces installations on OpenShift

6.5.6. `installation` defines the observed state of CodeReady Workspaces installation

6.5.7. Limits for workspaces

6.5.8. Limits for the workspaces of an user

6.5.9. Limits for for the workspaces of an organization

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

Making open source more inclusive

About Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links

Chapter 6. Advanced configuration options

6.1. CodeReady Workspaces configMaps and their behavior

6.1.1. CodeReady Workspaces installed using an Operator

6.2. Configuring namespace strategies

6.2.1. One namespace per workspace strategy

6.2.2. One namespace for all workspaces strategy

6.2.3. One namespace per user strategy

6.2.4. Allowing user-defined workspace namespaces

6.3. Deploying CodeReady Workspaces with support for Git repositories with self-signed certificates

6.4. Adding self-signed SSL certificates to CodeReady Workspaces

6.5. CodeReady Workspaces configMaps fields reference

6.5.1. server settings related to the CodeReady Workspaces server

6.5.2. database configuration settings related to the database used by CodeReady Workspaces

6.5.3. auth configuration settings related to authentication used by CodeReady Workspaces installation

6.5.4. storage configuration settings related to persistent storage used by CodeReady Workspaces

6.5.5. k8s configuration settings specific to CodeReady Workspaces installations on OpenShift

6.5.6. installation defines the observed state of CodeReady Workspaces installation

6.5.7. Limits for workspaces

6.5.8. Limits for the workspaces of an user

6.5.9. Limits for for the workspaces of an organization

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

Making open source more inclusive

About Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links

6.5.1. `server` settings related to the CodeReady Workspaces server

6.5.2. `database` configuration settings related to the database used by CodeReady Workspaces

6.5.3. `auth` configuration settings related to authentication used by CodeReady Workspaces installation

6.5.4. `storage` configuration settings related to persistent storage used by CodeReady Workspaces

6.5.5. `k8s` configuration settings specific to CodeReady Workspaces installations on OpenShift

6.5.6. `installation` defines the observed state of CodeReady Workspaces installation