SteVe is the Java OCPP server that most charge point operators start from

A university project that became the reference implementation

SteVe is an OCPP server implementation in Java, and the project's description calls it a trusted open source EV charging station management system since 2013, used by charge point operators, manufacturers and developers worldwide.

The history is in the readme. SteVe started its life at the RWTH Aachen University in 2013, and the name is derived from Steckdosenverwaltung in German, which in English is socket administration. The stated aim is to support the deployment and popularity of electric mobility, so it is easy to install and to use, and it provides basic functions for the administration of charge points, user data and RFID cards for user authentication, and was tested successfully in operation.

The second half of the mission is what makes the project interesting to researchers. SteVe is considered an open platform to implement, test and evaluate novel ideas for electric mobility, like authentication protocols, reservation mechanisms for charge points, and business models for electric mobility. So it is a working server that you can point a charger at, and a testbed for ideas that do not have a market yet.

The licence is GPL and it is free to use, and the readme even offers a logo for anyone deploying it, on the assumption that a charge point running SteVe should say so.

The current releases are 3.13.0 from 2026-05-25, 3.14.0 from 2026-07-28 and 3.14.1 from 2026-08-12, and the last push was on 2026-10-11 with the repository not archived.

Six OCPP versions, and routing by version

The supported charge point protocols are listed as OCPP 1.2S, OCPP 1.2J, OCPP 1.5S, OCPP 1.5J, OCPP 1.6S and OCPP 1.6J, the last of which includes the security extensions, with a link to the project's wiki page on the OCPP 1.6J security configuration.

The S and J suffixes are the SOAP and JSON flavours of the protocol, and the pairing matters more than it looks. A charge point speaks one of them, and the readme explains that the charge points must be configured to communicate with specific addresses, and that depending on the OCPP version of the charge point, SteVe will automatically route messages to the version specific implementation. So the same server accepts several protocol versions and dispatches internally, and a deployment does not need a separate instance per version.

Two endpoints do that work. The SOAP one is at the CentralSystemService path, and the WebSocket and JSON one is at the websocket path with the same service name. Both are relative to the application's context, so the full addresses take the form of the server address and port followed by the application path and the service name.

For a hardware team, the compatibility page in the project wiki is the more useful document than the version list, because the question is never only which protocol version a charger speaks but whether its particular firmware implements the operations the server expects.

The registration step is also protocol independent. A charge point must first be registered before SteVe will accept messages from it, and you add it under Data Management, then Charge Points, then Add, entering the ChargeBox ID configured in the charge point. As soon as a heartbeat is received, the status of the charge point appears in the SteVe dashboard, which is the point at which you know the wiring is right.

The certification applies to the hosted backend, not to your build

The readme carries a notice about certification, and the precision in it is the point.

Powerfill's OCPP backend has received Open Charge Alliance certification for OCPP 1.6 Core, plus C for Smart Charging, plus S for Advanced Security. Powerfill incorporates SteVe's OCPP protocol implementation without modifying its logic or behavior, and the consequence drawn from that is that SteVe's OCPP implementation has therefore been independently validated through its integration into the certified Powerfill backend.

And then the caveat, which is the sentence that matters for anyone deploying the open source project themselves: the certificate formally applies only to the certified Powerfill backend and version, not to SteVe as a standalone, open source distribution, or to other SteVe builds and deployments.

That is a well drawn line, and it is worth reading carefully because the claim is easy to over-read. The protocol implementation that SteVe contributes has been through a third party certification process, which is real evidence about its correctness. It is not a certification of your instance, of your configuration, of your version, or of anything you have changed.

The wider relationship is described in the readme. Powerfill is a SaaS company to expand beyond the basics of SteVe, and while SteVe covers the basics of OCPP functionality in a DIY sense, Powerfill offers more and enterprise features with ease of use, with links to the company announcement and the public launch post.

So the two projects are related but distinct, and the practical question for a reader is whether you want the self hosted core or the managed service. The homepage of the repository points at the commercial product, so the open source project and the company are closely linked even though the code and the licence remain separate.

Building and running it, in seven steps

The installation instructions are explicit, and the first step is the one people get wrong.

Before anything else, the time zone of the MySQL server has to match the time zone of SteVe, and since UTC is strongly recommended by OCPP it is the default in SteVe, so you should set it in MySQL accordingly. MySQL also has to be reachable over TCP, which means removing skip-networking from the configuration if it is there. The database itself is created with these statements, adjusting the name and the credentials:

CREATE DATABASE stevedb CHARACTER SET utf8 COLLATE utf8_unicode_ci;
CREATE USER 'steve'@'localhost' IDENTIFIED BY 'changeme';
GRANT ALL PRIVILEGES ON stevedb.* TO 'steve'@'localhost';

Then you download and extract a release tarball, configure the application before you build, and build with Maven, which produces a runnable war file in the target directory:

# ./mvnw package -Pprod,mysql

with a profile for MariaDB instead if that is your database. The application is started as a war, and the readme asks you not to run it as root:

# java -jar target/steve.war

SteVe is designed to run standalone in a Java servlet container or web server such as Apache Tomcat, and a servlet container is not required to run it.

The system requirements are JDK 25 or newer, Maven, and MySQL or MariaDB with a supported version. The web interface is then reached at the manager path under the application's context, and the readme closes with a short Have fun.

That is a complete deployment in a page, and the requirement list tells you what kind of project this is: a long running Java service with a database, a configuration file you must edit before the build, and a single artefact to deploy.

Docker, and the trick that waits for the database

The Docker path exists for people who would rather not run the seven steps, and the readme says you can skip steps one, four and five in favour of it, with one caveat.

The caveat is that the compose file builds the project for you, so you still have to change the configuration, but in a different file: rather than the production properties file, you edit the Docker one, changing all the settings described in step three. That is a sensible arrangement, because the Docker image sets its own database host and credentials, and editing the production file would fight the image.

The compose file itself is small. There is a database service on a pinned MariaDB image with a volume for the data, a random root password, the time zone set to UTC to match the application's default, and the database name and credentials matching the SQL from the manual steps. The application service builds from the Dockerfile, links to the database, mounts the source into the container, and publishes the two ports the web interface and the OCPP endpoints use.

The Dockerfile shows the waiting problem being solved. The base is a Temurin JDK 25 image, and a small tool called dockerize is installed so that the web container will wait for MariaDB to start. The start command uses it to wait on the database port with a sixty second timeout, and only then builds the application with the Docker and MariaDB profiles and runs the war with a capped heap percentage. The TLS client protocol list is passed to the build as a system property, which is the kind of detail that matters when a Java client talks to an older server.

The repository also carries a k8s/ directory and an api-docs.json, which is the machine readable description of the API the project exposes, plus a checkstyle configuration and a PMD plugin configuration, so the code is held to a static analysis standard as well as to tests.

Editorial conclusion

SteVe suits a charge point operator, a hardware manufacturer or a developer who needs an OCPP backend to test a charger against, and it suits a university or research group that wants to experiment with electric mobility protocols. It is the wrong choice if you need the managed service, because that is what the separate Powerfill product is for, and a poor match if you expect the OCPP certification of the hosted backend to transfer to your own deployment, because the certificate applies only to the certified backend and version. Before deploying, set the database timezone to match the application, change the database, host and web interface settings in the properties file before you build, and check the charging station compatibility wiki for your hardware.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. steve-community/steve on GitHub