Scaling

br\u016bhi Cloud is designed to scale from a single Docker Compose deployment up to thousands of stations on Kubernetes. This page outlines the three scaling tiers and when to use each.

Scaling Tiers

Stations	Recommended approach	Notes
1–10	Docker Compose (single host)	Default; zero additional complexity
10–100	Docker Compose + vertical scaling	Increase CPU/RAM on the host
100–1,000	Docker Swarm	Horizontal scaling with built-in orchestration
1,000+	Kubernetes	Full autoscaling, multi-region failover

Tier 1: Docker Compose (1–100 stations)

The default deployment. All stations run in a single container on one machine.

Scale up by upgrading your server hardware:

Stations	Recommended CPU	RAM
1–5	2 cores	2 GB
5–20	4 cores	4 GB
20–50	8 cores	8 GB
50–100	16 cores	16 GB

Each active Liquidsoap process uses approximately 50–150 MB RAM and 0.1–0.3 CPU cores at 192 kbps output.

Tier 2: Docker Swarm (100–1,000 stations)

Docker Swarm distributes station containers across a cluster of machines. br\u016bhi Cloud’s station engine creates one Swarm service per station.

Setting up a Swarm

# On the manager node
docker swarm init

# On worker nodes
docker swarm join --token <token> <manager-ip>:2377

Deploying to Swarm

docker stack deploy -c docker-compose.prod.yml bruhi

The station manager dynamically creates and removes Swarm services as stations are added or removed via the API.

Recommended hardware per node

Role	CPU	RAM
Manager	4 cores	8 GB
Worker	8 cores	16 GB

With 3 workers at 8 cores / 16 GB each, you can comfortably run 200–300 concurrent stations.

Tier 3: Kubernetes (1,000+ stations)

For very large deployments, Kubernetes provides:

Automatic pod scheduling
Horizontal pod autoscaling based on CPU/memory
Rolling updates without downtime
Multi-region failover

Each station runs as a Kubernetes Deployment with one pod:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: station-{{ station_id }}
  namespace: bruhi
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bruhi-station
      station: "{{ station_id }}"
  template:
    spec:
      containers:
        - name: liquidsoap
          image: savonet/liquidsoap:latest
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"
          volumeMounts:
            - name: station-config
              mountPath: /config/station.liq

Storage at Scale

At scale, local volume storage becomes a bottleneck. Recommendations:

Tier	Storage approach
Docker Compose	Local disk or NFS volume
Swarm	Shared NFS volume or S3 for media
Kubernetes	S3 (AWS, R2, MinIO) for all media

Use S3 Storage to decouple media from the container lifecycle.

Production Checklist for Scale

Configure a load balancer for the API/dashboard (ports 8000 and 8005)
Move media to S3 — do not rely on local disk for production
Set up monitoring: CPU/memory per node, stream health per station (listener count, connection drops)
Enable Icecast stats endpoint for listener tracking
Set up log aggregation (Loki, ELK, Datadog) — container logs are ephemeral
Plan for Liquidsoap process crashes: auto-restart policy (restart: always in Compose, restartPolicy: Always in K8s)