How Weik.io is put together
A Weik.io installation has a hub and any number of sites. 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 three or five for high availability. A site is a Linux host with Docker where an agent runs your integrations, and it connects to the hub with two outbound connections on port 443.
The hub and the sites
The hub runs a message server, the backend, the gateway and the log, metric and trace stores on one server, or on three or five for high availability, and it publishes port 443. Three sites connect to it: a factory site inside a customer network, a site in the customer's Azure account and cloud agents in Weik.io Cloud. Each site has a leaf node and an agent that 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 site accepts an inbound connection.
What the drawing shows:
- The hub on one server or on three: a message server, a backend and a gateway on each server, and the log, metric and trace stores.
- A site inside a factory network, a site in your Azure account and cloud agents in Weik.io Cloud.
- At each site a leaf node, an agent and one Java process for each running integration.
- Two connections from each site 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 site. The gateway is the API gateway, with an instance on every hub server and, where you want one, at a site.
NATS JetStream is the only store of the three programs. Versions and their files, configuration, events, the entity store and the audit trail 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 a site 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 a site to the hub | 443, HTTPS | OTLP telemetry: log lines, metrics and traces from the agent and from each integration |
| Into a site | None | A site 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 sites |
| A site 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 -- |
| A site gateway | The entrances its enrolment lists, 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 trail | 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
Three data servers in three zones sit 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.
- Three or five data servers across zones keep copies of the storage behind a TCP load balancer with a
/readyz/nodehealth check. - Any backend answers any request, and every server runs a gateway that serves from its last route table when the backend is away.
- 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.
- Sites keep running on their saved state for a day when the hub is out of reach, and 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 a site 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
Sites
A site is a Linux x86-64 host with Docker that can reach the hub on port 443, tested on Ubuntu 24.04 LTS. An admin enrols an agent, the platform writes a site bundle, and sudo sh ./setup.sh at the site starts it. Windows Server 2022 and 2025 sites with an MSI installer arrive with Weik.io 2026.2.2.
Capabilities such as region, site or data centre are written on the agent by an admin, never claimed by the agent itself. 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 the hub. 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 trail to Azure Monitor, Splunk HEC or an OTLP SIEM from one document, and every process has a Prometheus page for your own monitoring. Telemetry forwarding
Book an architecture session
An engineer from the Weik.io team plans the hub and the sites for your network with you.