Specific components of workspaces need to be made accessible outside of the Kubernetes or OpenShift cluster. This is typically the user interface of the workspace’s IDE, but it can also be the web UI of the application being developed. This enables developers to interact with the application during the development process.

Che supports three ways to make workspace components available to the users, also referred to as strategies:

  • multi-host strategy

  • single-host strategy

  • default-host strategy

The strategies define whether new subdomains are created for components of the workspace, and what hosts these components are available on.

Multi-host strategy

With this strategy, each workspace component is assigned a new subdomain of the main domain configured for the Che server. On OpenShift, this is the only possible strategy, and manual configuration of the workspace exposure strategy is therefore always ignored.

This strategy is the easiest to understand from the perspective of component deployment because any paths present in the URL to the component are received as they are by the component.

On a Che server secured using the Transport Layer Security (TLS) protocol, creating new subdomains for each component of each workspace requires a wildcard certificate to be available for all such subdomains for the Che deployment to be practical.

Single-host strategy

This strategy is available on Kubernetes, but not on OpenShift. When it is used, all workspaces are deployed to subpaths of the main Che server domain.

This is convenient for TLS-secured Che servers because it is sufficient to have a single certificate for the Che server, which will cover all the workspace component deployments as well.

This strategy limits the exposed components and user applications. Any absolute URL generated on the server side that points back to the server does not work. This is because the server is hidden behind a path-rewriting Ingress that hides the workspace and the component-specific URL prefix from the server.

For example, when the user accesses the hypothetical https://che-host/component-prefix-djh3d/app/index.php URL, the application sees the request coming to https://internal-host/app/index.php. If the application used the host in the URL that it generates in its UI, it would not work because the internal host is different from the externally visible host. However, if the application used an absolute path as the URL (for the example above, this would be /app/index.php), such URL would still not work. This is because on the outside, such URL does not point to the application, because it is missing the component-specific prefix.

Therefore, only applications that use relative URLs in their UI work with the single-host workspace exposure strategy.

Default-host strategy

This strategy exposes the components to the outside world on the subpaths of the default host of the cluster. It is similar to the single-host strategy. All the limitations and advantages of the single-host strategy applying to this strategy as well.