Skip to main content

Platform - Settings


The Cluster section provides information about the cluster running Otomi. Only 2 settings can be changed:

API ServerAdd the full url of the kubernetes API server. This is used to generate the KUBECONFIG for local API access.
OwnerA cluster owner. Used in alerts/reports to distinguish between resources for different customers.



Alerts settings will only be active when Alertmanager is active.

The alerts settings section offers configuration options to define alerting endpoints for alert manager and deployment feedback. The list of providers selected in Notification receivers should reflect their configuration. I.e. when receiver "slack" is selected, the slack configuration needs to be defined. Teams can also configure additional endpoints for the alerts spawning from their team namespace.

Repeat intervalIndicates waiting time before sending a notification again after it was sent successfully for an alert. (Usually ~3h or more).
Group intervalHow long to wait before sending a notification about new alerts that are added to a group of alerts for which an initial notification has already been sent. (Usually ~5m or more.)
SlackSlack webhook url and channels for critical and non-critical alerts.
MSteamsMicrosoft Teams webhook urls for critical (high prio) and non-critical alerts (low prio).
EmailEmail address(es) for critical and non-critical alerts.
Notification receiversSelect default notification channel(s) for receiving alerts.
Drone notificationsChannel to be used by the deployment pipeline for failure/success notifications. Can only be delivered to Slack or MSteams (for now).

Home alerts


Home alerts settings will only be active when Alertmanager is active.

The Home alerts section is similar to the Alerts section, but with a different intent: the configuration here is meant to target "Home" alerting endpoints. Those will become active when otomi.isHomeMonitored is turned on. This allows for a 3rd party to also monitor the system. This comes in handy when setting up Otomi as a managed service for clients that want to receive notifications themselves. We consider "Home" to be the managing party, and the regular "Alerts" section should then only contain endpoints for the client. Of course teams can still configure their own endpoints for the alerts spawning from their team namespace.



Azure settings will only be active when cluster.provider=azure.

The Azure settings section offers specific configuration options when running Otomi on a Kubernetes cluster in Azure. Note that this section will only be available when running on Azure (cloud=azure).

AppgwSelect if Azure Application Gateway is used as an external Load Balancer.
Azure MonitorTurn on Azure monitor to use Azure metrics in Grafana dashboards.
Storage TypesSpecify the Azure disk types used for storage classes in Otomi.


Using an Azure Application Gateway is optional. In case an application gateway is used with a WAF, make sure that its on detection mode and not prevention, as this might deny traffic to your cluster, which can have consequences on the availability of services. For example Grafana relies heavily on queries inside the api request that might trigger OWASP rules.



DNS settings will only be active when otomi.hasExternalDNS=true.

The DNS settings section offers configuration options for DNS.

ZonesDefines the dns zones accessible by the credentials given in the "Provider" section underneath.
ProviderThe provider hosting the dns zones. Can be AWS, Azure or Google.


By default (after installing Otomi), one ingress controller (ingress-nginx-platform) is deployed and is used to publicly expose both platform and user created services. In the settings for ingress, an admin can:

  1. Configure the platform ingress class to be private (using a private load balancer)
  2. Add additional ingress classes to expose user created services

By changing the platform ingress class from public to private, all platform services (like Otomi Console, the Keycloak platform instance and all other platform end-points) will only be accessible from the private network.

By adding additional ingress classes, each class will get a dedicated ingress controller and a dedicated cloud load balancer. This allows grouping of services and exposing them to differend networks.


The KMS settings section offers configuration options for the Key Management Service information needed to seal and unseal secrets used by Otomi. Otomi needs at least one key. It needs one for encrypting/decrypting the otomi-values repo), and one for sealing/unsealing Vault storage.


  • When omitting KMS credentials for SOPS, the secrets in the otomi-values repo will be stored in plain text
  • When omitting KMS credentials for Vault, on startup it will generate its own k8s secret for sealing/unsealing, so be careful not to remove it!

It is advised to provide credentials to an external stable KMS (such as from the cloud the cluster was deployed in), so that unseal keys can always be managed from one central location. The same credentials can be used for both SOPS and Vault, but that is up to you to decide.

Settings for Vault can be found under apps.vault in the Otomi values repository, but will be added to this section soon.



OIDC settings will only be active when otomi.hasExternalIDP=true

The OIDC settings section offers configuration options to connect with an external Identity Provider (Bring Your Own IDP). This allows to map IDP group names to the following Otomi roles:

  • Otomi admins (adminGroupID)
  • Team admins (teamAdminGroupID)

Some settings are left in case Keycloak is not needed (it is heavy, and small teams might not need authorization), and are used by Grafana only:

  • Auth url
  • Api url
  • Token url


The Otomi settings section offers configuration options for Otomi and feature flags that influence the way Otomi behaves.

Admin passwordDefault admin password for all Otomi apps. The default admin password can not be changed.
Additional ClustersA list of additional clusters to select in the Otomi console.
Global pull secretsAdd you Dockerhub pull secret. Will be connected to each "default" service account in all otomi app namespaces. Handy for authenticating with DockerHub to avoid rate limiting. Also useful when pulling all otomi images from a private repo.
External load balancerSet this to true when an external load balancer exists (Azure AppGW, Google Apigee) or needs to be started (AWS ALB). This will then be configured through ingress controllers. Expects existing LBs to terminate https. Currently this is only working correctly for Azure, and not for AWS and Google. AWS is close to completion.
External DNSSet this to true when an external DNS zone is available to manage DNS records. (Expects required dns: fields to be set.)
External IdPSet this to true when bringing your own external IDP such as Azure AD. (Expects required oidc: fields to be set.)
Home monitoredWhen this is turned on alerts will also be sent to the endpoints configured in the "Home" settings.
Managed mastersWhether masters are managed and not under control. Set this to false when onprem.
Multi-tenancyWhen turned on, team metrics and logs will be separated. Disabling this let everybody be admin and see everything. Will still use team-* namespaces for segmentation and network isolation of services.
VersionThe installed version of Otomi. Change to a new valid release to upgrade



SMTP settings will only be active when Alertmanager is active.

The alerts settings section offers configuration options to define for Mail server settings. A mail server needs to be configured in case email notifications are used.