On 2 October 2026, Nabu Casa confirmed that the subscription it has sold since 2018 as Home Assistant Cloud will be called Home Assistant Link. The switch becomes official with the 2026.12 release on 2 December. Pricing does not move: $6.50 a month or $65 a year, with a 31-day trial that asks for no card details. The feature set does not move either. Remote access, offsite backups, Alexa and Google Home bridging, hosted speech-to-text and text-to-speech, better camera and audio streaming, and a support queue answered by actual humans.

So it is a rename, and renames are normally the least interesting thing a company announces. This one is worth sitting with, because the stated reason is that the word "cloud" has stopped describing the product and started describing a set of behaviours the team wants nothing to do with.

Eight years of brand equity, traded away on purpose.

The word drifted and took the product with it

Around 2012, "cloud" was a reasonably precise engineering term. It meant elastic capacity, metered billing, and somebody else running the hardware. Useful word. By 2026 the consumer meaning has drifted somewhere else entirely: monthly fees that creep upward, thermostats that lose their schedules when a vendor shuts a server down, cameras that stop detecting motion after an acquisition, and data quietly repurposed for ad targeting or model training.

That drift created a real problem for a local-first smart home platform. Home Assistant's whole pitch is that the automation engine runs on a box in your house and keeps running when the WAN link drops. Then the official add-on service had "Cloud" stamped on it. Founder Paulus Schoutsen has spent years telling audiences not to buy devices that need a vendor's servers to function, and then immediately having to explain why this particular service is different. Two sentences of caveat every single time. Worse, a steady stream of new users assumed the product was a hosted Home Assistant instance, which it has never been.

The word came out of the company logo too.

We hit a version of this on client work in Accra almost every month. Say "cloud" in a scoping meeting and the next question is whether the system dies when the fibre cut happens or when the data bundle runs out. Fair question. Naming a component after its deployment location tells the user nothing they need and everything they fear.

Optional is an architecture, not a bullet point

Here is the part that actually costs money. Claiming a hosted service is optional is cheap. Making it true means you carry two execution paths for every capability that touches the network, forever.

Think about what that implies for a speech pipeline. Hosted speech-to-text is faster, handles more languages, and does not thrash a mini PC's CPU. A local Whisper model on an N100 box is slower and narrower, but it answers when the uplink is gone. If the service is genuinely optional, both paths must exist, both must be tested, and the handoff between them has to be boring. Same story for backups, remote access, and voice assistant bridging. Every one of those is a fallback chain, not a feature.

The failure mode we see most often in other people's code is that the degraded path exists but nobody ever exercises it. It was written during the first sprint, then slowly rotted while the hosted path got all the attention. Six months later a customer loses connectivity and discovers the local branch throws a KeyError on a config field that was renamed in March.

The fix is cheap and almost nobody does it. Run part of your suite with egress blocked.

# tests/test_degraded_mode.py
import socket
import pytest

@pytest.fixture
def no_egress(monkeypatch):
    def blocked(*args, **kwargs):
        raise OSError("outbound network disabled for degraded-mode test")
    monkeypatch.setattr(socket, "create_connection", blocked)
    monkeypatch.setattr(socket.socket, "connect", blocked)
    yield

def test_evening_automation_runs_offline(no_egress, home):
    home.automations.run("evening_lights")
    assert home.entity("light.kitchen").state == "on"

def test_speech_falls_back_to_local_engine(no_egress, home):
    with open("fixtures/hello.wav", "rb") as audio:
        result = home.pipeline.speech_to_text(audio)
    assert result.engine == "whisper-local"
    assert result.text.lower().startswith("hello")

In CI we go further and run the degraded job inside a container with no default route, because monkeypatching only catches the code paths you remembered to think about. A missing route catches the SDK that opens its own socket in a background thread.

Holding the key means giving up the easy answers

Link encrypts user data so that only the subscriber holds the key. That sentence looks like marketing until you work out what it removes from your roadmap.

No server-side search over backups. No deduplication across customers, so your storage bill scales with raw bytes rather than with unique blocks. No "let me take a look at your data" from support, which means your diagnostics have to be built from metadata and client-side logs the user chooses to send. No password reset that recovers content, so the recovery-code flow becomes a first-class piece of product design rather than a modal nobody reads. And no analytics on the content itself, which quietly rules out a whole category of feature ideas that would otherwise look obvious in a planning meeting.

Teams usually discover this ordering problem backwards. They ship the convenient version, grow, then try to retrofit end-to-end encryption and find that four of their best features depend on reading the plaintext. Decide early, because this one is close to irreversible.

A rename is a migration with a release date

Two months of notice before 2026.12 is not generosity, it is scheduling. The surface area of a rename on a platform this size is larger than it looks: translated UI strings across dozens of languages, documentation pages and their redirects, support centre categories, billing descriptors on customers' bank statements, screenshots in tutorials, community guides nobody controls, and the inevitable wave of "is my subscription cancelled?" tickets.

The account page was rebuilt ahead of the name change.

The smart move, and the one we would push for in a design review, is to rename the human-facing layer and leave the machine-facing layer alone. In Home Assistant the integration domain is cloud, which means entity IDs, service calls, config entries, and years of user YAML all depend on that string. Changing it would break automations in thousands of homes for a marketing win. Leave it. Users read labels, not domains.

Underneath the rename there is a far more consequential change that most subscribers will never notice: the remote access backend moved to a bare-metal setup that routes each connection to the nearest server. That is the work that makes the product feel different. The name change is what gets the attention.

The new name, in use on the subscription's own page ahead of the December release.

Worth auditing your own labels

Open your product's settings screen and read the words out loud to someone who does not work in software. Anything named after where it runs rather than what it does is a candidate for the same treatment. "Cloud sync" tells a user about your deployment topology. "Keep my notes on every device" tells them what they get.

And if any part of your pitch includes the word optional, go block egress in CI this week. Either the claim survives the test or you have just found your next bug. We would rather find it on a Tuesday afternoon than during a customer's outage.