cloudparts

EdgeX Foundry

A set of microservices for an edge gateway that talk to devices in their own protocols, such as Modbus, BACnet or OPC UA, turn every reading into a common event, and pass it on to rules, local apps or the cloud.

LF Edge · Impact
What it is
IoT device messaging
Type
Open source
Made by
LF Edge (Linux Foundation), started at Dell
Foundation
LF Edge, impact, joined January 2019. A Linux Foundation project since April 2017; one of LF Edge’s five founding projects. Part of the Linux Foundation
License
Apache 2.0
Facts checked
28 October 2026
Website Source code

What it is

Factories and buildings are full of equipment that speaks old field protocols over serial lines and local networks, not MQTT to the cloud. EdgeX Foundry runs on a gateway or industrial PC next to that equipment. On the south side, device services act as connectors, one per protocol: the project maintains services for Modbus, BACnet, OPC UA, Siemens S7, SNMP, GPIO, USB cameras, MQTT, REST and more, with SDKs in Go and C for writing others. Each device is described by a device profile, a YAML or JSON file that lists its resources (a temperature, a switch, a register) with types and read/write rights, and the commands built from them. Core Metadata keeps the profiles and the list of devices, Core Command turns a REST call into a read or write on a real device, and Core Data can store what devices send.

Readings travel as events on the EdgeX message bus, which is MQTT by default since version 4.0. On the north side, application services subscribe to events, filter and transform them in a pipeline of functions and send them on to a cloud service, a database or an enterprise system; they are written with SDKs in Go or, since 4.0, Python, or configured without code. The docs list the eKuiper rules engine among the supporting services, next to a scheduler and notifications. All the pieces are separate services, normally run as Docker containers, and the recommended minimum is 1 GB of memory and 3 GB of disk; the community supports amd64 and arm64.

EdgeX 4.0 “Odesa”, released in March 2025, is the third long-term support release, supported until March 2027; patches 4.0.1 and 4.0.2 followed. It replaced components whose licences had moved away from Apache-2.0-compatible terms: PostgreSQL became the default database instead of Redis, OpenBao replaced HashiCorp Vault as the secret store, and the project’s own Core Keeper replaced Consul for configuration and service registry.

Why teams pick it

  • Connectors for many industrial and building protocols out of the box, so old equipment can feed modern systems without new firmware
  • Device profiles separate what a device offers from how it is wired, so apps read Temperature instead of a Modbus register address
  • Vendor-neutral, Apache 2.0 and an LF Edge Impact-stage project, with long-term support releases that last two years
  • Each service can be replaced or extended, and app services can send data to any cloud rather than one provider’s IoT platform

Watch out for

  • Many moving parts for one gateway: a message bus, a database, a secret store, a registry and a dozen services to run, secure and upgrade
  • Only amd64 and arm64 are supported; small 32-bit Arm boards need self-built binaries, and the minimum is a 1 GB machine, not a microcontroller
  • Data is kept on the gateway itself, so retention needs disk: the docs recommend about 32 GB to start, depending on how long readings are kept
  • The LTS policy covers the core services and SDKs, but not the reference device services, the GUI or third-party components such as PostgreSQL and OpenBao

Alternatives

What all iot device messaging have in common →Compare side by side →
Thinger.ioCommercialAn IoT platform where devices keep a connection open to the server and expose named resources that the server reads, writes and stores, with dashboards, data buckets and an MQTT broker built in.AWS IoT CoreAWSAWS’s managed MQTT broker for devices, with per-device certificates, a SQL rules engine that routes messages into AWS services, and cloud-side device state.Azure IoT HubAzureAzure’s device gateway: a registry of device identities, telemetry into an Event Hubs-compatible stream, and device twins, direct methods and cloud-to-device messages, sold in fixed-price units with a daily message quota.Eclipse ZenohIncubatingOpen sourceA pub/sub, query and storage protocol that runs peer to peer or through routers, from microcontrollers to the cloud; also a ROS 2 middleware.EMQXCommercialAn Erlang MQTT broker built for very large device fleets, with a SQL rule engine, now under the Business Source License.HiveMQCommercialA Java MQTT broker built for clusters, sold as self-managed software or as HiveMQ Cloud, with an open-source single-node edition.MQTTOpen sourceThe small publish/subscribe protocol most IoT devices use to talk to a broker, standardised by OASIS and ISO.ZephyrOpen sourceA real-time operating system for microcontrollers: the firmware on the sensor, wearable or controller at the edge of an IoT system, with its own networking, Bluetooth and MQTT client, built for more than 1,000 boards.

How it fits with other technologies

Part of a device profile for an air-conditioning bridge on Modbus · yaml

name: "Test-Device-Modbus-Profile"
manufacturer: "Cool Automation"
model: "CoolMasterNet"
deviceResources:
-
  name: "SwitchA"
  isHidden: true
  description: "On/Off , 0-OFF 1-ON"
  attributes:
    { primaryTable: "COILS", startingAddress: 0 }
  properties:
    valueType: "Bool"
    readWrite: "RW"
deviceCommands:
-
  name: "Switch"
  readWrite: "RW"
  isHidden: false
  resourceOperations:
    - { deviceResource: "SwitchA", mappings: {"true":"ON","false":"OFF"} }

See it in a real stack

No architecture uses EdgeX Foundry yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2017–2026

Industrial IoT in the mid-2010s was a patchwork: every gateway vendor and cloud platform had its own way of talking to sensors and machines, and integrators wrote the same protocol glue again for each project. Dell had built IoT gateway software of its own under the name FUSE, and offered it as the seed of a shared, vendor-neutral middle layer instead.

On April 24, 2017 the Linux Foundation launched EdgeX Foundry with Dell’s FUSE code, more than a dozen microservices and over 125,000 lines under Apache 2.0, and about 50 founding members, among them AMD, Canonical, Linaro and VMware. Releases are named after places in alphabetical order, and 1.0 was tagged in June 2019. In January 2019 EdgeX became one of the five founding projects of LF Edge, where it later reached the Impact stage.

Major versions followed in 2021 (2.0) and 2023 (3.0 “Minnesota”). For 4.0 “Odesa” in March 2025 it swapped out Redis, Vault and Consul after their licences changed, making PostgreSQL, OpenBao and its own Core Keeper the defaults.

Why it’s built this way

Microservices instead of one gateway program
Each protocol connector, data service and export service runs in its own process, so a vendor can replace one part, or write it in another language, without forking the rest.
Device profiles as data
Describing devices in YAML or JSON lets a new model of sensor be added by writing a file rather than code, and gives northbound apps the same names whatever the protocol.
Only Apache-2.0-compatible dependencies
When Redis, Vault and Consul moved to source-available licences, EdgeX replaced them in 4.0 so that the whole default stack stayed open source.

Timeline

  1. 2017

    EdgeX Foundry launched at the Linux Foundation on April 24 with Dell’s FUSE code

  2. 2019

    Becomes a founding LF Edge project in January; 1.0 tagged in June

  3. 2021

    2.0 tagged in June

  4. 2023

    3.0 “Minnesota” in May, 3.1 “Napa” LTS in November

  5. 2025

    4.0 “Odesa” LTS in March: PostgreSQL, OpenBao, Core Keeper and an MQTT message bus by default

  6. 2026

    4.0.2 patch release in May

Sources11 · facts checked 28 October 2026

Improve this page on GitHub