Choosing a Deployment Model for Spatial Intelligence in Malaysia

Answer up front — The three spatial intelligence deployment models are hub-integrated (Studio pre-installed on Aqara gateway hardware), edge-deployed (Studio standalone on your own server) and cloud-hosted (Studio delivered by cloud, with no local hardware). The choice decides three things that cannot be changed cheaply after commissioning: where your data physically sits, whether the building can still switch its lights off during an internet outage, and who carries the operating load. For a Malaysian project the usual answer is edge-deployed for anything commercial or multi-tenant, hub-integrated for a single home or small pilot, and cloud-hosted for a provider running many sites from a small team. On the M300 specifically: it has not been listed as a Malaysian-channel product. Talk to us about availability and project fit rather than assuming it is on a shelf locally.

This is the decision post. Not what the platform does — that is covered in Aqara Studio explained — but which of the three ways of running it you should sign for, and what you take on when you do.

The reason this decision matters more in Malaysia than in many markets is that the commercial building stock here is overwhelmingly owner-occupied or long-held, the fit-out budget is decided once and lives for a decade, and nobody wants to sign a contract that quietly creates an operational obligation nobody budgeted for.

The three models side by side

The three questions the model actually decides

1. Where does your data live?

Occupancy, presence, space membership and automation logic are personal-data-adjacent in a building where people live, work or are cared for. Under Malaysia's PDPA, the questions a building owner will eventually be asked are: what is collected, where is it processed, who can reach it, and how long is it kept. The deployment model answers the "where is it processed" question before anyone asks it.

Edge-deployed and hub-integrated both keep it on site. That is the strongest position to be able to state in a document, and it is a materially easier conversation than explaining which overseas region your building's occupancy data sits in.

2. What happens when the internet goes out?

A Malaysian building should not lose the ability to switch its lights off because a fibre circuit is down, a TM upstream fault is in progress, or a provider is having an afternoon. This is not hypothetical — connectivity interruption is a normal operating condition, not an exception.

In a hub-integrated or edge-deployed deployment, the automation that turns a corridor light off at 11pm executes on hardware inside the building. Cloud connectivity adds remote access and fleet management on top; it is not in the critical path of the switch. In a cloud-hosted deployment, you are accepting a dependency on a link you do not control for a function you cannot tolerate losing.

For hotels, hospitals, care facilities and anything with a security function, this is not a trade-off you should be making at all. It is a requirement.

3. Who carries the operating load?

This is the question most often left off the table until after signature.

Edge-deployed buys you data locality, modularity and compliance posture. It pays for that with an operating obligation that has to sit in somebody's budget and somebody's calendar. If nobody at the building owns it, the system will work beautifully for three years and then quietly fail after an unattended firmware change.

Four Malaysian scenarios

A landed terrace retrofit

Single dwelling, existing construction, one family, no tenancy turnover. The decision is almost always hub-integrated, because there is no one to run a server and no commercial data question to answer. The only real constraint worth checking before you commit is the building itself — ceiling height, back-box depth and circuit capacity — which we cover in which smart home retrofit is realistic in Malaysia.

If the family wants a garage, a gate and a back garden zone as well, that is still the same model. Scale has not crossed a line.

A 200-unit condominium

Multiple owners, common areas, tenants arriving and leaving every few years, a management corporation that must control cost. Hub-integrated per unit and edge-deployed for common areas and the building system is the combination that usually holds up.

The reason is turnover. Every unit that changes hands needs the automation re-pointed, the access credentials reissued and the configuration reviewed by someone. That is an operational cost, and it belongs in the budget before the handover, not discovered at the second refit. Our posts on common areas, tenant space and who pays and integrating Aqara into condo property management set that out in more detail.

Data residency matters here more than anywhere else on this list. A condominium with 200 households on one edge server has an occupancy record for every unit in one place, and can answer the PDPA question in one sentence.

A hotel

Occupancy drives the whole business case, and occupancy is exactly what breaks when the link does. A guest room whose lighting and air-conditioning depend on a cloud round trip is a guest room that does not respond when the room is full and the internet is down.

Edge-deployed, with the operator's existing systems reachable locally. The hospitality case is developed in spatial intelligence for hotels and serviced apartments in Malaysia.

An office floor

Mixed use: some zones need to be conditioned all day, meeting rooms are empty most of the time, and the complaint from occupants is almost never "the lights are too dim" — it is "it is freezing" or "the room is too hot."

Edge-deployed is the right default, because the air-conditioning decisions need local response. Cloud-hosted is defensible here only if the tenant's priority is zero on-site hardware and they accept the dependency. Tenant turnover is the other factor — an office floor changes tenants more often than a condominium changes owners, so plan for reconfiguration. Our post on building a smart building business case covers the numbers side.

How to decide, in order

1. List what must keep working when the link does not. Anything on that list rules out a pure cloud dependency for that function.
2. Decide whether you can own an on-site server. If there is no named owner with time in their week, edge-deployed is a liability and you should say so rather than sell it.
3. Establish the data-residency position before the contract, not after. If occupancy data is involved, write down where it is processed.
4. Count the sites. One site, or a small number, is a technical decision. Many sites run by one team is an operating-model decision, and cloud-hosted becomes defensible.
5. Write the operating load into the scope — hardware, network, firmware, backup, turnover. The deployment model table above is the starting list, not the final one.

For how the platform behaves across larger rollouts, see rolling out smart devices at scale.

What this page does not claim

• It does not claim a confirmed Malaysian price or Malaysian stock for Aqara Studio, Studio Connect, the Edge Hub M300 or any Studio subscription or licensing.
• It does not claim the Edge Hub M300 can be bought in Malaysia. Aqara's documentation lists its sales regions as Chinese Mainland, North America, Europe and Russia.
• It does not state energy, cost or payback figures. Build those against your own tariff and occupancy profile — the approach is in building a smart building business case.
• It does not offer legal advice on PDPA. If your building processes personal data, take your own advice on what you are obliged to do.