Server Requirements¶

What a Huddo release needs from your Kubernetes cluster, and where to start with resource requests and limits. These figures apply to the huddo chart. The Component Pack chart runs the same services but reuses the MongoDB and cache that Component Pack already provides.

Starting points, not guarantees

The figures below come from the chart defaults and from running Huddo Boards in production. Huddo's own services have not yet been benchmarked under load, so treat them as a first setting: watch actual usage with kubectl top pods for the first few weeks and adjust.

Size your cluster¶

Choose the products you are installing, start from the size closest to your organisation, then adjust the numbers. Everything below the inputs updates as you type.

The calculator assumes:

Search is always on. Spaces comes with Huddo Wikis.
At the busiest hour, 10% of licensed users are online and 15% of those are editing a page.
Two replicas of every stateless service, so a node can be drained without an outage. Three nodes let the scheduler keep the two replicas apart.
Memory limits about twice the request, with a quarter more node memory than the limits add up to.

CPU requests are low because most services are idle between requests. Set CPU requests but no CPU limits, so that a burst (a page render, an image resize) is not throttled.

Sizes at a glance¶

For Huddo Wikis on its own. Licensed users, content and storage are the calculator's starting sizes; the rest is what it works out for them.

	Starter	Small	Medium	Large
Licensed users	up to 200	up to 500	up to 2,000	up to 10,000
Wikis	about 20	about 50	about 150	about 600
Pages	about 3,000	about 10,000	about 40,000	about 150,000
Attachments	about 5 GB	about 20 GB	about 60 GB	about 250 GB
S3 storage to provide	200 GB	250 GB	500 GB	1 TB
Worker nodes	3 × 2 vCPU, 8 GB	3 × 2 vCPU, 8 GB	3 × 4 vCPU, 8 GB	3 × 4 vCPU, 16 GB
Pods	32	32	32	36
CPU requests	2.1 vCPU	2.3 vCPU	2.5 vCPU	3.0 vCPU
Memory requests / limits	4.8 GB / 12 GB	5.9 GB / 14 GB	8.2 GB / 16 GB	13 GB / 22 GB
OpenSearch heap / memory	`512m` / 1 Gi	`1g` / 2 Gi	`2g` / 4 Gi	`4g` / 8 Gi
OpenSearch volume	20 Gi	20 Gi	20 Gi	30 Gi
MongoDB data	about 0.3 GB	about 1 GB	about 4 GB	about 14 GB

Adding products to Wikis, at any size:

Also installing	Adds
Huddo Ideas	2 pods, about 0.2 vCPU, 0.3 GB of memory requests (0.8 GB limits)
Huddo Boards	10 pods, about 0.5 vCPU, 1 GB of memory requests (3.8 GB limits), and a second S3 bucket

Trying Huddo out

Turning off high availability runs one replica of each service. Starter then fits on a single node with 4 vCPU and 16 GB (19 pods, 3.4 GB of memory requests). There is no room to drain that node without an outage, so use it for a trial rather than production.

What drives each figure¶

As this grows…	…this needs more
Users online at once	`wikis` replicas (about one per 250 users online), `attachments` replicas, and socketcluster workers: every open browser tab holds a live connection, so add a worker per 500 tabs
Pages open for editing	`editor` memory: each open page is held in memory while it is being edited
Pages and attachments	OpenSearch memory and volume, and MongoDB storage. Text from PDF and Office files, and text found in images, is searchable, so attachments add to the index as well as pages
Number of wikis	OpenSearch heap: every search filters by the wikis the user can read. Above about 1,000 wikis, move up one heap size
Attachments	Object storage: the files themselves, plus about 15% for the resized copies of images
Licensed users	`user` replicas, which handle sign-in (about one per 5,000 users)

Applying the values¶

Every service accepts resources and replicaCount in your values file, and OpenSearch also takes heapSize and persistence.size. The socketcluster broker and state, and draw.io, run with the chart's own settings; only the socketcluster worker's replicaCount can be changed. For example:

wikis:
  replicaCount: 2
  resources:
    requests:
      cpu: 80m
      memory: 128M
    limits:
      memory: 384M

opensearch:
  heapSize: 1g
  resources:
    requests:
      cpu: 400m
      memory: 2Gi
    limits:
      memory: 2Gi
  persistence:
    size: 20Gi

socketcluster:
  worker:
    replicaCount: 2

Our team can produce a complete values file for your size; ask support@huddo.com.

Give attachments-indexer a memory limit

It reads PDF and Office files and scans images for text, two files at a time, each in a process of up to 512 MB. On some kernels the image scanner cannot be capped from inside the container, so the pod limit is the only guard against an unusual file.

Search¶

Search runs on a single-node OpenSearch deployed by the chart, with one persistent volume.

Search index size	`heapSize`	Memory request and limit
up to 400 MB	`512m`	1 Gi
up to 1.5 GB	`1g`	2 Gi (chart default)
up to 4 GB	`2g`	4 Gi
larger	`4g`	8 Gi

Estimate the index at about 12 KB per page plus about 2% of the attachments' size.
Keep the memory limit at twice the heap. The other half caches the index files, which keeps searches fast.
Size the volume at three times the index. Rebuilding the index writes a new copy beside the old one.
Every node that can run OpenSearch needs vm.max_map_count of at least 262144. The chart sets it with a privileged init container; where privileged containers are not allowed, set it on the node instead.
OpenSearch is the largest pod, so it is the one that fails to schedule on a tight cluster. To keep it off your application nodes, pin it to a node pool of its own. See Giving OpenSearch room.
To use an OpenSearch cluster you already run, set opensearch.enabled: false and point the search service at it. See Configuration.

Importing content¶

Plan extra headroom for the weeks you import existing content.

Raise the wikis and attachments memory limits to 1G while imports run.
Raise the attachments-indexer limit to 2G, and OpenSearch one step in the table above.
Expect search results to fill in after the import finishes. Pages are indexed at about 40 a second; text in attachments takes longer, about 2 to 3 hours for 60 GB of files.
Put the limits back once the import is done.

External services¶

Service	Requirement
MongoDB	5.0 or later, running as a replica set (MongoDB Atlas always is). Huddo uses transactions and change streams, which a standalone server does not support. On first start each service builds its indexes, which can take several minutes on a large imported database
S3 storage	Any S3-compatible endpoint. Allow for the attachments plus about 15%
Valkey/Redis	Deployed by the chart. Holds caches and work queues only, so nothing needs backing up

Images¶

Most images come from Huddo's repository on Quay.io, which needs access to our images. A few come from Docker Hub. For an air-gapped cluster, or to avoid Docker Hub's pull limits, mirror these into your own registry.

Registry	Images
`quay.io/huddo`	`core`, `wikis`, `spaces`, `ideas`, `editor`, `attachments`, `discussions`, `notifications`, `search`, `acl`, `user`, `provider`, `licence`, `socketcluster`
Docker Hub	`opensearchproject/opensearch`, `valkey/valkey`, `socketcluster/scc-broker`, `socketcluster/scc-state`, `busybox`
Docker Hub (only with diagrams enabled)	`jgraph/drawio`