Choose a Countly Helm Sizing Profile

Updated

This guide explains the profile dimensions you choose when deploying Countly with Helm, and helps you pick the right combination for a local laptop, a small staging cluster, or a full production environment. Profiles are layered on top of chart defaults to control resource sizing, ingress TLS, observability footprint, Kafka Connect tuning, and network policy strictness, all from a single global.yaml file in your environment directory.

How the Configuration Layers

The Helm deployment composes values in a fixed order:

chart defaults  ─▶  profiles (sizing + dimensions)  ─▶  environment choices  ─▶  secrets

Profiles live under profiles/ in the repository. Each dimension is a directory with one file per option. You select one option per dimension in your environment's global.yaml, and the helmfile orchestration applies the matching profile values to every chart that consumes them.

The Five Profile Dimensions

Five dimensions cover the most common deployment trade-offs. Pick exactly one option per dimension.

DimensionOptionsWhat it controls
sizinglocal, small, productionCPU and memory requests, replica counts, Horizontal Pod Autoscaler bounds, Pod Disruption Budgets
observabilitydisabled, full, external-grafana, externalWhether the in-cluster Prometheus, Grafana, Loki, Tempo, and Pyroscope stack runs, and where data is sent
kafkaConnectthroughput, balanced, low-latencyBatch sizes, write frequency, and Kafka Connect worker memory for the ClickHouse sink
tlsnone, letsencrypt, provided, selfSignedIngress TLS configuration: no TLS, automatic Let's Encrypt issuance, your own pre-existing secret, or a generated self-signed certificate
securityopen, hardenedNetwork policy enforcement level between namespaces

Picking a Sizing Profile

Sizing is the dimension that most directly drives cluster cost and capacity. Use the table below as a starting point.

ProfileUse caseNotes
localLaptop or single-node development clusterLowest resource requests; minimal replica counts; suitable for evaluating features and running smoke tests
smallStaging or light-traffic productionModerate replica counts and resource requests; appropriate for non-HA workloads or low-volume tenants
productionFull production deploymentHighest replica counts, HPAs, and Pod Disruption Budgets; designed for sustained traffic and high availability

Sizing affects every chart

Choosing production raises resources and replica counts across the Countly application, Kafka, ClickHouse, MongoDB, and the observability stack. Confirm your cluster has node capacity and storage class capacity before applying.

Picking an Observability Profile

ProfileBehavior
disabledNo in-cluster observability backends are deployed. Use when you have an external monitoring solution.
fullDeploys the complete in-cluster stack: Prometheus, Grafana, Loki, Tempo, Pyroscope, and Alloy collectors.
external-grafanaDeploys collectors and backends in-cluster, but expects Grafana to live elsewhere.
externalDeploys only the collectors. Sends metrics, logs, traces, and profiles to external backends.

Picking a Kafka Connect Profile

The Kafka Connect ClickHouse sink trades latency for throughput depending on batch and flush settings. Choose the option that matches your data delivery expectations:

ProfileWhen to choose
throughputMaximize rows-per-second to ClickHouse. Tolerates higher end-to-end delay.
balancedDefault. Reasonable trade-off between latency and throughput for most workloads.
low-latencySurface events in ClickHouse as soon as possible. Trades throughput for freshness.

Picking a TLS Profile

ProfileWhat it does
nonePlain HTTP at the ingress. Use only behind another TLS-terminating proxy.
letsencryptcert-manager issues a certificate via the Let's Encrypt ACME flow. Requires a public DNS record.
providedUse a pre-existing kubernetes.io/tls secret you create or materialize from Secret Manager.
selfSignedcert-manager generates a self-signed certificate. Suitable for local evaluation only.

Picking a Security Profile

ProfileBehavior
openPermissive network policies between Countly namespaces. Easier to debug.
hardenedStrict network policy enforcement; only required cross-namespace traffic is allowed.

Recommended Combinations

The combinations below cover the most common deployment scenarios:

ScenariosizingobservabilitykafkaConnecttlssecurity
Laptop evaluationlocaldisabled or fullbalancedselfSignedopen
Small stagingsmallfullbalancedletsencryptopen
Productionproductionfull or externalbalanced or throughputprovided or letsencrypthardened

Setting Profiles in global.yaml

All profile selections live under global: in your environment's global.yaml. A typical production block looks like this:

global:
  sizing: production
  observability: full
  kafkaConnect: balanced
  tls: provided
  security: hardened
  ingress:
    hostname: countly.example.com

Once your global.yaml is set, deploy with helmfile from the repository root:

helmfile -e my-deployment apply

Profiles are composable

You can change one dimension at a time. For example, switch kafkaConnect from balanced to throughput and re-run helmfile apply; only the Kafka Connect resources are affected.

Changing Profiles Later

Profile changes are applied with the same helmfile apply command. Plan ahead for the following caveats:

  • Increasing sizing raises resource requests and may require additional cluster nodes before pods reschedule successfully.
  • Switching tls from selfSigned to letsencrypt requires DNS for the ingress hostname to resolve publicly so cert-manager can complete the ACME challenge.
  • Switching security from open to hardened may break ad-hoc kubectl port-forward or debugging flows that relied on permissive cross-namespace traffic.

Related to

Was this page helpful?
Reach out to us for any other questions.
Discord Community Contact Support
Helpful?

Looking For More Help?