Sizing
Weik.io 2026.2The measured image size and memory of every part of Weik.io, and what a hub and its sites need to run them.
On this page
The image sizes, the integrations’ memory and the hub’s totals on this page were measured on the built images and the tested installations, and the memory ranges of the message server, the backend and the gateway are the ranges they’re designed to run in. Use them to size a hub and its sites, then check the real use on the Health page, which shows each part’s CPU, memory and disk.
What runs where#
| Part | Where | Image | Memory |
|---|---|---|---|
| Message server | the hub, on each server | about 26 MB | 40 to 150 MB |
| Backend, with the admin UI, the API and the builder | the hub, on each server | about 450 MB, because it carries a Java runtime and one Camel launcher per supported Camel version | 130 to 300 MB, more while it builds a version |
| API gateway | the hub, on each server, and a site that runs a gateway | about 140 MB, and about 400 MB more for keeping a site gateway’s telemetry | 90 to 200 MB, and 200 to 230 MB more at a site for its telemetry |
| Log, metric and trace stores | the hub, on node 1 of several servers | one binary each | about 20, 70 and 15 MB idle, up to about 150, 280 and 110 MB after an hour of eight busy integrations |
| Agent | each site | about 430 MB, and about 400 MB more for keeping the site’s telemetry | about 110 MB, and 200 to 230 MB for the site’s telemetry |
| Leaf message server | each site | 26 MB | 26 MB |
| One Camel integration | each site, one JVM per running deployment | built at the hub | 136 MB with traces and metrics on, 131 MB with them off |
Eight integrations on one agent take 820 to 880 MB together, less than eight times one, because they share the classes of the platform’s jars. Every JVM starts from a shared snapshot of those classes, so an integration is ready in about 0.38 seconds instead of 0.63.
A hub on one server#
The hub as tested has 4 virtual CPUs and 8 GB of memory on Ubuntu 24.04 LTS, x86-64. The hub’s services with the three stores take about 500 MB idle, and the builder runs a JVM for the length of each weikio apply. A hub needs at least 2 GB of memory, and init warns on a host with less. A developer stack with the hub and a site on one machine stays under 2 GB up to five integrations.
The disk needs the storage budget and a quarter of it more, about 2 GB for the images, and up to about 75 GB for the log, metric and trace stores with their default caps. The tested disk of 160 GB has room for all of them with --disk-budget 40GiB and about 29 GB to spare.
A hub on several servers#
| Role | Each server |
|---|---|
| Data server, nodes 1 to 3 or 1 to 5 | 4 virtual CPUs, 8 GB of memory, and a disk for its copy of the storage: a disk of 100 GB under the message store fits --, which has room for the installation’s own stores, three environments and 26 projects of the default size |
| Standard server | 4 virtual CPUs, 8 GB of memory and about 10 GB of disk |
| Node 1, in addition | disk for the log, metric and trace stores, up to about 75 GB with their default caps |
Events a second#
The message server writes every change to disk and waits until the disk has it before it confirms the change. The time of one such write sets how many changes a hub accepts a second, events stored among them. On three servers of 4 virtual CPUs and 8 GB of memory that each keep a copy of the storage:
| Disk under the storage | One write that waits for the disk | Events the hub stored |
|---|---|---|
| The server’s own solid-state disk | about 1 ms | about 600 a second |
| A network-attached disk, encrypted or not | 5 to 9 ms | 70 to 100 a second |
Measure the disk once it’s mounted. The command prints the time of 1,000 writes, so divide it by 1,000:
$ dd if=/dev/zero of=/data/disk-speed bs=4k count=1000 oflag=dsyncPut the hub’s storage on the fastest disk your encryption rules allow. A dedicated server with a second local disk gives the rate of a server’s own disk.
A site#
A site’s host needs about 110 MB for the agent, 131 to 136 MiB for each integration it runs, and room for each integration’s Java heap, which may grow to 256 MB unless its deployment gives it another size. Keep 200 to 230 MiB more for the telemetry the site keeps while the hub is out of reach, and up to 4 GiB of disk for it. The images take about 0.9 GB of disk, and a gateway’s about 0.55 GB more.
The site’s free disk and memory are on the Health page, and the problem list raises a row when an agent’s server has more than 90 % of its memory in use or less than a fifth of its disk free.
Telemetry#
A log line takes about 50 to 90 bytes of the log store’s disk, so 30 days at 100 lines a second take about 15 to 25 GB. A call through the gateway into an integration takes about 600 bytes of the trace store’s disk, so the default 20 GiB keeps 7 days up to about 59 such calls a second. The metric store’s 90 days take about 5 GB for 50 integrations and 20 GB for 250. Storage and its budget shows how to change the caps and the days.