Cloud API vs Self-Hosted: how energy groups choose a device-data integration architecture
Data residency, credential management, compliance, SLA boundary — five procurement dimensions decide the deployment model, plus Cloud → Self-Hosted migration path.
A major state-owned energy company finished a Cloud PoC, and in the final week of procurement reversed the direction to Self-Hosted.
The turning point wasn't technical. Legal asked "where are the tokens kept?", security asked "does data leave the network?", IT asked "how does this plug into our group IDaaS?". Three questions in, the Cloud option was off the table.
Technically Cloud could have served that PoC. But once the conversation lands in the procurement committee, "does it run" stops being the question.
This piece is the postmortem on three years of helping different customer profiles walk through the Cloud vs Self-Hosted choice. The conclusion: this is a procurement question, not a technical one.
It's a procurement question, not a technical one
Cloud and Self-Hosted are functionally equivalent — same vendor integrations, same unified schema, same delivery channels. Anything that runs on one runs on the other.
What actually decides which model fits is these five procurement dimensions:
- Can data leave your network? — SOEs, state-owned utilities, government energy platforms, and large groups have hard compliance boundaries
- Who holds the credentials? — can your security team accept a third party holding vendor API tokens?
- What does your network and security architecture look like? — do you have internal bastions, CMDB, dedicated lines?
- Who handles long-term maintenance? — API revisions, security patches, scaling — SLA responsibility sits where?
- What's the SLA boundary? — when something breaks, who's responsible, and how is liability defined?
These five don't decide "can it work" — they decide "does it fit this company."
Architecture comparison
The diagram below shows the data flow difference between the two deployment modes:
Note the dashed box on the right — that's your network perimeter. In Self-Hosted mode, all data flow paths stay inside that boundary. In Cloud mode, data passes through ZenovaConnect infrastructure.
Both modes run the same software. The difference is where it runs.
Who Cloud fits
| Dimension | Cloud profile |
|---|---|
| Time to first data | Request API key → hours |
| PoC validation | Suitable (2–4 weeks for vendor coverage + schema + delivery validation) |
| Device scale | Best under 10K devices |
| Data residency | Data passes through ZenovaConnect infrastructure |
| Credential custody | ZenovaConnect holds |
| SLA | 99.5% / 99.9% (Pro) |
| Operations cost | We carry it, you don't need an ops team |
Three customer profiles most often pick Cloud:
- Energy SaaS teams — product scale under 10K devices, Cloud's per-device subscription is more economical than running it yourself
- All customers in PoC phase — fast validation of vendor coverage, unified schema, delivery pipeline. Decide later whether to switch to Self-Hosted
- Customers whose compliance allows data egress — in Cloud mode, device data passes through ZenovaConnect infrastructure, then gets pushed to your Webhook / Kafka / MQTT
The real advantage of Cloud isn't just convenience — more importantly, long-term maintenance responsibility stays with ZenovaConnect. API revisions, security patches, scaling, new vendor integrations — the customer doesn't manage any of it.
Who Self-Hosted fits
| Dimension | Self-Hosted profile |
|---|---|
| Time to first data | Deployment assessment + implementation = 4–8 weeks |
| PoC validation | Not suitable (private deployment PoC takes too long) |
| Device scale | Any scale, cost advantage emerges at 10K+ devices |
| Data residency | Stays fully inside your network |
| Credential custody | Customer holds |
| SLA | Negotiated, typically tied to customer infrastructure |
| Compliance | MLPS 2.0 Level 3 / domestic crypto compatible |
Four customer profiles need Self-Hosted:
- Data residency — SOEs, state-owned utilities, government energy platforms, some large groups explicitly require that device data not flow outside the company network. Self-Hosted runs inside the customer IDC or private cloud, with all data flow staying inside the customer perimeter
- Internal network / group architecture — customer has a unified intranet, bastions, CMDB, dedicated lines. Self-Hosted plugs into those existing systems more naturally than Cloud
- Compliance / domestic crypto / audit — scenarios requiring MLPS 2.0 Level 3, cryptographic law compliance, or domestic crypto algorithm support. Self-Hosted keeps data flow entirely inside the customer compliance perimeter, with direct audit access
- Group identity — customer has unified identity (IDaaS, SSO, group OA integration). Self-Hosted integrates more naturally
The real cost of Self-Hosted isn't deployment itself — it's that long-term maintenance responsibility partially shifts to the customer's ops team. Next section breaks down the responsibility boundary.
Responsibility boundary
The biggest difference between the two modes isn't function — it's responsibility allocation.
| Item | Cloud | Self-Hosted |
|---|---|---|
| Vendor API credential custody | ZenovaConnect | Customer |
| Upstream API revision tracking | ZenovaConnect | ZenovaConnect ships upgrades, customer schedules deployment |
| SLA | 99.5% / 99.9% (Pro) | Negotiated, typically tied to customer infrastructure |
| Data backup | ZenovaConnect | Customer |
| Security patches | ZenovaConnect pushes | Customer schedules deployment window |
| Upgrade cadence | Continuous (canary) | Customer decides upgrade timing |
| Incident debugging | ZenovaConnect | Joint, with logs on customer side |
Note "customer decides upgrade timing" — this is an advantage for group customers (they can schedule it in their change windows) but a burden for small customers (someone has to own the upgrade schedule).
Migration path: Cloud pilot to Self-Hosted
We recommend large customers start with a Cloud pilot, validating these four things in 2–3 months:
- Are all needed vendors covered?
- Does the unified schema fit your product?
- Do the delivery channels (Webhook / Kafka / MQTT) integrate with your downstream systems?
- Do critical scenarios — alarms, historical backfill, downlink control — behave as expected?
Once validated, if you decide to go private, we provide:
- Deployment assessment — network, capacity, dependencies, integration points with existing group IT
- Deployment delivery — 4–8 weeks (including training)
- Operations documentation for the customer ops team
- Annual maintenance + upgrade support
- SLA package (optional)
The advantage of this migration path: use Cloud to absorb the uncertainty first (product, engineering, business layer), then enter private deployment with a known approach. All adaptation work from the Cloud pilot carries over to Self-Hosted — no duplication.
One line
Don't pick "Self-Hosted vs Cloud" first. Pick the answers to these three questions first:
- Can my data leave the network?
- Do my engineers have time to operate this?
- Who should carry the SLA liability?
Once those three are clear, the deployment model is decided.