Technical building blocks

gtbapexpress

Open Apexpress

Deploy containers on an ECLYPSE APEX in a few clicks — Mosquitto, Zigbee2MQTT, Node-RED, ChirpStack, InfluxDB, Grafana… Windows executable + demo mode.

eclypse apex
docker
mqtt
node-red
chirpstack

$ download source code

no APEX at hand? the executable has a demo mode with a simulated APEX.

Your containers on ECLYPSE APEX, express. Distech Controls' APEX runs Docker containers. But between the OPA plugin rules, ARM64 images, no SSH and JSON to write by hand, setting up Mosquitto + Zigbee2MQTT + Node-RED quickly takes an afternoon.

Open Apexpress does all of that in a few clicks, only through the APEX's official REST API v2. No install, no dependency: a standalone .exe to hand a colleague on a USB stick.

Open Apexpress catalogue: ready-made packs and services to tick, with their status and port — choosing services, here the Zigbee pack + Grafana (demo mode)

§ 01 What it does

Install: Tick the services or pick a pack (Zigbee, LoRaWAN, Trends, Maintenance). Images, creation and start in the right order, live progress, then links, credentials and a report.
Catalogue: Mosquitto, Zigbee2MQTT, ChirpStack, Node-RED, InfluxDB, Telegraf, Grafana, Cloudflare Tunnel, Tailscale, FileBrowser, ntfy, Uptime Kuma, MQTT Web, Netdata, Nginx Proxy Manager, a links portal… ARM64 images checked, tags pinned.
On the APEX: Containers (state, clickable ports, start, stop, restart, delete) and volumes, with protected deletion.
Backups: A volume as a .tar.gz on your PC, without SSH, and restore into an existing or new volume: enough to copy one APEX to another.
Updates: Each image compared with Docker Hub, new image pulled before touching the service, container recreated with its configuration and volumes.
Tools: Test whether an image runs on ARM64, deploy a custom container checked against the OPA rules, log of every request sent to the APEX.
MCP ECLYPSE: An MCP server giving Claude access to the APEX's BACnet points, trend logs, schedules and alarms. Read-only by default, supervised writing as an option.

Install finished: each service checked, then the links and notes for each service — install finished: links, credentials and notes per service

§ 02 Up and running in 1 minute

Download OpenApexpress-x.y.z-windows-x64.exe from the GitHub releases.
Run it: a console opens (keep it open) and the interface appears in your browser.
Enter the APEX IP, its username and password, or click Try without an APEX (demo mode).

The file is not digitally signed: on first launch, “Windows protected your PC” → More info → Run anyway.

The APEX needs Internet access to pull the images.

§ 03 The OPA rules, applied for you

The APEX's OPA authorisation plugin rejects a lot. Every generated container follows what was observed in the field:

host ports in the 50000-50500 range;
every published port declared in ExposedPorts;
named volumes through Mounts, never Binds;
a single core for containers ("CpusetCpus": "0"), control keeps the others;
lowercase container names, ARM64 images with pinned tags;
no privileged container, device or host network.

§ 04 Security

The interface only listens on your machine (127.0.0.1) and requires a token generated at each launch: no other machine or website can drive the APEX through the tool.
APEX credentials stay in memory, are never written to disk and are only sent to the APEX.
Generated passwords only appear on the final screen and in the report: keep that report somewhere safe.
The MCP server is read-only by default. With writing enabled, it simulates first, only writes after confirmation, at a dedicated BACnet priority, and logs every write.

The containerisation API responses are not documented by Distech. The very first use on a real APEX is done with an eye on the Log tab. Services marked “To test” should be tried on site before you rely on them.

§ 05 What you get, service by service

17 services in the catalogue, all verified ARM64 images with pinned tags. What each one is for, and why it is handy:

🔌 The message bus

Mosquitto validated on APEX The MQTT broker: the crossroads every message between sensors, Node-RED and the rest goes through. The cool part: optional authentication is propagated to the other services automatically.
MQTT Web to test An MQTT client in the browser to watch messages go by and publish by hand. The cool part: debug without installing anything on your PC.

📡 Wireless sensors

Zigbee2MQTT validated on APEX The gateway that turns Zigbee sensors into MQTT messages, through an Ethernet coordinator (SLZB-06…). The cool part: your Zigbee sensors run in the cabinet, with no vendor cloud.
ChirpStack validated on APEX A complete LoRaWAN server (PostgreSQL, Redis, Gateway Bridge, REST API). The cool part: your own LoRaWAN network on the APEX, with no custom image to build thanks to a small init container.

🧠 The link with the BMS

Node-RED validated on APEX The flows that connect MQTT to the APEX REST API and therefore to BACnet points. The cool part: it is the bridge that turns an MQTT message into a point the BMS can read; password and modules can be preinstalled.
MCP ECLYPSE to test An MCP server that gives Claude read access to BACnet points, trend logs, schedules and alarms. The cool part: you ask your installation a question in plain language; read-only by default, supervised writing optional.

📈 History and trends

InfluxDB validated on APEX The time-series database that keeps the measurement history. The cool part: retention is adjustable, so you do not fill the APEX storage.
Telegraf validated on APEX The collector that sends MQTT messages (Zigbee, LoRaWAN, free topics) to InfluxDB. The cool part: its configuration is generated, nothing to write by hand.
Grafana validated on APEX The dashboards to visualise the curves. The cool part: the InfluxDB data source is created automatically, you open it and see your measurements.

🔐 Remote access and security

Cloudflare Tunnel validated on APEX Remote access without opening a port. The cool part: it works even when the APEX sits behind a 4G modem.
Tailscale validated on APEX A mesh VPN in userspace mode, with the APEX advertised as a route. The cool part: you reach the APEX from outside without setting up a VPN by hand.
Nginx Proxy Manager to test A reverse proxy with certificate management. The cool part: your services answer under a proper name instead of IP:port.

🚨 Monitoring and alerts

ntfy to test Push notifications on your smartphone, with no cloud. The cool part: an alarm reaches your phone without any third-party service.
Uptime Kuma to test Monitoring of the site's equipment (ping, HTTP, ports). The cool part: you know a device is down before the customer calls.
Netdata to test CPU, RAM and disk of the APEX in real time. The cool part: you see whether the APEX is struggling before adding one more container.

🛠️ Troubleshooting and comfort

FileBrowser validated on APEX A file explorer to read logs and edit the configs of a volume. The cool part: you troubleshoot without SSH, which the APEX does not offer.
Portail APEX validated on APEX A home page with the links to every installed service. The cool part: a single entry point to hand to the customer.

“Validated on APEX”: recipe used on a real APEX. “To test”: ARM64 image verified, but not yet validated on a real APEX with Open Apexpress.

MIT licence. Independent project, not affiliated with Distech Controls. ECLYPSE is a trademark of Distech Controls. github.com/OpenGTB/open-apexpress