Last modified October 21, 2026

Prepare your environment for the standalone Observability Platform

The standalone Observability Platform runs Mimir, Loki, Tempo, and Grafana in a Kubernetes cluster you own. It stores all data in object storage you own.

This page lists what the cluster and the object storage need before the install. Each requirement links to a setup guide in the observability-platform repository.

Responsibility boundary

The diagram shows what you provide in blue, the Giant Swarm Observability Platform in orange, and the network paths between them.

Requirements

Kubernetes cluster

• Kubernetes cluster: a conformant cluster that can host the Observability Platform. Any managed or self-managed distribution works. Giant Swarm has verified the platform on Kubernetes 1.36 and Amazon EKS 1.36.
• Release namespace monitoring. The platform installs into the monitoring namespace only.

Access and tools

• cluster-admin on the Kubernetes cluster. The install creates custom resource definitions and cluster-wide RBAC.
• kubectl and helm, pointed at the right cluster.

Cluster capacity

Pick the profile that matches your data volume. The chart’s default values match the minimum profile. Larger profiles need more Mimir ingesters and higher autoscaling limits in your values.

At rest, the platform requests 5.2 vCPU and 36.9 GiB of memory. The remaining capacity absorbs ingest and query load.

Cluster add-ons

• Default StorageClass backed by a working CSI driver. Mimir, Loki, and Tempo store data on persistent volumes. Use volumeBindingMode: WaitForFirstConsumer on a multi-zone cluster. A volume then lands in the zone of the pod that uses it. See EKS_CLUSTER.md and Provider guidance.
• Metrics server. The platform scales Mimir and Loki components with HorizontalPodAutoscalers. These need the metrics.k8s.io API. If it’s missing, install metrics-server. See EKS_CLUSTER.md.
• DNS service. Mimir discovers its components through the cluster DNS service. The chart expects a Service named kube-dns in kube-system. On a cluster where the Service has another name, set mimir.global.dnsService to that name.

Check that a default StorageClass exists. One class must show (default) next to its name:

kubectl get storageclass

Check that the metrics API serves. The command prints CPU and memory per node:

kubectl top nodes

Check that each HorizontalPodAutoscaler reads its metrics after the install. No target must show <unknown>:

kubectl get hpa -n monitoring

Network access

Allow egress to these hosts from the cluster nodes. See the observability-platform README.

• gsoci.azurecr.io, for container images.
• docker.io, for container images.
• giantswarm.github.io/giantswarm-catalog, for Helm charts.
• giantswarm.github.io/control-plane-catalog, for Helm charts.
• Object storage endpoint, over HTTPS on port 443. Mimir, Loki, and Tempo reach it.
• OIDC issuer JWKS URI, over HTTPS, with the External API enabled. The Envoy Gateway pods fetch it.

A registry cache or proxy in front of these hosts works too. For examples on Giant Swarm clusters, see the Zot registry cache and the cluster proxy settings.

Object storage

The platform supports Amazon S3 and Azure Blob Storage. See OBJECT_STORAGE.md.

• Buckets: five private buckets. On Azure Blob Storage, a bucket is a container in a storage account.
  • mimir-blocks, for metrics.
  • mimir-alertmanager, for Alertmanager state.
  • mimir-ruler, for recording and alerting rules.
  • loki, for logs.
  • tempo, for traces.
• Bucket names: you can pick other names. Set them under global.objectStorage.buckets at install time.
• Public access: disabled.
• Transport: HTTPS only.
• Minimum TLS version: 1.2.
• Redundancy: zone-redundant, if your data needs to survive a zone outage.
• Credentials with read and write access to the five buckets.

Release namespace, Secret, and Helm values

The platform reads object storage settings from two places:

• Secret: holds the credentials.
• Helm values under global.objectStorage: hold the account and bucket names.

Inside the monitoring namespace, in which the platform lives:

• Secret name: observability-platform-object-storage. Keep the name and the key names exactly as written.
• Secret key on Azure Blob Storage: AZURE_STORAGE_KEY, holding the storage account key.

Example for Azure Blob Storage:

kubectl create secret generic observability-platform-object-storage \
  --namespace monitoring \
  --from-literal=AZURE_STORAGE_KEY=<storage-account-key>

Warning: Static credentials are long-lived. Rotate them in your object storage service, then update the Secret and restart the Mimir, Loki, and Tempo pods.

Set the account and bucket names in your values file. Example for Azure Blob Storage:

global:
  objectStorage:
    azure:
      accountName: <storage-account>
    buckets:
      mimirBlocks: mimir-blocks
      mimirAlertmanager: mimir-alertmanager
      mimirRuler: mimir-ruler
      loki: loki
      tempo: tempo

The bucket names above are the defaults. With these names, only accountName is required.

Grafana access

External access to Grafana is disabled by default. Giant Swarm recommends exposing Grafana to your users through an ingress. See GATEWAY.md.

An ingress for Grafana needs:

• Ingress controller or Gateway API implementation.
• DNS name for Grafana.
• TLS certificate for that name.

External API (optional)

The Observability Platform API accepts metrics, logs, and traces from outside the cluster. It’s disabled by default. Without it, the platform observes only the cluster it runs in. Enable it when agents, collectors, or users outside the cluster send or query data. See EXTERNAL_API.md.

• Envoy Gateway installed in the cluster. See GATEWAY.md.
• Gateway with an HTTPS listener that accepts routes from the monitoring namespace. Set parentRefs on every API component (loki, mimir, tempo, and basicAuth) to that Gateway and listener. See GATEWAY.md.
• Base domain. The API answers at observability.<domain>.
• DNS record for observability.<domain>, pointing at the Gateway. See GATEWAY.md.
• OIDC issuer, at least one. Every request carries a JWT from that issuer.
• Tenant header. Every request carries an X-Scope-OrgID header with the tenant name.

Provider guidance

kubectl apply -f - <<'EOF'
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  encrypted: "true"
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
EOF

az aks nodepool add \
  --resource-group <resource-group> \
  --cluster-name <cluster> \
  --name observability \
  --node-count 3 \
  --node-vm-size Standard_D4s_v5 \
  --zones 1 2 3

Next steps

Install the platform with the observability-platform chart.

If you need help with the setup, contact your Giant Swarm account engineer. For sharing any secret with us, read Sharing secrets with our team first.