Ask or search…

Self hosting

Details on providing a self-hosted (on-premise) control plane


Calyptia provides a hosted control plane for Calyptia Core workloads through calyptia.com, and this is the recommended way to consume Calyptia Core. In this mode, only workloads need hosting locally to run.
For some customers and users it may be required to host their own versions of the control plane either completely offline or in a restricted network. This documentation will explain how to do so.


A Helm chart is provided to deploy the control plane on a Kubernetes cluster.
helm repo add calyptia https://helm.calyptia.com --force-update
helm repo update
helm upgrade --install --create-namespace --namespace "calyptia" --wait calyptia-cloud calyptia/calyptia-standalone
The default installation provides an out-of-the-box working control plane cluster but is not recommended for production as it does not provide a high-availability version of the Postgres database for all state and authentication information.
Refer to the configuration section for specific details to configure the control plane for your specific usage (for example, resource tuning and service configuration).
The helm chart documentation also provides details on configuration: https://github.com/calyptia/charts/tree/master/charts/calyptia-cloud-standalone
Helm provides a standard mechanism to configure through YAML, and supports YAML manifest generation or integration with other GitOps tools (such as ArgoCD or Flux).

Offline installation

For some customers, it is not possible to access any public networks for installation. For these customers, Calyptia can provide a packaged version of the Helm chart along with all supporting tooling and documentation to run on an isolated network.


After the control plane has been deployed, you can use the following helm chart to deploy a Calyptia Core Instance (data plane or workloads) and attach it to our self-hosted control plane.
The key thing to ensure is that the api_url is set to the in-cluster endpoint so it does not use the default hosted cloud-api.calyptia.com endpoint.
helm repo add calyptia https://helm.calyptia.com --force-update
helm repo update
helm upgrade --install --namespace calyptia --create-namespace calyptia-core calyptia/core \
--set project_token="$(kubectl get secret -n "calyptia" auth-secret -o jsonpath='{.data.ONPREM_CLOUD_API_PROJECT_TOKEN}'| base64 --decode)" \
--set name=test --set core_instance_tags=test --set api_url="http://cloud-api.calyptia:5000" \
--debug --wait
Similarly, using the calyptia CLI there are equivalent command line options to set the --cloud-url and the --core-cloud-url. The reason for two separate ones is whether the URL is external to the cluster or internal (for example, if you deploy workloads in a separate cluster, it can use the external --cloud-url parameter).

Production deployments

For production deployments, Calyptia recommends and supports the following:
The configuration for pipelines and everything else is held within the Postgres deployment. The default chart configuration deploys an in-cluster database purely to help with initial or development deployments.
Similarly, Core Operator is deployed by default as part of an initial deployment but in a production system it is better to separate the control plane (self-hosted) from the data plane (Core Operator). This will allow you to manage upgrades and the overall lifecycle of each plane separately as required.


The main thing to ensure is that the Postgres database being used maintains its state
  • the control plane retrieves all state and authentication information from this database. As long as this is maintained during an upgrade then no workload changes or recreation should be required. Refer to Configuration for details on this.
To upgrade, it should be as simple as running a helm upgrade ... command with the new version of the chart as long as it is an adjacent version upgrade.
If all configuration is stored in a separately managed Postgres database then the old chart can be removed and the new chart installed from scratch.
helm uninstall --namespace "calyptia" calyptia-cloud
You can also remove the namespace entirely.
kubectl delete ns calyptia
Now we can install the new version of the chart as if it was in a fresh cluster. It will then pull all its configuration from the Postgres database.
helm install --create-namespace --namespace "calyptia" --wait calyptia-cloud calyptia/calyptia-standalone

Operator upgrade

For full details, refer to Core Operator upgrade documentation.
The Core Operator could be fixed at a specific version as well to prevent any future upgrades, however Calyptia only supports the versions defined as the default for a particular chart version.
Core Operator usage with the self-hosted helm chart is not recommended for production deployments. The approach provided above is best effort to upgrade between adjacent chart versions for non-production deployments.

Old Core Operator versions

Older versions of Core Operator (pre-2.x self-hosted chart) included the CRD in the Core Operator chart. Therefore the upgrade process is two steps:
  1. 1.
    Apply the new Core Operator version of the CRD.
  2. 2.
    Upgrade the Helm chart
The Core Operator version CRD is available as an artefact on the release for that version under https://github.com/calyptia/core-operator-releases/releases. The Core Operator version is controlled by a value in the Helm chart so check the default for the chart version being used: https://github.com/calyptia/chart-cloud-standalone/blob/main/chart/values.yaml
For version 2.0.12 of Core Operator, the command would be:
kubectl apply -f \
Replace the v2.0.12 version string with the appropriate new version to upgrade the Core Operator to. See Versions for a list of supported charts and operator combinations.

Supported upgrade versions

Calyptia guarantees support only for adjacent version upgrades for the Helm chart. This means assuming we have release versions 1.0.8, 1.0.9, 2.0.0, 2.0.1 the only supported upgrades are:
  • 1.0.8 -> 1.0.9
  • 1.0.9 -> 2.0.0
  • 2.0.0 -> 2.0.1
To go from 1.0.8 to 2.0.1, the only supported route is by using the intermediate versions.
The default versions provided by a particular chart version are the ones officially supported as working together.
Refer to the release notes as well for the Core versions being deployed for any specific upgrade or feature changes that may impact you. This will provide any details for specific migrations to do around major version upgrades too.