Network

Weik.io 2026.2

Every connection between the hub, the sites, the CLI and your API callers, with its port and protocol, and the firewall rules that follow from them. Product page · Video

Watch: What runs where, 3:41

The video shows where the hub, the sites and the agents run and the two outbound connections a site makes on port 443.

On this page

What leaves a site
What stays inside a site
Ports at the hub
The hub’s four names
Firewall rules

Weik.io never opens an inbound port at a site. A site makes two outbound connections to the hub, both on port 443, and everything else it does is the integrations’ own traffic to your systems. The hub publishes port 443 and nothing else, and it terminates TLS for its own names and for every gateway hostname.

What leaves a site#

From	To	Port and protocol	Carries
The site’s leaf node	The hub’s link address, such as `nats.acme.example`	443, WebSocket over TLS (`wss`)	The agent’s control traffic, events in both directions and the built integration versions the agent fetches
Each integration’s Java process and the agent	The hub’s address, `/otlp/v1/logs`, `/otlp/v1/metrics` and `/otlp/v1/traces`	443, HTTPS	Logs, metrics and traces over OpenTelemetry (OTLP), each process with its deployment’s own credential

Both connections go to port 443 of the hub, so a site that can reach the hub at all can do both. A site that also runs a gateway uses the same two connections. Logs, metrics and traces don’t travel on the link the agent’s control traffic uses, which keeps the bulk of the data off the connection the site depends on.

An integration’s own traffic, such as calls to an ERP, a bank’s SFTP server or a database, leaves from the site on that system’s own port. Weik.io neither opens nor manages it.

What stays inside a site#

Between	On
The Java processes and the local leaf node	Port 4222 on the site’s own container network, never published
The agent and each process’s health and metrics endpoint	One loopback port per process, from a configured range
The agent and a running integration, for `weikio invoke`	Files in the integration’s run folder, with no network port
An integration’s own HTTP listener	Port 8080 on every interface, as plain `camel run` serves it, unless the integration sets its own server settings. The site’s firewall decides who reaches it.

A partner the hub serves can call an API in front of an integration at a site through a hub gateway that relays to the site’s gateway, with no port opened at the site. Gateways at sites describes the relay.

Ports at the hub#

Listener	Port	Reached by
The backend: the API, the admin UI, the token issuer and the OTLP ingest	443, through your load balancer	The CLI, pipelines, browsers and every site
APIM, the API gateway	443, one or more hostnames per environment	Your API callers
The message server’s link listener	443, WebSocket	The leaf node of every site
The message server’s client port	The hub’s own network only	The backend and APIM, and an agent’s credential is refused there
The log, metric and trace stores	The hub’s own network only	The backend only
`/healthz`, `/readyz` and `/metrics`	An internal listener	Your monitoring

Port 443 at the hub passes each connection on by the name it asks for. The hub’s own names end TLS at the hub’s terminator, and every gateway hostname goes to APIM, which ends TLS with that gateway’s certificate. TLS 1.2 and 1.3 are accepted, and on TLS 1.2 only the AEAD cipher suites, AES-GCM and ChaCha20. On a hub of several servers, the message servers’ routes between the servers use TLS too.

The platform obtains and renews every certificate itself. A name that points at the hub is proved to the public authority on port 443, and a name behind a CDN’s proxy or on an internal network is proved through DNS. A name no public authority signs, such as an .internal name, gets a certificate from the platform’s own authority. Certificates describes each source and when the platform uses it.

The hub’s four names#

An installation with two environments has four DNS names, all pointing at the hub’s address:

Name	Goes to	Used by
`acme.example`	The backend and the admin UI	The CLI, pipelines, browsers and the telemetry of every site
`nats.acme.example`	The message server’s link listener	The leaf node of every site, as `wss://nats.acme.example:443`
`api.acme.example`	APIM, the gateway of production	Callers of production APIs
`api-test.acme.example`	APIM, the gateway of devtest	Callers of devtest APIs

The two API names are the hostnames of each environment’s gateway. Adding a gateway or a hostname adds a name here and in DNS, and the platform obtains its certificate. When the names sit behind Cloudflare’s proxy, the CLI uploads large integration files in parts under the proxy’s request size limit and resumes an interrupted upload.

Firewall rules#

Direction	Rule
Inbound to the hub	Port 443 only, from wherever the CLI, pipelines, API callers and sites connect from
Inbound to a site	Nothing
Outbound from a site	Port 443 to the hub’s address. The integrations’ own traffic to your systems is separate.
Outbound from the hub	The Maven repositories the builder resolves dependencies from, which an air-gapped hub replaces with one mirror, and, when you set them up, a Dapr secrets sidecar and the systems telemetry forwarding sends to

The hub never connects to a Git repository. Pipelines push changes into the hub with the weikio CLI, so the hub needs no Git credentials and no network path to your Git host.

An agent beside the hub, in the hub’s own network, can link to the message server’s listener on port 7422 directly instead of through port 443. It’s enrolled with --via hub-network and needs no public name. The hub’s allowed networks limit which addresses can reach the hub’s names at all, and Allowed networks and TLS describes them.