A growing movement towards decentralised smart-home systems emphasizes local control to withstand internet disruptions, offering enhanced resilience and privacy amid rising cloud service outages.
The central lesson for smart-home builders is becoming harder to ignore: a connected home that depends on a remote cloud service can fail when the internet does. That is the argument advanced by Андрей Логинов, co-founder and technical director of CleverHome, in a piece published on Habr, where he sets out a third approach between fully cloud-based systems and ad hoc local integrations. His case is that a professionally designed platform can remain local in architecture while still being standardised enough to deploy across multiple buildings.
Recent outages have given that argument new force. On 20 October 2025, Amazon Web Services suffered a major disruption in its US-EAST-1 region, with Tom’s Hardware reporting that DNS problems affecting the DynamoDB API rippled through a wide range of services, from gaming platforms and communication tools to Amazon’s own Alexa and Ring products. TechRadar later reported that the outage also affected services relying on EC2 and that some backlogs took hours to clear. For smart-home users, the most visible consequences were not abstract errors but failed devices: reporting on Eight Sleep’s connected beds described units stuck in awkward positions or left heating uncontrollably, with no offline control available.
Logинов links those failures to a broader operational risk that is especially acute in Russia, where internet restrictions and shutdowns have become more frequent. He cites figures showing long periods of outage in several regions and notes that some mobile sessions in border areas have taken place under heavy constraints. His point is simple: if a home automation system is built around a cloud provider, a loss of connectivity can turn core functions into dead weight, including door entry, automation routines and remote video access.
CleverHome’s answer is to put a controller in each flat, rather than relying on a gateway that merely forwards commands to the cloud. In his description, that controller is a full local server handling sensors, wireless devices such as ZigBee equipment, video streams and automation logic. Because the control loop stays inside the apartment, basic functions continue even if the internet is unavailable. The same idea is then extended to the whole building: each block has its own on-site server, connected to a single local network that brings together intercoms, CCTV, access control, lift management and dispatch systems.
That local model is not just about convenience. Logинов argues that it also improves resilience during power loss, because the building server is designed to keep running for an hour in line with requirements already expected of some dispatch systems, particularly lift control. Fire alarms remain a separate autonomous system, but they can still exchange data with the BMS platform so that residents receive immediate alerts identifying the relevant sensor and apartment. In practice, the architecture divides responsibilities: safety-critical systems remain independent, while the smart-home platform provides coordination and notification.
Privacy is presented as a by-product of that design. Because data is processed inside the apartment or building, rather than being shipped to a vendor’s infrastructure, there is less exposure to external interception and less incentive for broad data collection. CleverHome says it has gone further by limiting even its own access to apartment data, accepting a harder incident-response process in exchange for stronger privacy. The company also separates live camera access from video archiving, saying the latter is outside the remit of the smart-home platform.
Logинов does not describe the local model as cost-free. Centralised cloud systems are easier to update in one place, while a distributed network of servers in multiple buildings is more difficult to monitor and maintain. Troubleshooting also becomes more labour-intensive when engineers cannot inspect apartment data remotely. Still, his conclusion is blunt: anyone designing a smart home should ask what still works when the internet fails, where data is processed, what happens if a supplier exits the market and how long the system survives without power. If the answer to those questions is “everything stops”, he suggests, the result is not a smart home at all, but a home dependent on somebody else’s server.
Disclaimer: This content is intended for informational purposes only. Readers are advised to exercise their own judgement, conduct due diligence, or consult a qualified expert before acting on any information provided.
