Environments
An environment is a fleet inside an organization, and the boundary everything else is isolated by. If you have used a platform with "projects" or "workspaces", this is that — with one twist worth knowing early: an environment is part of a charger's connection URL, so moving a charger between environments is a hardware reconfiguration, not a database update.
Why they exist#
You need somewhere to break things.
Charging hardware is unusually unforgiving of this. You cannot spin up a
charger to test against, you cannot roll one back, and mistakes are visible to
drivers standing in a car park. So the platform gives you separate fleets
inside one account: a staging environment with a couple of test units or
simulated chargers, and a prod environment with the real ones.
They also serve a second purpose that emerges later: scoping access. A
member with the user role reaches only the environments granted to them, so
an installer or a contractor can be given staging and nothing else.
What belongs to an environment#
Chargers, sites, circuits, transactions, meter values and the authorization registry — all of it. Nothing crosses the boundary.
What does not belong to an environment: members and billing. Those sit on the organization, one level up. A member is a member of the organization, and their environment access is a grant on top of that.
The default environment#
Creating an organization automatically creates an environment named prod
and marks it default. Exactly one environment is the default at any time.
The default is not special in any way except one, and it is the important one:
/ocpp/{org_slug}/{charge_point_id} → the default environment
/ocpp/{org_slug}/{env_slug}/{charge_point_id} → a named environment
A charger whose URL omits the environment segment lands in whichever environment is currently default. That is convenient, and it is also a trap: changing which environment is default silently changes where those chargers connect.
If you run more than one environment, put the environment slug in every charger's URL explicitly. The extra segment costs nothing and removes a class of surprise entirely.
Naming and slugs#
An environment has a name (free-form) and a slug (URL-safe, lowercase alphanumeric segments joined by hyphens, 1–63 characters).
Nothing is special-cased by name. prod is a convention, not a keyword —
behaviour is driven entirely by the default flag. You can rename prod to
production, or create qa, demo, customer-acme, whatever suits.
Slugs are unique within an organization, not globally. Two organizations
may both have a staging, which is why the organization slug always comes
first in a connection URL.
Charge point ids are per-environment too#
The same uniqueness rule applies one level down: a charge point id is unique within an environment, not globally.
This is deliberate and useful. It means you can run CP-01 in staging and
CP-01 in prod — the same station identity, the same firmware
configuration, differing only in the URL it dials. Testing a configuration
that then goes to production does not require renaming anything.
It also means a charge point id is never enough to identify a charger. Use the UUID for everything except the connection URL.
Price and time zones#
Two settings hang off an environment:
Price zone — an ENTSO-E bidding zone, given as an EIC code. This is what day-ahead electricity price forecasts are fetched against. Unset means no prices.
Time zone — an IANA name such as Europe/Stockholm. This is the zone an
operator reads this environment's timestamps in. It does not change how
timestamps are stored or returned by the API; those stay unambiguous.
Sites can override both. That matters when one environment spans countries: a Swedish depot and a German one sit in different bidding zones, and setting the zone per site is the only way to price either correctly.
How many should you have?#
Two, usually. One production fleet and one you can break.
Reasons to add more:
- A demo or sales environment, with simulated chargers that always behave.
- Per-customer environments, if you operate on behalf of several parties and want their data genuinely separated rather than filtered.
- A hardware-qualification environment, for testing new charger models before they go near a live site.
Reasons not to: environments are not a substitute for sites. If two depots belong to the same operation, they are two sites in one environment, not two environments. Splitting them means losing any cross-site view and duplicating every member grant.
Moving a charger between environments#
The short answer: you re-provision it.
A charger belongs to exactly one environment, and its environment is baked into the URL the station dials. So "moving" means provisioning it in the new environment, obtaining fresh credentials, and reconfiguring the station to point at the new URL — a visit to the hardware, or a remote configuration change if the station supports one.
Its history does not come with it. Transactions belong to the environment they happened in.
Plan for this rather than discovering it: decide where a charger lives before it is installed, and prefer explicit environment slugs in URLs so that decision is visible in the configuration rather than implied by a flag.
What to do next#
- Core concepts — everything an environment contains.