Codibly CPMS Engine

Build your network. Own your platform.

A production-ready charge point management system, handed over with its source code. White-label CPO software you license once, customize without asking permission, and run on infrastructure you control.

Codibly CPMS Engine operator console showing network-wide EVSE status, live charging sessions, energy delivered and protocol connectivity

Who it’s for

Three buyers, one core

The Engine is the same codebase whichever of these you are. What changes is the shape of the customization and the size of the license. That is why the first conversation is a scoping session rather than a price list.

ev_station

Charge point operators outgrowing SaaS

You launched on a rented platform and it did its job. Now the per-charge-point line grows every time the network does, the roadmap you need sits behind someone else’s backlog, and the features that would differentiate you are the ones the vendor will not build.

bolt

Utilities and energy groups

Charging is one asset class inside a much larger energy business, and it has to answer to the same standards as the rest of it: data residency, security review, integration with systems that predate the EV program by decades. A platform you own is a platform your architects can sign off.

directions_car_filled

Fleets and fuel retailers moving into charging

Depot charging, forecourt charging and a loyalty relationship you already own. The commercial logic is yours and unusual, and a multi-tenant schema built for public networks will not hold it.

Aerial view of EV charging canopies at night, with luminous arcs of data rising from each charger

The choice

There is a third way to own the charging software

There are two usual ways to get charge point management software. Renting is genuinely the fastest route to a live network and the cheapest to start; that is not a concession, it is the reason most operators begin there. Building in-house gives you everything you want, and takes twelve to twenty-four months to give you any of it. The third position is the one this page sells: a proven core, customized to your business, handed over with the code. We argue the whole decision, from cost structure and ownership through to roadmap control and exit, on a page of its own.

The argument

What ownership actually changes

Ten things that are true of a platform you own and not of one you rent. None of them is a feature; all of them are consequences of where the code lives.

code

You own the code, not just the license

Full source-code ownership means no vendor can raise your price, change your terms, or retire a feature you have built a business process around.

paid

No per-charge-point or per-transaction fees

Cost stays largely fixed after the build instead of scaling with the network’s growth. Growth stops being a line item that punishes you.

account_tree

Freedom from a vendor’s roadmap

Your team, or ours under a support agreement, extends the platform on your timeline. You stop competing with other customers for a feature request.

hub

Protocol compliance from day one

OCPP and OCPI come pre-integrated and production-proven, so budget goes to what differentiates you rather than to rebuilding interoperability that already exists.

shield_locked

Full data ownership and portability

Charging, energy and customer data live in infrastructure you control. That is what makes a data-residency answer possible, and it removes migration risk entirely.

savings

Lower long-term TCO, even after the build

Past a moderate network size the multi-year cost curve is flatter than a subscription’s. Up to 70% below a full custom build to get there, because the core already exists and is already tested.

layers

Customizable to your commercial model

Shaped around your actual business logic, whether that is a public network, a depot fleet or a utility program, rather than a generic multi-tenant schema that fits everyone approximately.

bolt

A foundation, not a black box

Adding DER orchestration, V2G or smart charging later does not need a vendor’s sign-off or a custom-integration fee. The extension point is yours.

security

Less exposure to someone else’s business risk

If a platform vendor is acquired, pivots or shuts down, an owned codebase insulates you from a decision you had no part in.

support_agent

Expert support without a dependency

Codibly can carry ongoing development. That is a choice you make each year, not a structural requirement for keeping the platform running.

  • OCPP charge-point connectivity: standards-based communication with multi-vendor chargers
  • Charger configuration management: central onboarding, parameter configuration and lifecycle control of every station and connector
  • Asset and location administration: registration and maintenance of sites, stations, connectors and location metadata
  • Remote session control: start, stop and reset triggered remotely, across RFID, ad-hoc, external-app and terminal-initiated sessions
  • Firmware update orchestration: remote rollout of firmware packages to chargers and their components

More on how we approach this layer in CSMS/CPMS development.

  • Real-time monitoring and diagnostics: live status, health metrics and fault codes with near-real-time refresh
  • Error and service alert handling: capture, classification and presentation of technical alarms and maintenance alerts
  • Maintenance dashboard: charger health and anomalies in one view, including failed authorizations, abnormal session patterns and low-availability alerts
  • Tariff and pricing assignment: tariffs or price profiles per connector, time window or partner
  • Session data and charge detail records: full session metrics captured for billing, settlement and analytics
  • CDR and billing correction management: recalculate against updated tariff patterns and re-issue corrected invoices
  • Invoicing module: automated invoice generation from your own templates
  • Hubject / OICP integration: bidirectional interoperability with the Hubject network for roaming and partner sessions
  • Sub-CPO and sub-MSP management: delegated operational roles and reporting access for sub-operators and mobility service providers
  • Regulatory and data feeds: automated export of required data sets, such as infrastructure registry and location feeds, to external systems

The roaming layer is covered in more depth under OCPI and OICP interoperability.

  • Authentication and token management: RFID tokens and other identifiers handled for session authorization
  • Anti-fraud module: detects token cloning and “teleporting” sessions, with automatic blocking of drivers and tokens
  • Web portal access: drivers start sessions from a web portal with location search on a station map
  • Operational dashboard: active stations, sessions in progress and utilization rates as a live KPI view
  • Reporting and analytics: scheduled and on-demand diagnostic, operational and partner reports
  • Bidirectional charging (V2G): control of bidirectional energy flow through compliant chargers

Interoperability

Owned, and open

Ownership is worth nothing if the platform only talks to itself. The Engine ships with the protocol layers already built and already proven in delivery, which is the half of the build that usually consumes a certification budget.

hub

OCPP 1.6J and 2.0.1

Full backend support for both, hardware-agnostic across the major charger vendors. Smart charging and the device model come with 2.0.1. More on our approach in OCPP implementation.

compare_arrows

OCPI and OICP roaming

OCPI 2.1.1 and 2.2.1 for CPO-to-eMSP interoperability and multi-country operation through one API, plus OICP for Hubject roaming. The same layers sit under the eMSP Engine on the other side of the transaction.

ev_charger

ISO 15118 Plug & Charge

Plug & Charge through Hubject, so a driver authenticates by plugging in and your authorization flow does not depend on an app being open.

Delivery

From workshop to handover

Weeks, not quarters, because roughly 80% of what a CPMS needs already exists, is already tested and is already carrying load elsewhere. The variable is customization depth, and that is what the first phase exists to establish. Nobody can quote you a date before it.

edit_document

Scope

  • Requirement workshops with your team: operations, billing, security, whoever will own it afterwards
  • Scope agreement, with delivery costed against it rather than against a template
  • Milestones and contract agreed before anyone writes code
code_blocks

Build

  • The Engine core is deployed into your cloud on Docker, Terraform and Kubernetes, cloud-agnostic and Azure-compatible
  • Customization built against the scope: your commercial logic, your integrations, your brand
  • Testing against real chargers, not only against a simulator
chip_extraction

Migrate and transfer

  • Migration from the incumbent platform, including the session and CDR history you are entitled to take
  • Documentation, architecture guides, training and knowledge-transfer workshops
  • Handover of the codebase, the infrastructure and the operational knowledge, or a staged Build-Operate-Transfer engagement if you want us to run it first

After handover

Who runs it afterwards is your call

Two routes, and we are genuinely indifferent between them. Either way you own the platform; the only question is whose people operate it.

engineering

Run it yourself

Your team takes the platform and operates it. That is what the handover is designed to make possible, and it is the route that makes the ownership argument literal rather than rhetorical.

support_agent

Have us run it

Codibly maintains it under contract: health checks, security patches, performance monitoring and preventative maintenance. You still own the code; you have simply chosen not to staff for it.

library_add

What handover includes, either way

Technical documentation, system architecture and operational guides, team training sessions and knowledge-transfer workshops. Ad-hoc support and future enhancements are scoped per request rather than bundled into a retainer you may not need.

How pricing works

A one-time license, tiered to the size of your company and your network. No per-charge-point fee, no per-transaction fee, no revenue share — the things that make a rented platform more expensive every year you succeed. Customization is scoped and priced separately, after the workshop that defines it, because pricing it before then would be a guess dressed as a quote. What that comes to for a network your size is a conversation.

For the buying committee

Take it to your team

Owning your charging platform is a decision your finance, procurement, security and engineering colleagues all have a stake in. Four short briefs, each answering their questions directly, so you can forward one rather than translate the whole case.

paid

For the CFO

The capital-versus-operating case, honestly drawn: where an owned platform is more expensive in year one, and where the curves cross. Includes what “no per-charge-point fee” is worth against a network plan, and what is genuinely still recurring.

handshake

For procurement

Ownership and exit in contractual terms: what transfers at handover, what Build-Operate-Transfer commits both sides to, what happens if you want to leave, and what happens if we do.

security

For the CISO

Where the data lives and who can reach it: your infrastructure, role-based access control, SIEM integration, encrypted tokens, and the review artifacts your security function will ask for before sign-off.

integration_instructions

For the technical lead

The capability set, the protocol versions, the stack you inherit (Docker, Terraform, Kubernetes), and an honest account of what customization on top of the core actually involves.

Delivery in progress

One core, three enterprise programs

The same Engine core sits under charging platforms for a European energy group, a Gulf charging network and a global carmaker: three very different businesses, three very different builds. Anonymized at each client’s request.

public

A major Central European energy corporation

Codibly is building the CPMS platform on its Engine for one of the region’s largest integrated energy groups.

hub

A Gulf-region charge point operator

The same core is in delivery for a charge point operator scaling a national network.

directions_car_filled

A global automotive OEM

An OEM-grade charging management platform, built on the same core.

Case studies

Named work from the same practice

Published projects where the client agreed to be named, drawn from the same e-mobility delivery record.

Frequently asked questions

You own it. The Engine is delivered as a one-time perpetual license with full source-code ownership. The customized codebase is yours to modify, extend, fork or hand to another supplier. There is no clause that returns it to us, and no runtime dependency on anything we host.

The commercial logic is the point of customization: tariff structures, roaming arrangements, fleet and depot models, loyalty mechanics, branding, and the integrations into whatever you already run. The protocol layers and the core data model are what you are licensing precisely so you do not have to build them, though once the code is yours, even those are yours to change.

That is standard scope rather than an exception. CRM, ERP, billing, identity, BI, and the energy-side systems a utility already operates are all integrations we build against the scope agreed in the first workshop. The platform runs in your cloud, which is usually what makes the awkward integrations possible at all.

Your side of the work is requirements, systems access, and decisions: a product owner who can settle commercial logic, someone from billing, someone from security for review, and an integration contact per connected system. The commitment is heaviest in the scoping phase and during migration testing, and lightest through the build. The exact shape is one of the things the scoping session establishes, because it depends far more on how many systems you are connecting than on how large the network is.

Whichever you prefer. Your team can run it: the documentation, architecture guides, training and knowledge-transfer workshops exist to make that a real option rather than a theoretical one. Or Codibly maintains it under contract, covering health checks, security patches, performance monitoring and preventative maintenance. Both are normal, and neither changes who owns the platform.

OCPP 1.6J and OCPP 2.0.1, both as full backend implementations, hardware-agnostic across the major charger vendors. Roaming runs on OCPI 2.1.1 and 2.2.1 with OICP for Hubject, and Plug & Charge is supported through ISO 15118.

Nothing happens. That is the whole argument. You are holding the source code, running it on your own infrastructure, with your data in your own database. There is no migration project, because there is nothing to migrate away from. The platform is already where it would be migrating to.

Contact us

Bring us the network you actually have

Not a demo of a generic platform, and not a discovery call that turns into a pitch. A scoping session: what you run today, what it costs you, what you would build if the roadmap were yours, and what the Engine would have to become to get you there.