Your onboard application exists as a Helm chart, the pipeline is in place, your team knows Kubernetes. Only in the vehicle did that workflow stop short, at an additional compute box or at a rewrite of the application for the router. With Unwired Edge Compute for Kubernetes it now runs where it belongs: as a Kubernetes workload directly on the vehicle router.
The Router Becomes the Platform for Your Applications.
Passenger information, automatic passenger counting, diagnostics and video analytics stopped being single programs long ago. They are systems made of several services with their own databases, interfaces and release cycles. The people who build them work with manifests, Helm charts and GitOps. In the vehicle, that state of the art had to stay outside: either every application got its own box in the equipment cabinet, or the software was taken apart and adapted for the router.
Unwired Edge Compute for Kubernetes changes that. The vehicle router that already sits in the vehicle for WAN bonding, passenger Wi-Fi and the in-vehicle network now also runs a Kubernetes cluster with a standard API. Your application runs on it unchanged, with the standard Kubernetes API, with Helm and with the GitOps tool of your choice. For you, that means one piece of hardware less per vehicle, no special path for onboard software, and a deployment process that is the same from the data center to the train.
What You Get with Unwired Edge Compute for Kubernetes.
One Cluster per Vehicle.
Every router runs its own single-node cluster. Multi-node clusters spanning several vehicles are deliberately not supported, and for good reason: a train is not an availability zone. Cars are coupled and uncoupled, links between vehicles break, devices fail one at a time. A cluster that had to hold a quorum across those boundaries would cause trouble exactly when you need it.
That is why every cluster stays operational on its own, and high availability is built where it actually works in a vehicle: in the application itself and through the failover sidecar between devices. For your team, that means fewer edge cases in operation and behavior you can reproduce in the lab.
Operations and Security from a Single Source.
The Kubernetes service is part of the device configuration and is activated and rolled out through the device management of the Unwired Edge Cloud, just like modems, VLANs or WAN bonding. New Kubernetes versions arrive as package updates that Unwired releases regularly; before release, the operating system and the Kubernetes service go through automated tests, long-running tests on lab devices, and an SBOM and CVE check. You schedule operating system updates in rollout windows with limited concurrency, so the entire fleet never updates at the same time.
For tenders and audits, that counts twice. Containers run isolated from the host system, workloads follow Pod Security Standards as non-root with resource limits, and observability provides the version evidence that CRA, NIS2 and ISO 27001 demand across the lifecycle. You meet those requirements with the same platform you use to manage devices and network.
When the Standard Edition Is Enough.
Not every application needs Kubernetes. Unwired Edge Compute Standard runs lightweight OCI containers and is available across the entire device portfolio. For a single service with a clear job, such as an onboard portal or an interface integration, it is the right choice. The overview shows what a vehicle router does without Edge Compute, what the Standard edition adds, and what only comes with Kubernetes:
| Without Edge Compute | Standard | Kubernetes | |
|---|---|---|---|
| Device management, WAN bonding, passenger Wi-Fi from the Unwired Edge Cloud | ✓ | ✓ | ✓ |
| Observability for router and network | ✓ | ✓ | ✓ |
| Applications run on the vehicle router instead of on separate hardware | ✗ | ✓ | ✓ |
| OCI containers, isolated from the host system | ✗ | ✓ | ✓ |
| Application updates without a firmware build | ✗ | ✓ | ✓ |
| Activation and rollout from the Unwired Edge Cloud | ✗ | ✓ | ✓ |
| Access to VLANs of the in-vehicle network | ✗ | ✓ | ✓ |
| Access to physical interfaces (CAN, RS485, GPIO, GPS, USB) | ✗ | ✓ | ✓ |
| Persistent storage on internal SSD | ✗ | ✓ | ✓ |
| Runs across the entire device portfolio, from 1 CPU core and 256 MB RAM | ✓ | ✓ | ✗ |
| Standard Kubernetes API, Helm charts, CRDs | ✗ | ✗ | ✓ |
| GitOps deployment with ArgoCD, Flux or Open Cluster Management | ✗ | ✗ | ✓ |
| Orchestration of multiple services (Deployments, StatefulSets) | ✗ | ✗ | ✓ |
| Advanced networking, multiple network interfaces per pod | ✗ | ✗ | ✓ |
| Persistent Volumes for Kubernetes workloads on SSD or NVMe | ✗ | ✗ | ✓ |
| Failover between vehicles with a virtual service IP | ✗ | ✗ | ✓ |
| Pod Security Standards, resource limits, probes | ✗ | ✗ | ✓ |
| Container logs and metrics in real time to the Unwired Edge Cloud and on to your own monitoring systems | ✗ | ✓ | ✓ |
| Base services for networking, storage, observability, hardware access and failover, maintained by Unwired | ✗ | ✗ | ✓ |
| Minimum requirements | none | 1 core, 256 MB RAM | 2 cores, 1 GB RAM, SSD or NVMe |
Unwired Edge Compute for Kubernetes pays off as soon as an application consists of several services, comes as a Helm chart, or your team already works with GitOps. It requires an x64 or arm64 router with SSD or NVMe; large rail routers and onboard servers have that on board. For such devices, Unwired recommends the Kubernetes edition for all new projects.
Conclusion.
Kubernetes on the vehicle router means your onboard application rides into the train with the same toolbox it was built with. No additional box, no firmware build for a software update, no technician at the vehicle for a release. How both editions fit into the edge computing platform of the Unwired Edge Cloud is covered on our page on edge computing with a container runtime on vehicle routers. Whether your application runs on your routers is something we can settle fastest together: start a demo or get in touch.
FAQ
Yes, if the router has enough resources and the operating system ships a Kubernetes service. A vehicle router is an industrial Linux device with modems, Ethernet and Wi-Fi; on capable models with two or more CPU cores, at least 1 GB RAM and an SSD, it can run a single-node Kubernetes cluster that executes onboard applications as pods. Unwired Edge Compute for Kubernetes delivers this service as a package of the Unwired Edge Cloud OS, activated through the device management of the Unwired Edge Cloud. Applications are described with standard Kubernetes manifests or Helm charts and rolled out via GitOps.
Because many onboard applications have to run where the data and the hardware are. Passenger information, passenger counting, video analytics and diagnostics need access to cameras, sensors, GPS, serial interfaces and the in-vehicle network, and they have to keep working when the train or bus has no connection. Unwired Edge Compute for Kubernetes brings the deployment standard from the data center to that place: the same manifests, Helm charts and GitOps tools, just on the router instead of a server. The cloud stays responsible for device management, observability and distributing new versions, not for running the pods.
Full Kubernetes in a single-node configuration. The router runs the control plane with embedded etcd, kubelet and containerd as the container runtime; the standard Kubernetes API is available, as are Deployments, StatefulSets, ConfigMaps, Secrets and CRDs. What is missing is the distribution of a cluster across several nodes. In Unwired Edge Compute for Kubernetes, the Unwired Kubernetes Service (unwired-ks) takes on this role; Helm, ArgoCD, Flux and Open Cluster Management work as they do on any other cluster.
Because a train is not an availability zone. Multi-node Kubernetes relies on stable links between nodes to hold a quorum; in a vehicle, cars are coupled and uncoupled, links between vehicles break and devices fail one at a time. A cluster that had to reach consensus across those boundaries would be unstable exactly when it is needed. That is why Unwired Edge Compute for Kubernetes deliberately runs an independent cluster per router. High availability is built at the application level or through a failover sidecar that manages a virtual service IP via VRRP across several routers.
The cluster keeps running, because the control plane and the workloads are local to the router and the Kubernetes API is reachable on the device. The connection to the cloud is needed for device management, forwarding logs and metrics, and syncing with the GitOps repository, not for running the pods. A pull-based GitOps tool such as ArgoCD or Flux fetches the desired state as soon as a connection is back. In Unwired Edge Compute for Kubernetes, the firmware additionally records the state of the Kubernetes service, so the Unwired Edge Cloud still reports whether service and node are running even when nothing is getting through inside the cluster itself.
An x64 or arm64 device with at least two CPU cores, 1 GB RAM and persistent storage such as SSD or NVMe. In Unwired Edge Compute for Kubernetes, the base system uses about 0.3 CPU cores and 500 MB RAM, with the rest available to your applications; for storage, plan at least 4 GB plus container images and data. Large rail routers and onboard servers have these reserves. Smaller routers with one CPU core and 256 MB RAM run containers with Unwired Edge Compute Standard. The list of supported devices shows which devices are supported.
Applications made of several services that come as a Helm chart or are meant to be rolled out via GitOps: passenger information systems with a database and interfaces, automatic passenger counting with analysis, video analytics, diagnostics and telemetry stacks. A single service with a clear job, such as an onboard portal for passenger Wi-Fi, a VPN or an interface integration, does not need Kubernetes; lightweight OCI containers are enough for that, at Unwired the Edge Compute Standard edition. For capable devices, Unwired recommends Unwired Edge Compute for Kubernetes for all new projects.
Separately. Applications arrive via GitOps: a new commit in the repository, and every vehicle pulls the new version, with no firmware build and no maintenance appointment at the vehicle. The Kubernetes service itself is a package of the Unwired Edge Cloud OS in Unwired Edge Compute for Kubernetes; new versions arrive as package updates that Unwired releases regularly and secures beforehand with automated tests, long-running tests on lab devices, and an SBOM and CVE check. Operating system updates are scheduled in rollout windows and rolled out with limited concurrency, so the entire fleet never updates at the same time.
Through additional network interfaces and device mappings that Kubernetes does not provide out of the box. In Unwired Edge Compute for Kubernetes, the default pod network attaches to a bridge in the router’s host network; through advanced networking, pods get further interfaces and connect directly to VLANs or bridges of the in-vehicle network, such as the passenger network or the operational network. The integrated hardware access passes GPIO, GPS, RS485, USB, audio and DisplayPort through to pods. Both are optional base services that Unwired tests and maintains. WAN bonding, VLANs and the firewall stay in the device management of the Unwired Edge Cloud.
It provides the building blocks these frameworks demand across the lifecycle: isolated workloads, traceable versions and regular security updates. Containers run separately from the host system, workloads follow Pod Security Standards as non-root with resource limits, and every version is documented as a manifest or Helm chart in the repository. Unwired Edge Compute for Kubernetes adds the SBOM and CVE check of the operating system and the Kubernetes service, plus the observability of the Unwired Edge Cloud, which records versions and states centrally. The duty to provide evidence stays with the operator; the platform supplies the data for it.
