Once an enterprise decides to run EV charging under its own brand, a second question follows close behind: whose infrastructure does it run on? A white-label platform doesn't have to mean handing your charging business to someone else's servers - the same product can run as fully managed, inside your own cloud account, or entirely on-premise. Which one fits depends less on preference and more on who you are as a business.
The three models
| Managed cloud | Your cloud (BYOC) | On-premise | |
|---|---|---|---|
| Who operates it | The platform vendor, fully | The vendor, deployed into your AWS/Azure/GCP account | Your own team, in your own data center |
| Time to launch | Fastest - no infrastructure to provision | Slower - your cloud account, security review and networking setup add time | Slowest - hardware and data center readiness gate everything else |
| Data residency & control | In-country residency where the vendor supports it | Fully within your account, your region, your security policies | Fully within your physical infrastructure - air-gapped if required |
| Ongoing ops burden | None - fully managed | Low - vendor manages the platform, you own the cloud account/billing | Highest - your team handles infrastructure operations alongside the vendor |
| Cost structure | Predictable subscription, no infrastructure to budget separately | Subscription plus your own cloud spend | Subscription plus your own hardware, hosting and infrastructure staff |
| Typical fit | Most enterprises and CPOs launching a new branded network | Enterprises with existing cloud vendor agreements, security policies or billing consolidation requirements | Utilities and public-sector operators with sovereignty or grid-security mandates |
Why this doesn't have to mean three different products
The deployment model is an infrastructure decision, not a product decision - the same CSMS, tariffs and billing engine, and branded driver app run underneath all three, on the same release train. Choosing on-premise instead of managed cloud shouldn't mean losing features or falling behind on updates; it should mean the same platform, with a different party controlling where it physically runs.
Managed cloud: the default for a reason
For most enterprises and CPOs, managed cloud is the fastest and simplest path to a live network - there's no infrastructure to provision, secure or staff, and the vendor handles scaling, backups and high availability as part of the subscription. It's the right default unless something specific points elsewhere: a regulatory requirement, an existing cloud commitment, or a sovereignty mandate.
Bring-your-own-cloud: control without the operational load
BYOC deployments put the platform inside your own AWS, Azure, GCP or regional cloud account - useful when your organization already has security policies, procurement agreements or billing consolidation tied to a specific cloud provider, or when internal policy requires workloads to sit inside accounts your security team already audits. You still don't operate the platform day-to-day; you own the account it lives in.
On-premise: for sovereignty and grid-security mandates
On-premise deployment - including fully air-gapped environments - exists for organizations where that's not optional: utilities and public-sector operators subject to data sovereignty rules, or grid-security requirements that rule out any external network path. It's the slowest model to stand up and the highest ongoing operational burden, so it's worth confirming it's actually required before defaulting to it out of caution.
How to decide
- Is there a regulatory or sovereignty requirement? If yes, that likely settles it in favor of on-premise or a specific-region deployment - check this first, before comparing cost or speed.
- Do you have an existing cloud vendor relationship or security policy? That points toward BYOC, so charging infrastructure sits inside accounts your team already governs.
- Is speed to launch the priority? Managed cloud removes an entire workstream from the critical path - see the typical launch timeline for how much that matters.
- Who's actually available to operate infrastructure long-term? On-premise only makes sense if your team can staff that ongoing operational load - not just the initial setup.
See how deployment model fits into the rest of the platform on the platform page, or talk to us directly about your specific infrastructure requirements on the contact page.
Frequently asked questions
Can we switch deployment models later?
Migrating between deployment models is possible since it's the same underlying product, but it's still an infrastructure migration project - worth choosing deliberately upfront rather than planning to switch casually later.
Does on-premise mean we lose feature updates?
No - on-premise deployments run the same product and release train as managed cloud; updates are applied to your environment on an agreed schedule rather than automatically and continuously.
Is BYOC more expensive than managed cloud?
It adds your own cloud infrastructure spend on top of the platform subscription, which managed cloud bundles in - so total cost depends on your existing cloud pricing and usage, not a fixed premium.