Markus LarssonMost CAN tools display and record frames. With container support, the Helix 2 Plus also runs your own software: it becomes your own CAN node, a programmable edge device that works right where the bus is and runs a wide range of CAN-oriented applications.
Plug in a Helix and you no longer have just an interface. You have a small, rugged Linux computer connected directly to the bus, logging frames and ready to run your own code alongside that logging.
Your Application, Running on the Bus
Helix 2 Plus includes a full container runtime on the device. Package your application as a standard container image and run it directly on the Helix hardware, at the edge, close to where the data is produced.
You can run a wide range of applications:
Custom protocol stacks. Implement your own higher-layer CAN protocol or gateway.
Signal processing and decoding. Turn raw frames into the exact data your systems need.
Edge analytics and inference. Run models close to the source instead of shipping raw traffic to the cloud.
Bridges and integrations. Forward data to your own databases, brokers, or APIs.
Automation. React to bus conditions in real time with your own logic.
If your application works with CAN, it can run on Helix.
Getting Your Container onto the Device
The Docker page, under the left navigation, gives you three ways to get an image onto the device, each suited to a different situation.
Pull from a registry when the device is online and you want a public or private registry image. Load from a file when you are offline: prepare a self-contained image tarball on your workstation and upload it, with no internet, no registry access, and no credentials stored on the device, which suits air-gapped installs and closed-source images. Or build from a Dockerfile directly on the device, with the build log streaming live as it runs.
Once an image is on the device, you run it with a name, an optional command, and a restart policy. You also set CPU and memory limits. Containers share the device's CPU and memory with Helix's own logging and web interface, so set limits on anything you leave running to keep it a good neighbor to those services.
Give Your Container Safe Access to the CAN Bus
Enable Grant CAN access on a container and Helix mirrors its can0/can1 interfaces into your container.
Inside the container, can0/can1 appear as ordinary CAN interfaces that your application reads and writes directly. The real interfaces stay on the host, so Helix keeps control of the physical bus: it continues logging and analyzing the same traffic while your container runs, giving you control and recording at the same time.
The container itself stays isolated. It runs on bridged networking and does not have access to the device's other interfaces or service ports, and its persistent storage is confined to a dedicated SD-card volume that is kept separate from the rest of the device filesystem.
The CAN bridge is re-established automatically across restarts and reboots, so a long-running container keeps its CAN connection without a manual step. Helix also forwards CAN error frames into the container, so your application can detect real bus conditions such as bus-off or error-passive.
Prefer to stay on the network side? A container can also reach CAN through Helix's own encrypted, authenticated backend, using standard
python-canplus bitrate and bus on/off control, with no direct interface access.
Bring It into the Helix UI with Orbit
Running your application on the device is useful on its own. It becomes more useful when its data and controls appear inside Helix. With the Orbit plugin system, you can present your container's data and controls directly in the Helix interface, with no separate app or screen.
An Orbit plugin can provide three kinds of capabilities. Readers are data sources that feed custom values, computed signals, or processed streams into dashboard widgets such as charts, gauges, and consoles. Writers are control outputs that take values from dashboard controls (sliders, toggles, buttons) and hand them to your application. Triggers are callable actions your users can invoke on demand or through automation.
To load a plugin, drag an .orbit file onto the Plugins page.
Once loaded, your plugin's readers and writers become reusable components in any dashboard. Add a widget, choose Add Reader → Plugin, and your data appears alongside native CAN signals. Plugins that need configuration get a host-rendered settings page automatically, generated from the plugin's Orbit schema.
Together, containers and Orbit turn Helix into an application platform: your logic runs on the device with direct, controlled access to the bus, and your users interact with it through the same Helix UI they already know.
Bring Your Own Web Interface, Too
Orbit is one way to present your application inside the native Helix UI, but not the only one. Because containers can publish their own ports, you can also ship a complete web interface inside your container and serve it straight from the device. Run your own dashboard, configuration screen, or API on a port of your choosing, and open it in the browser alongside Helix, over the same WiFi, Ethernet, or VPN connection.
Helix reserves its own service ports, so your interface uses any other port and avoids conflicts with the device's own services. Use Orbit, your own web UI, or both.
From Interface to Platform
This is what we mean by your own CAN node. Helix still does what it did before: dual-channel logging, real-time dashboards, and remote connectivity. The device is now open. Bring your own application, give it access to the bus, and present it to your users.
Helix 2 Plus: an interface, a logger, and a runtime for your own code.
Container support and the Orbit plugin system are available on the Helix 2 Plus. Contact our team to learn more about building your own edge application on Helix.
