How Weik.io is put together
A Weik.io installation has a hub and any number of agents. The hub stores the versions, configuration and telemetry of your integrations and serves the admin UI, the API and the gateway, on one server or on as many as you need for high availability. An agent runs your integrations on a Linux host with Docker or on Windows Server, and it connects to the hub with two outbound connections on port 443.
This part of the video couldn't be loaded.
The hub and the agents
The hub runs a message server, the backend, the gateway and the log, metric and trace stores on one server, or on as many as you need for high availability, and it publishes port 443. Agents in three places connect to it: at a factory inside a customer network, in the customer's Azure account and as cloud agents in Weik.io Cloud. Each agent has a leaf node beside it and starts one Java process per running integration, and it opens two outbound connections to the hub on port 443, wss for the leaf node and https for telemetry. No agent accepts an inbound connection.
What the drawing shows:
- The hub on one server or on as many as you need: a message server, a backend and a gateway on each server, and the log, metric and trace stores.
- An agent inside a factory network, an agent in your Azure account and cloud agents in Weik.io Cloud.
- On each agent's host a leaf node, a small NATS server that links the host to the hub, the agent and one Java process for each running integration.
- Two connections from each agent to the hub, both outbound on port 443: the leaf node's link and the telemetry.
The programs and the store
Weik.io is three programs. The backend is one process that serves the HTTP API, builds each integration version, chooses the agents that run each deployment and runs the entity store service and the token issuer. The agent starts one Java process for each running integration on its host. The third program is the API gateway, with a gateway on every hub server and, where you want one, beside an agent.
NATS JetStream is the only store of the three programs. Versions and their files, configuration, events, the entity store and the audit log all live in it, and the hub's log, metric and trace stores keep the telemetry. The admin UI is static files inside the backend image, served on the same hostname as the API.
Network
| Flow | Port and protocol | What it carries |
|---|---|---|
| From an agent to the hub | 443, WebSocket (wss), to one hostname | The leaf node's link: control traffic, events in both directions and the files of each version the agent runs |
| From an agent to the hub | 443, HTTPS | OTLP telemetry: log lines, metrics and traces from the agent and from each integration |
| Into an agent | None | An agent opens no inbound port |
| Into the hub | 443 only, TLS 1.2 and 1.3 with AEAD suites | The admin UI, the API, the CLI, pipelines, API callers and the agents |
| An agent inside the hub's own network | 7422 | The leaf node's link straight to the hub's leaf listener, with no public name, for an agent enrolled with --via hub-network |
| A gateway at a site | The addresses listed in its enrolment, such as a LAN address | API calls at the site, with nothing opened towards the hub or the internet |
Where data lives
| Data | Where | How long |
|---|---|---|
| Versions and their files | The hub's object store, by SHA-256 | Until the version is deleted |
| Events | One stream per environment, within the environment's budget | 30 days |
| Entity store records | One bucket per project, environment and record type | Within the size limit and history the administrator sets |
| Logs | The hub's log store | 30 days |
| Metrics | The hub's metric store | 90 days |
| Traces | The hub's trace store | 7 days |
| Audit log | A stream the backend's own credentials can't delete or shorten | 400 days |
| Secrets | Sealed with AES-256-GCM in the store, under a master key kept in a file on each backend host and never in a backup | Until changed or deleted |
High availability
A hub with three data servers, one in each of three zones or data centres, is behind a TCP load balancer that checks /readyz/node on each of them. Every server runs a TLS terminator, the backend, a gateway and a message server. Each data server keeps a copy of the stored data, and any backend answers any request. Backup copies go to S3 storage with Object Lock, where no key can delete a copy early, and a standby hub keeps the newest backup restored and ready.
- The hub runs on as many servers as you need behind a TCP load balancer with a
/readyz/nodehealth check, and three or five of them are data servers that keep copies of the storage, each copy in its own zone or data centre. - With its data servers in three data centres or cloud providers, one hub keeps working through the loss of a whole data centre with no switch-over step.
- Any backend answers any request, and every server runs a gateway that keeps serving with the last configuration it received when the backend is down.
- An integration runs as two or more copies on matching agents, and a job that runs one copy at a time moves to another agent when its agent goes away.
- When the hub is out of reach, agents keep running their integrations and start them from their saved copy for 24 hours, unless the environment sets another limit. They keep up to 4 GiB of telemetry on their own disk until the link is back.
- Backups go to your S3 storage every 6 hours, and a standby hub keeps the newest archive restored and ready.
Sizing
| Part | Measured |
|---|---|
| Backend | Image about 450 MB, 130 to 300 MB of memory |
| Gateway | Image about 140 MB, 90 to 200 MB of memory |
| NATS | Image 26 MB |
| One Camel integration | 131 to 136 MB of memory, and eight together 820 to 880 MB |
| The hub's services with the three stores | About 500 MB of memory when idle |
| A developer stack with the hub and an agent on one machine | Under 2 GB with up to five integrations |
| A hub as tested | 4 vCPUs and 8 GB of memory |
| Events stored on three 4 vCPU servers | About 600 a second with local SSD, 70 to 100 a second on network disks |
What runs where
This part of the video couldn't be loaded.
Agents
An agent runs on a Linux x86-64 host with Docker that can reach the hub on port 443, tested on Ubuntu 24.04 LTS. An admin enrols the agent, the platform writes the agent's bundle, and sudo sh ./setup.sh on the agent's host starts it. An agent also runs on Windows Server 2022 and 2025, installed from one MSI.
An admin sets capabilities such as region, site or data centre on the agent, and the agent can't set its own. Each integration lists its requirements, and it runs on the agents whose capabilities match them. An agent reaches only the projects and environments an admin allowed.
Systems around the hub
Deploy from your pipeline
Your pipeline runs the weikio CLI and pushes the documents of your Git repository to Weik.io. The platform never connects to a repository, so it needs no Git credentials and no network path to your Git host. GitOps and the CLI
Sign in with your identity provider
People sign in through Microsoft Entra ID or any OpenID Connect provider, and claim mappings turn group claims into grants. Local accounts can be limited to emergency use. Sign-in and providers
Forward to your monitoring
The hub forwards logs, metrics, traces and the audit log to Azure Monitor, Splunk HEC or an OTLP SIEM from a telemetry-forwarding document, and every process serves Prometheus metrics for your own monitoring. Telemetry forwarding
Book an architecture session
An engineer from the Weik.io team plans the hub and the agents for your network with you.