Cloud VEN vs On-Site VEN: Choosing Your OpenADR Deployment Model
One of the first decisions in any OpenADR project is where the VEN actually lives. The protocol is the same either way, but the deployment model — a Virtual End Node hosted in the cloud, or one installed on hardware at the site — shapes your cost, your time to deploy, how well it scales across a fleet, and, increasingly, whether you qualify for utility incentives. This guide compares the two honestly so you can pick the right one, and covers a recent California regulatory clarification that tilts the playing field toward cloud.
If you need a refresher on what a VEN does, start with our OpenADR overview. In short: the VEN is the client that receives demand response events and price signals from the utility's or aggregator's VTN, and hands them to whatever system actually controls the load.
On-site VEN
An on-site VEN runs on hardware at the customer's premises — embedded in an energy management system or building controller, or installed as a dedicated gateway that passes signals through to the BMS and end devices.
It suits large commercial and industrial sites, where the load controlled per location is high enough to justify the install and there's usually an energy manager or integrator already on site. Its strengths are local resilience and control: because the VEN and the response logic both live at the edge, the building can keep executing its curtailment strategy even if the wider network connection drops. For a single high-value site, that autonomy is often worth the hardware and commissioning cost.
The trade-offs are cost and scale. Every site needs hardware provisioned, certificates or credentials managed, and firmware kept current. That's manageable for a handful of large sites; it becomes a serious operational burden across hundreds or thousands of them.
Cloud VEN
A cloud VEN runs as a centralized service — on a device manufacturer's platform, a demand response aggregator's system, or a customer's own EMS — and represents many distributed sites or devices through a single registration with the VTN. The cloud platform receives the OpenADR signal once and fans the resulting control action out to all the devices behind it.
This is the dominant model for residential and small-to-medium commercial fleets: large numbers of relatively small loads, many of them on hardware too constrained to run a VEN of its own. It scales because the utility never has to deal with each device individually, and because most device manufacturers and aggregators already operate a cloud platform that controls their fleet — adding a VEN to that existing infrastructure is far cheaper than putting a certified VEN on every endpoint. New sites are onboarded in software rather than with a truck roll.
The trade-off is dependency: the response now relies on the cloud platform and its connection to the devices. For small, numerous loads that's an acceptable exchange for the scale and economics; for a single critical industrial process, on-site autonomy may still win.
How a cloud VEN reaches the equipment
A common misconception is that a cloud VEN removes hardware from the equation entirely. It doesn't. The cloud VEN speaks OpenADR upstream to the VTN, but something still has to act on the load downstream. In practice the cloud VEN dispatches to on-site control hardware — a thermostat, a controller, a gateway — and that downstream link can use whatever protocol the equipment already speaks. OpenADR is only required between the VTN and the VEN; below the VEN, it's your normal controls world.
This split is the key to the cloud model's flexibility, and as we'll see, it's exactly the distinction regulators have now made explicit.
Cloud VEN vs on-site VEN at a glance
| On-site VEN | Cloud VEN | |
|---|---|---|
| Where it runs | Hardware at the customer site (EMS, controller, gateway) | Centralized platform (manufacturer, aggregator, or customer EMS) |
| Best for | Large single C&I sites | Residential, SMB, and device fleets |
| Scaling | Per-site hardware and commissioning | Onboard new sites in software |
| Resilience | Runs locally even if the network drops | Depends on cloud-to-device connectivity |
| Cost profile | Higher per-site, hardware-led | Lower per-site, leverages existing platform |
| Certification burden | VEN certified at each site | One certified VEN at the cloud level |
Regulatory tailwind: California clarifies that cloud VENs qualify for incentives
For years, a grey area hung over the cloud model in California's Automated Demand Response (AutoDR) incentive programs: did a cloud-hosted VEN actually qualify a customer for the rebate, or did the OpenADR-capable device have to sit on site? PG&E and SCE had interpreted the rules differently, leaving integrators unsure.
A draft California Public Utilities Commission resolution — Resolution E-5453, scheduled for the Commission's July 2, 2026 voting meeting — resolves it. The resolution approves PG&E's and SCE's revised AutoDR Technology Incentive Program and clarifies the program's Cloud-Based Technology Provision. The practical effect, once the follow-up filings are in place:
- Cloud-level VENs explicitly qualify. A VEN may be located on site, or at the cloud level — a manufacturer app or portal, a demand response aggregator, or a customer EMS — provided it dispatches to on-site control hardware. The cloud model is squarely eligible for AutoDR incentives, not a workaround.
- On-site hardware no longer has to speak OpenADR for cloud projects. The VEN must use OpenADR (2.0a, 2.0b, or 3) to reach the on-site hardware, but that hardware itself is not required to communicate via OpenADR. SCE is aligning with PG&E and dropping the requirement that a customer's on-site controls be OpenADR-certified on cloud-based projects, because the OpenADR conversation only needs to happen at the aggregator or provider cloud level. SCE's change also extends cloud-based control incentive eligibility to customers at or above 200 kW.
- OpenADR 3 is now an accepted protocol. The resolution adds OpenADR 3 alongside 2.0a and 2.0b in the list of qualifying communication standards, recognising it as the current version.
The Commission framed this as a clarification of long-standing intent rather than a new policy, noting that cloud-level controls responding to an OpenADR signal at a centralized point were always meant to be allowed. For anyone building on the cloud model, that's a meaningful signal: the largest demand response incentive programs in the US are confirming the cloud VEN as a first-class, rebate-eligible architecture — and naming OpenADR 3 as a current standard in the same breath.
A note on timing: as of writing this is a draft resolution awaiting adoption at the July 2, 2026 meeting, after which PG&E and SCE have 60 days to file the implementing advice letters. Confirm the final adopted language before relying on it for a specific project.
How to choose
For a single large industrial or commercial site where local autonomy matters and there's already controls hardware and an integrator on site, an on-site VEN is often the cleaner fit. For a fleet of smaller sites or devices — residential, SMB, EV chargers, distributed storage — or anywhere you need to onboard customers quickly and cheaply, a cloud VEN almost always wins on economics and scale, and is increasingly the model utility programs are built around.
Many real deployments end up hybrid: a cloud VEN handling registration and grid communication, dispatching to whatever on-site hardware each customer happens to have. The right answer is rarely ideological — it's about how much load sits behind each VEN and how much autonomy that load needs.
Frequently asked questions
What's the difference between a cloud VEN and an on-site VEN? An on-site VEN runs on hardware at the customer's premises; a cloud VEN runs on a centralized platform and represents many sites or devices through one registration. Both speak OpenADR to the VTN — the difference is where the VEN lives and how the response reaches the equipment.
Does a cloud VEN still need hardware at the site? Yes. The cloud VEN handles the OpenADR conversation with the grid, but it dispatches to on-site control hardware to actually act on the load. That downstream hardware doesn't have to speak OpenADR — it can use whatever protocol it already supports.
Can a cloud VEN qualify for utility demand response incentives? In California, a draft 2026 CPUC resolution clarifies that cloud-level VENs are eligible for PG&E and SCE AutoDR incentives, and that on-site hardware on cloud-based projects need not be OpenADR-certified. Eligibility rules vary by program and jurisdiction, so always confirm against the specific program.
Which model scales better? The cloud VEN, by a wide margin, for large numbers of smaller loads — new sites are onboarded in software rather than with per-site hardware. On-site VENs make more sense for a small number of large, high-value sites.