EVerest: the open source software stack for EV chargers

What is EVerest?

EVerest is an open source software stack for EV charging stations, hosted by LF Energy under the Apache 2.0 licence. It handles the full charging path: the low level control logic between charger and vehicle, ISO 15118 communication and Plug and Charge, OCPP to the operator backend, energy management across multiple connectors, and drivers for the power meters, power modules and isolation monitors inside the cabinet. It runs on Linux, usually built with Yocto.

That covers AC wallboxes, DC fast chargers, and the megawatt class hardware now being built for trucks.

The short version for anyone comparing options: EVerest is the part of your charger that is the same as everyone else's charger. The protocol handling, the state machines, the certification-critical timing behaviour. None of it differentiates your product, all of it has to be perfect, and every manufacturer that writes it from scratch pays for the same work twice.

Who owns EVerest

Nobody owns it, and that is the point.

EVerest sits inside LF Energy, part of the Linux Foundation, governed by a Technical Steering Committee. Pionix holds a seat on that committee alongside chargebyte, Qwello, and the U.S. Department of Energy's DriveElectric programme. Around twenty further organisations contribute, including ABB, Siemens, Tesla, and NREL.

Pionix initiated the project in 2020 and remains its largest contributor. We did not keep it. A stack that every manufacturer is expected to build on cannot be controlled by one supplier, because the moment it is, it stops being infrastructure and starts being a lock-in risk. Neutral governance is what makes the stack safe to adopt, and it is the reason a charger manufacturer can build on EVerest without betting the roadmap on Pionix continuing to exist.

Everything we write goes upstream. If you work with us and later decide to work with someone else, or with nobody, the code stays yours.

What is inside the stack

The current release is 2026.02. Highlights of what ships in it:

The OCPP 2.0.1 implementation has been certified by the Open Charge Alliance on multiple hardware platforms and is continuously tested against OCTT2. That matters more than it sounds. A protocol implementation that has passed the compliance tool on real hardware is a different object from one that has passed unit tests, and the gap between the two is usually discovered late, in an integration lab, with a launch date already announced.

Note for the record: the standalone libocpp repository was archived in April 2026 and now lives inside the main EVerest repository, so anyone pointing at old links should update them.

Why manufacturers move to an open stack

Three arguments, in the order they usually land.

The protocol treadmill never stops. OCPP 1.6 to 2.0.1 to 2.1. ISO 15118-2 to -20. Plug and Charge, then bidirectional charging, then megawatt charging. Each one is a multi-engineer, multi-quarter project, and none of them wins you a single customer, because your competitors are shipping the same standard on the same deadline. Shared implementation work is the only sane response to a shared obligation.

Certification cost scales with how much code is yours alone. Test campaigns are expensive, and repeat campaigns for the same protocol behaviour on slightly different firmware are the most expensive kind. A stack that has already been through OCA certification on other people's hardware starts you further along.

Buyers are asking harder questions. Charge point operators have been burned by chargers they could not update and vendors they could not replace. Open firmware changes that conversation, and the tender language in Europe and North America has started to reflect it. The U.S. Joint Office of Energy and Transportation adopting EVerest for interoperability work is a signal about where procurement is heading.

There is a counterargument worth stating plainly, because every engineering manager raises it: an open stack you do not understand is a liability, not an asset. Reading 200,000 lines of C++ under deadline pressure is nobody's plan. Which brings us to the honest part.

What open source gives you, and what it does not

Downloading EVerest gets you a charging stack that works. It does not get you a product.

What is still on your side of the line:

• Your hardware. Your power stage, your meter, your contactors, your relay board, your MCU. Drivers exist for a lot of hardware, not for yours specifically.
• Certification evidence. The stack has been certified on other platforms. Your platform is your platform, and the test campaign is yours to plan, book and pass.
• Safety logic on the microcontroller. The Linux side of a charger is not where safety-critical timing lives. That code is separate, it is small, and it is where certification risk concentrates.
• Ten years of maintenance. Chargers stay in the field for a decade or more. Somebody has to track CVEs, backport fixes, and keep a build reproducible in 2034. Under the EU Cyber Resilience Act, that somebody is legally you. Reporting obligations for actively exploited vulnerabilities apply from 11 September 2026, with the full obligations from 11 December 2027.
• A device backend. Provisioning, fleet updates, remote diagnostics. Not part of the charging stack, and not optional in production.
• Testing at fleet scale. One charger on a bench proves the firmware boots. It does not prove your backend survives 4,000 chargers reconnecting after an outage.

None of this is a criticism of open source. It is the same list you would face writing every line yourself, minus the protocol work. But it is why "we found it on GitHub" and "we shipped it" are separated by twelve to eighteen months for teams doing it alone, and why the teams that ship fastest are the ones that stop treating the stack as free software and start treating it as a supply chain decision.

EVerest in production

Zaptec shipped EVerest on the Zaptec Pro and then pushed it to the majority of their installed fleet over the air, across the Pro CC, MID, M&E and T2S variants, making it one of the most widely deployed AC charging platforms in Europe running an open stack. As their product owner put it: "A Zaptec Pro running EVerest is not the same product it was on the day it shipped, and a year from now, it will be better still."

Tritium uses EVerest in its DC fast charging products.

eloaded works with Pionix on software-defined charging infrastructure for high power sites.

chargebyte and PHYTEC ship EVerest on charge controller hardware and modules, which means a manufacturer choosing EVerest can choose between multiple controller suppliers rather than one.

The U.S. Joint Office of Energy and Transportation works with LF Energy on EVerest to advance charging interoperability nationally.

Three ways to start

Evaluate it yourself. The documentation is public, the simulation modules let you run a charging session without hardware, and the community calls are open. Cost: an engineer's afternoon.

Prototype on a reference design. Skip the blank page. Start from hardware and a build that already work, and find out what your product actually needs before committing to a schematic.

Bring us in on a programme. Certification deadline, protocol migration, a controller that needs porting, or a fleet that needs a maintenance story. This is where most conversations with us begin.