Eclipse Kura turns a Raspberry Pi into an IoT gateway with a web UI and a wire editor

A framework for the gateway, not a script on a board

Eclipse Kura is described in the repository as a versatile software framework for edge devices. With an intuitive web interface, it simplifies configuring a gateway, connecting sensors and IoT devices, and collecting, processing and sending data to the cloud. The name comes from the Maori word for tank or container.

It runs on an edge gateway, which the README says can be anything from a small single-board computer such as a Raspberry Pi to a powerful high-performance computer. That range is the design brief, and it explains the shape of the software.

The mechanism is a plugin architecture with two extension points that matter most. There is an extensible Java API for developing custom plugins within the framework, and the plugin model lets you add your own Services and Drivers. On top of that sits a REST API, which the README presents as enabling the use of Kura as a backend service in your application, that is, embedding the framework rather than running it as a standalone box.

So Kura is two things at once: a complete gateway application you can install and configure from a browser, and a set of libraries you can pull into your own edge application. That dual nature is the main thing to understand before choosing it.

Ten named subsystems, and a visual editor for data flows

The feature list in the README is organised as named Kura capabilities, and reading them in order shows what the framework expects to own.

Kura Services lets you provision and set up features to run on the gateway, such as an MQTT broker. Kura Networking manages network connectivity. Kura Wires lets you design data flows and data processing streams with a drag and drop visual editor. Kura Cloud Connectors is the extendable cloud connector system. Kura Drivers is the extendable service that handles reading data off external devices.

Then the operational ones. Kura Snapshots securely stores and re-applies gateway settings. Kura Security stores your secrets. Kura Container Orchestrator manages Docker or Podman containers on the gateway. Kura AI Inference runs Nvidia Triton models on the edge. Kura Plugins adds Services and Drivers of your own. And Kura REST Service lets you embed the framework as a backend in your own edge applications.

The interesting one for most people is Kura Wires, because it removes the scripting from routine data work. A drag and drop editor for data flows means a technician can rewire a pipeline through the web interface rather than by editing code and redeploying, and the fact that it is called out as a headline feature suggests it is the part users notice first.

The other two that shape hardware choices are Kura Container Orchestrator, which pins your gateway to having Docker or Podman available, and Kura AI Inference, which assumes an Nvidia Triton runtime if you want local models.

The APT install is four steps and a signed repository

The quick Linux installation is documented as a single block of commands, and the APT repository provides packages for both x86-64 and arm64 architectures.

# Install required tools
sudo apt update
sudo apt install -y curl gpg

# Add the Eclipse Kura APT repository key
curl -fsSL "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xBA7E3DF5EDC3FC36" \
  | gpg --dearmor \
  | sudo tee /etc/apt/keyrings/kura.gpg > /dev/null

# Add the Eclipse Kura APT repository
sudo tee /etc/apt/sources.list.d/kura.sources > /dev/null << 'EOF'
Types: deb
URIs: https://repo.eclipse.org/repository/kura-apt/
Suites: stable
Components: main
Signed-By: /etc/apt/keyrings/kura.gpg
EOF

# Update package index and install Eclipse Kura
sudo apt update
sudo apt install -y kura

The shape of it is the modern Debian repository pattern: fetch a key, dearmor it into /etc/apt/keyrings, write a deb822 .sources file pointing at repo.eclipse.org with the Signed-By key path, then install the kura package. The README notes you may need sudo privileges to run these commands, which is worth remembering for CI environments where the runner is not root.

Two other install routes exist. There are pre-built installers for common development boards, linked from the Eclipse downloads page, with the documentation page on supported platforms and installer types as the place to check before you commit to a board. And there is a Docker container published on Docker Hub, with build and run instructions in the kura-metapackage repository.

The compatibility statement is that Eclipse Kura is compatible with Java 21, and the container route is the one to consider if your gateway is not a Debian derivative.

Building it is a plain Maven build on JDK 21

The build prerequisites are JDK 21 and Maven 3.9.9 or newer, and the README says the build runs on Linux, macOS and Windows as a plain Maven build producing the same artefacts everywhere.

That last sentence contains the detail that matters operationally. Eclipse Kura itself runs on Linux gateways, so what you build on macOS or Windows are the packages to install on a device. The build machine and the target machine are different concerns, and the README says so directly.

The repository layout is a large multi-module Maven project. There is a pom.xml at the top, a kura/ directory for the main code, distrib/ for the distribution artefacts, bom/ for the bill of materials, test/ for the test suites, checkstyle-resources/ for the style configuration, a Jenkinsfile and a .jenkins/ directory for the CI definition, and both AGENTS.md and CLAUDE.md at the top level, which tells you the project has been set up for agent-assisted development. There is also SECURITY.md, a CODE_OF_CONDUCT.md, a PULL_REQUEST_TEMPLATE.md and a NOTICE.md alongside the LICENSE.

The build badges in the README point at Jenkins on ci.eclipse.org rather than GitHub Actions, with separate jobs for the develop branch and a multibranch setup, and the default branch for the project is develop rather than master. That is the Eclipse Foundation convention for a project under active development, and it means the branch you clone is not the branch you release from.

For macOS developers, the README gives a specific path: download the JDK 21 tar archive from the Adoptium project repository, copy it into /Library/Java/JavaVirtualMachines/, cd into it, and unpack with sudo tar -xzf. The tar archive can be deleted afterwards.

Scaling means adding a second project

The README asks a question that is really an admission about the scope of the project, and then answers it with a redirect.

The question is what to do if you have used Eclipse Kura to make a small scale edge deployment and now want to scale and manage many instances of Kura. The answer is Eclipse Kapua, described as an Eclipse Kura compatible cloud command and control service that allows you to aggregate data and configure many Kura devices.

That is a significant architectural fact for anyone evaluating this. Kura is the thing on the device, and if you have more than a handful of devices, the project is telling you that the management plane is a separate piece of software with its own repository and its own deployment.

The alternative would be for Kura itself to include fleet management, and it does not. So the sizing question is really: at what point does your fleet become big enough that you need Kapua as well? One gateway is a Kura problem. Fifty gateways with the same configuration are a Kura plus Kapua problem, with the configuration pushed from the cloud side rather than edited on each device.

It also reframes what the web interface is for. On a single device, the web UI is how you configure it. In a fleet, the web UI is how you inspect it, and Kapua is how you change it across the fleet.

What this framework costs you on the device

There are real constraints, and they follow from the design rather than from shortcomings.

The heaviest is the runtime. A Java 21 stack, an OSGi-style plugin framework, a web interface, an MQTT broker, a container orchestrator, a secrets store and a visual editor is a lot of software to run on a single-board computer, and the README says a Raspberry Pi is a valid target. Whether that is comfortable depends on the board, and the snapshot and container features in particular assume there is storage and a container runtime to manage.

The second is the plugin model. The API is extensible, which is the point, but the same extensibility means the behaviour of a given gateway depends on which plugins are installed. Kura Snapshots, which stores and re-applies gateway settings, exists precisely because a gateway with custom plugins has state worth capturing, and that is also a warning that the configuration surface grows.

The third is the division of responsibility. Running Kura as a backend service inside your own edge application, via the REST API, means the framework is a library dependency with its own lifecycle in your process. The Kura REST Service feature is what makes that possible, and it is also the part with the least documentation in the README, which links to a wiki for developer documentation rather than describing the REST surface here.

None of this makes Kura wrong. It makes it a framework for a serious deployment, where the alternative is assembling the same capabilities yourself and owning every integration.

Licence, releases and who maintains the branch

The licence is EPL-2.0, the Eclipse Public License 2.0, and the repository has a LICENSE file and a NOTICE.md. For a Java framework with plugin boundaries, EPL is a reasonable choice, and it is worth noting for anyone who intends to modify and distribute.

The release history shows two maintained lines rather than one. The recent releases are KURA_5.6.2 on 2026-07-08, KURA_4.1.5 on 2025-12-17 and KURA_5.6.1 on 2025-12-09. The 5.6.x line is where current work lands, and the 4.1.5 release in December 2025 suggests the older line still receives maintenance releases for deployments that have not moved.

The repository is not archived and the last push was on 2026-10-22, so work is landing on the develop branch continuously.

The documentation structure is worth noting too, because it is split by audience. The user documentation is a generated site on GitHub Pages with installation instructions, web UI information and tutorials. The developer documentation is the GitHub wiki, described as covering the development and release model, guidelines on importing internal packages, creating new bundles, and development environment tips. The Docker documentation lives in the kura-metapackage repository. So the three things you need, install, use and extend, are three different places.

Editorial conclusion

Adopt Eclipse Kura if you are running a fleet of edge gateways, need sensor drivers, data flow configuration and cloud connectivity in one place, and can live with a Java 21 stack on the device. Do not adopt it for a single sensor or a hobby gateway, where the operational weight of a full framework is larger than the problem. Before you install, confirm your gateway architecture is covered by the APT repository or the target board installers, read the user documentation for the supported platforms, and plan around the fact that managing many Kura instances means adding Eclipse Kapua alongside it.

Frequently asked questions

Official sources

1. eclipse-kura/kura on GitHub
2. License: EPL-2.0
3. Project website
4. README
5. Releases