Skip to main content
This section is for solutions architects at system integrators and for the customer’s IT and security teams. It covers what runs where, which connections each component opens, and what exists today. Where something is not available or not documented yet, the page says so.

​
Architecture

Cyberwave has three parts. The cloud control plane is operated by Cyberwave. Edge nodes are Linux hosts that you run next to the robots. Your applications can run anywhere. The edge opens every connection outbound, so the site network generally needs no inbound firewall rules.

​
What runs where

​
Where workflow triggers run

Workflows mix cloud and edge nodes in one graph (node reference). The trigger decides where a run starts:

​
Data flows

Recording is on by default for every twin, according to Replay and historical data. This includes camera video. Check this against the customer’s data-handling requirements before you connect cameras.

​
Deployment options

​
Self-hosted: what exists

Cyberwave has a self-hosted package, referred to as Cyberwave Enterprise. It is a Docker Compose stack for a single Ubuntu Server 24.04 host with Docker 24+. Today it works like this:
  • Images. Pulled from a private Docker Hub repository, with a read-only pull token issued by Cyberwave.
  • Catalog. Either synced from the production catalog, which needs internet access and a separate token from Cyberwave, or imported from a snapshot bundle that Cyberwave provides.
  • Updates. Pull newer images and restart the stack. An export command snapshots the database and media first.
  • Pointing clients at it. SDK, CLI, Edge Core and cloud nodes read CYBERWAVE_BASE_URL and CYBERWAVE_MQTT_HOST, so they can target the self-hosted server instead of api.cyberwave.com and mqtt.cyberwave.com.
The self-hosted package is not production-hardened as documented. The reference setup serves the UI, API and MQTT without TLS. It does not document admin bootstrap or how to restrict sign-up. It has no HA, sizing, backup/restore or rollback procedure beyond the snapshot export. Plan TLS termination and access control with Cyberwave before you expose it on a customer network. Contact info@cyberwave.com.

​
Not available or not documented yet

Customers’ IT teams often ask about the items below. Each one was checked against the docs and the public repositories. Don’t promise anything here without written confirmation from Cyberwave.

​
Evaluation checklist

Work through this list with the customer’s IT and OT teams before you commit to a design.
1

Map the network

Get the egress allowlist approved for each component: edge, operator browser, cloud node, and developer machines. Check that TCP 8883 and TLS on 443 are allowed from the cell network. Network and firewall requirements
2

Decide the tenancy model

Choose one workspace per customer or per site, and decide who owns the service tokens. API tokens · Access control · Slugs
3

Confirm hardware support

For each robot model, confirm whether an official driver exists or you will write one. Custom hardware · Writing compatible drivers
4

Plan provisioning and updates

Run a scripted install on one golden device. Pin the Edge Core version and decide how updates roll out. Fleet provisioning
5

Plan integration with business systems

Pick the surface for each system: REST, MQTT, workflow webhooks, MCP, or a custom driver. Integration surfaces
6

Agree monitoring and escalation

Decide who watches alerts and edge status, and how alerts reach the on-call team. Alerts
7

Close the gaps in writing

Get written answers from Cyberwave for every item in “Not available or not documented yet” that the customer requires.

​
Next steps

Network and firewall

Every host, port and protocol, per component.

Fleet provisioning

Install edge nodes headlessly, then name, monitor and update them.

Integration surfaces

REST, MQTT, webhooks, MCP, ROS 2 and more, with auth for each.

Architecture

The general platform architecture and its local data bus.