When you deploy Countly with single-host Docker Compose, the smallest single-instance defaults fit on a 16 GB host. To match a larger machine, pick one of the bundled tier presets. This guide explains what a tier is, lists the ones available, and helps you decide which one matches your host.
What a tier is
A tier is a preset of resource caps (RAM, CPU, JVM heap) and replica counts for the busy services (aggregator, ingestor, jobserver, API), sized to a host machine. Each tier is named T<vCPU>-<RAM>, so T32-128 is the preset for a 32 vCPU / 128 GB host. Tier files live in dockerized_deploy/tiers/; you select one with make up TIER=<name>.
Available Tiers
Ten tiers ship with the deployment, ranging from a 4 vCPU / 16 GB host up to 80 vCPU / 320 GB:
| Tier | Host Size | Aggregator | Ingestor | Jobserver | API | Validation |
|---|---|---|---|---|---|---|
T4-16 |
4 vCPU / 16 GB | 1 | 1 | 1 | 1 | Interpolated |
T6-24 |
6 vCPU / 24 GB | 1 | 1 | 1 | 1 | Interpolated |
T8-32 |
8 vCPU / 32 GB | 1 | 1 | 1 | 1 | Interpolated |
T12-48 |
12 vCPU / 48 GB | 1 | 1 | 1 | 1 | Interpolated |
T16-64 |
16 vCPU / 64 GB | 1 | 1 | 1 | 1 | ✔ Validated |
T24-96 |
24 vCPU / 96 GB | 2 | 2 | 1 | 1 | Interpolated |
T32-128 |
32 vCPU / 128 GB | 2 | 2 | 1 | 1 | ✔ Validated |
T48-192 |
48 vCPU / 192 GB | 4 | 4 | 1 | 1 | Interpolated |
T64-256 |
64 vCPU / 256 GB | 5 | 5 | 1 | 2 | ✔ Validated |
T80-320 |
80 vCPU / 320 GB | 7 | 7 | 2 | 2 | Interpolated |
The frontend service stays at one replica across every tier. Multi-host or zone-aware deployments are out of scope for single-host Docker Compose; switch to the Countly Helm chart on Kubernetes when you need more.
Validated vs. interpolated
Three tiers (T16-64, T32-128, T64-256) are validated against benchmark runs. Their resource caps and replica counts come from measured behavior. The remaining seven tiers are interpolated from the validated points and are safe starting positions, but you should smoke-test under representative load before committing to one in production.
Choosing the Right Tier
Three questions narrow the choice down:
What size is the host?
Match the tier to the host the stack is running on. Tiers are sized to fit their named host: T32-128 assumes 32 vCPU and 128 GB of RAM, and overcommits memory if you run it on anything smaller. Confirm host capacity with nproc and free -h before applying a tier.
Does the host fall between two tiers?
If your host size lies between two bundled tiers (for example, 20 vCPU / 80 GB sits between T16-64 and T24-96), pick the smaller tier as a starting point and watch resource usage under load. If you see consistent headroom, define a custom tier sized to the actual host instead of running below capacity.
Is the tier validated, or interpolated?
Validated tiers are the safest production targets. Interpolated tiers are usable but should be load-tested before committing to them. If your host size matches a validated tier exactly, prefer it.
Applying a Tier
From dockerized_deploy/, apply the chosen tier with one command:
make up TIER=T32-128
The tier name is written to .active-tier in the current directory.
Subsequent commands like
make ps, make logs, and make restart read
the active tier automatically;
you only pass TIER= again when switching to a different tier.
What Each Tier Contains
Two files define a tier. Both live in dockerized_deploy/tiers/:
| File | Purpose |
|---|---|
T<vCPU>-<RAM>.env |
Per-service env-var overrides (memory limits, JVM heap, CPU caps) applied to the base docker-compose.yml via --env-file. |
T<vCPU>-<RAM>.compose.yml (optional)
|
Compose override that adds extra replica services for tiers that run more than one replica of a busy service. Present from T24-96 upward; absent for the smaller tiers. |
When the wrapper applies a tier, it includes both files automatically. There is nothing to merge by hand.
Replica Scaling Model
Tiers grow replicas in a fixed pattern as host size increases:
- Aggregator and ingestor scale together at a 1:1 ratio. Their counts always match within a tier.
-
Jobserver is capped at three replicas across all tiers, and stays at one for every tier except
T80-320, which uses two. -
API scales from one to two only at the two largest tiers (
T64-256andT80-320). - Frontend stays at one replica across every tier — a single nginx upstream on one host is enough for it.
- Backing services (MongoDB, ClickHouse, Kafka, Kafka Connect) stay at one container per tier and grow vertically — more memory, more CPU, more JVM heap. Multi-instance clustering of these is a different architecture and not supported in single-host Docker Compose.
Replicas above ten strain single-broker Kafka
Aggregator and ingestor reach seven replicas at T80-320. Pushing them higher with custom tiers is possible, but replica counts much above ten per service start to strain the single-broker Kafka model bundled with the deployment. If you need that much throughput, plan to move to multi-broker Kafka and the Helm chart on Kubernetes.
Common Questions
make up with no TIER) and only move to a tier once the host is large enough.T80-320?
T80-320, switch to multi-broker Kafka and the Countly Helm chart on Kubernetes. The Docker Compose deployment is a single-host artifact by design.tiers/<name>.env directly — it lists every per-service env-var override the tier applies. For tiers with extra replicas, also read tiers/<name>.compose.yml. The full per-service memory and CPU values per tier are documented in tiers/README.md..env; they override the tier's defaults. For repeatable host sizes that aren't yet covered by a bundled tier, the cleaner path is to define a custom tier file. See the related guide on adding a custom tier. T16-64, T32-128, T64-256) come from internal benchmark runs. Contact Countly Support for the throughput and latency numbers behind each one if you need them for capacity planning.