Gateway release notes

The Gateway can be an OPC UA server, read-only, so a third-party client can browse and read its tags.

• A read-only OPC UA server exposing the Gateway’s tags as an address space. Nodes are read-only, and there is no write handler at all, so this version has no setting that enables writes.
• Secure channels use Basic256Sha256 in Sign and SignAndEncrypt. SecurityPolicy None is an explicit opt-in.
• Users log in with their HotLoop user name and password, the same user database and bcrypt hashes as the web login, and must hold tags.read and values.read. Permissions are re-checked on live sessions, so revoking one takes effect without waiting for a reconnect.
• Anonymous sessions are an explicit opt-in, and a client’s application certificate has to be approved by an operator before it is trusted.

Writes are deliberately absent. The runtime has one write gate, and an OPC UA write would have to go through it. That deserves its own review, so it did not ride along in this release.

Database backups, taken in pure Go over the existing connection, with a restore that refuses to touch a database that already has data.

• A logical snapshot of every configuration and history table, taken inside one REPEATABLE READ transaction so it is consistent. It is table data only, since migrations rebuild the schema from nothing on every start.
• No pg_dump. The runtime image is distroless with no shell and no external binaries, and backups do not get an exception to that.
• Retention defaults to 7 backups, and 0 keeps everything. An optional interval scheduler runs backups on a plain interval, not cron.
• Restore is deliberately not an API endpoint. It is a flag an operator runs by hand against an empty, freshly migrated database, and it refuses a target that already has data.

Not verified, and stated in the backup docs: very large history volumes, where long-transaction and connection-pool behavior have not been measured, and restoring across Gateway versions that changed the schema.

An optional embedded MQTT broker, so a single-box install can be its own Sparkplug hub.

• An in-process broker with a plain TCP listener on 1883, plus a TLS listener on 8883 whenever a certificate and key are configured.
• Credential authentication, checked in constant time. Anonymous access is an explicit, off-by-default opt-in.
• Fleet management, edge publishing, and an edge relay can all point at localhost with nothing else to stand up.

There is no per-topic access control, by design. The broker is the authorization boundary, and for a production deployment at scale you should still run a dedicated broker such as Mosquitto or EMQX.

Alarm notifications by webhook and email, so a 03:00 alarm can reach a phone.

• Two provider-agnostic channels. A webhook posts JSON to any URL, which composes with PagerDuty, Opsgenie, ntfy, Pushover, Slack, Discord, or a script of your own. Email goes out over SMTP.
• Notifications fire when an alarm is raised, and only then. Cleared, acknowledged, and shelved alarms are deliberately not page-worthy.
• A priority floor per channel, so a channel set to high and above stays quiet for a low alarm.
• SMTP upgrades to STARTTLS automatically when the server offers it, which authenticated relays generally require. It is tested against a local server configured for STARTTLS and authentication, and not against a hosted provider.

Off by default. A test endpoint, restricted to administrators, lets you verify a channel without waiting for a real alarm.

The rename to HotLoop: module path, container images, charts, and environment variables.

• The Go module is now github.com/HotLoop-io/hotloop, and the images are ghcr.io/hotloop-io/hotloop and ghcr.io/hotloop-io/hotloop-edge-relay.
• Both Helm charts are renamed to hotloop and hotloop-edge-relay.
• Every IIOT_ environment variable is now HOTLOOP_.

The App Store labels and annotations under the embernet.ai namespace are unchanged on purpose. A namespaced key names the system that reads it, and those labels are how the EmberNET App Store finds a chart.

Config push: stage a new device file on a fleet relay without touching it by hand.

• The Gateway publishes a device file to a retained MQTT topic per relay, validated before it is published with the same validation the relay uses, so a malformed file never reaches a relay.
• A push and a restart are two separate operator actions on purpose. Pushing to a running relay only stages the file for the next restart, and a relay that is offline picks it up automatically when it reconnects.
• Pushing a config is administrator-only.

Fleet management: see registered edge relays, and command them.

• Membership is declared, not auto-trusted. A birth message from an unregistered relay is logged and ignored.
• Presence comes from Sparkplug birth and death messages, which are outbound from the relay and work through NAT with no inbound connection to a relay ever required.
• Rebirth is open to operators. Restart is administrator-only, since it takes a relay down.

The application cannot enforce this part, so the docs say it plainly: the broker’s own access controls should restrict publishing of node commands to the Gateway’s credentials.

A second binary, the Edge Relay, with no database at all, and two ways to deploy it.

• The Edge Relay is a separate, lighter binary that polls equipment and forwards it, with no PostgreSQL dependency. About 16.9 MB against the Gateway’s 33.4 MB.
• It exposes only /healthz and /status, read-only and unauthenticated, since there is no identity system to guard them and nothing sensitive in the response.
• Deployable on k3s with its own Helm chart, or on a box with no cluster as a Podman Quadlet unit that runs as a real systemd service.

The Gateway can be a Sparkplug B edge node, with a queue that survives a restart.

• A disk-backed queue with at-least-once delivery, oldest-first eviction when it fills, and no loss across a restart.
• Full Sparkplug B edge node behavior: birth, data, and death messages, sequence numbers, and rebirth on request.
• Buffered readings replay as historical data, one message per reading, in order.

Off by default.

A login, and writes off until someone turns them on.

• Local users with bcrypt-hashed passwords, sessions by cookie or bearer token, and three roles: admin, operator, and viewer.
• Every route checks a permission before it does anything.
• Writes are off by default. They used to be on, and a tag is now read-only until somebody marks it writable, one at a time.
• The Helm chart generates an admin account into the release Secret.