↓Skip to main content

AfterTouch: Keeping Bose SoundTouch Speakers Fully Featured After the Cloud Shutdown

·7 mins

On May 6, 2026, Bose shuts down SoundTouch cloud services . But before you assume this turns your speaker into a paperweight: Bose is also pushing an automatic app update that preserves the basics — device setup, remote control, multiroom groups, and streaming via AirPlay, Bluetooth, Spotify Connect, or AUX.

So the speakers keep working. Just not completely.

What you lose with the cloud: presets. Those numbered buttons on the device and in the app — gone. In-app music browsing — no more browsing TuneIn or other services from within the SoundTouch app. SoundTouch 10 stereo pairing — also a casualty. And no more security updates, which is its own quiet concern.

For a lot of people, losing presets is losing the primary way they use these speakers. One tap to start the morning radio station. That’s the workflow, and it stops working tomorrow.

Unless you prepared. Here’s what I built, and why.

The SoundTouch Community Had Already Started #

When Bose announced the cloud shutdown, my first thought was: “Someone has probably already started working on a local replacement.” That instinct was right.

The first project I found was SoundCork by Deborah Kaplan and contributors. It’s a Python FastAPI service that intercepts the Bose cloud API calls — specifically the BMX (Bose Media eXchange) and Marge endpoints that the speakers use for account management, preset sync, and media browsing — and answers them locally.

SoundCork pioneered the entire approach. It figured out which endpoints matter, what the request/response shapes look like, and how to redirect a speaker away from Bose’s infrastructure and toward a local service. Without that work, I’d have spent months on reverse engineering alone. Instead, I could build on a solid foundation.

Credit where it’s due: SoundCork is the blueprint. My project wouldn’t exist without it.

Why Go? #

I wanted something I could ship as a single binary — download and run, no runtime to install. Cross-platform without a package manager. Goroutines instead of async. And honestly: Go is the language I reach for when I want something I’ll still understand in two years.

There’s one more reason that only became clear later: Go cross-compiles to armv7 without any fuss, and the SoundTouch speakers themselves run on armv7 hardware. Someone already verified that the AfterTouch binary executes on a SoundTouch 20 without modifications (issue #196 ). That opens up an interesting future where AfterTouch runs directly on the speaker, with no separate server required.

The result is github.com/gesellix/bose-soundtouch — a Go toolkit for SoundTouch devices that includes a full local cloud replacement called soundtouch-service. Internally I’ve been calling it AfterTouch.

What AfterTouch Does #

At its core, AfterTouch is a local HTTP server that the speakers talk to instead of Bose’s cloud. Once a speaker is redirected — more on that in a moment — it uses AfterTouch for everything that used to require an internet connection:

  • Presets: Store and retrieve up to six presets per speaker, synced across devices on the same account. The numbered buttons work again.
  • TuneIn and media browsing: The BMX service lets the speaker browse and play internet radio stations the same way it always did.
  • Account and device management: The Marge service handles device registration, source learning, and recent items tracking.
  • Spotify Connect: Full ZeroConf priming with Diffie-Hellman key exchange so Spotify authentication works without relying on Bose’s relay.
  • Multiroom zones: Group speakers together and control them as a unit.

There’s a web UI at http://localhost:8000 that handles the whole setup. No config files to write.

Redirecting the Speaker #

The tricky part is getting the speaker to talk to AfterTouch instead of *.bose.com. There are two approaches, and the web UI guides you through both.

XML redirect uploads a configuration file directly to the speaker via its local Web API. It’s the minimal approach — it covers only the specific endpoints registered in that config, without touching your network infrastructure.

DNS redirect runs a custom DNS server on your network so that every outgoing request from the speaker to a Bose hostname resolves to the AfterTouch server instead. This catches all traffic at once. It requires HTTPS — AfterTouch manages its own certificate authority, and the web UI walks you through trusting the CA cert on each speaker.

Beyond What the Original App Could Do #

Once you have local control, you’re not limited to what Bose shipped. This is where a community-maintained solution can actually improve on the original.

CLI and home automation: soundtouch-cli controls any speaker over the local network — play, pause, volume, presets, multiroom zones, device discovery. All scriptable. Pipe it into a cron job, trigger it from a webhook, integrate it with whatever home automation stack you run. The original app never exposed this.

Real-time event streaming: The speakers speak WebSocket for status updates. AfterTouch exposes those events, so you can build integrations that react to speaker state rather than polling. Track changes, volume adjustments, playback status — all available programmatically via WebSocket. The official app never gave you this.

Backup before shutdown: soundtouch-backup saves your Bose cloud account — presets, paired devices, music sources — while the cloud is still running. That data is what AfterTouch uses to restore your full setup locally.

Traffic transparency: An optional proxy mode logs everything the speaker sends and receives. It’s how much of the protocol was documented in the first place — and it’s available to anyone who wants to understand or extend what their speaker is doing. LOG_PROXY_BODY=true soundtouch-service gives you visibility Bose never provided.

Go library: pkg/client is an importable package. If you want to build your own integration — a custom dashboard, a voice assistant hook, a Home Assistant component — the library gives you a typed API over the SoundTouch Web API with WebSocket event support included.

The Migration Path #

The recommended sequence:

  1. Run soundtouch-backup all to snapshot your account and device state from the Bose cloud.
  2. Start soundtouch-service on a machine with a stable local address, e.g. http://localhost:8000.
  3. Open that address in your browser and follow the migration steps.
  4. Choose your redirect method — XML for minimal coverage, DNS to catch all speaker traffic.
  5. Install the CA certificate on each speaker (the web UI shows how).
  6. Verify presets load and TuneIn browsing works.

After that, the speaker doesn’t know Bose’s cloud is gone.

What’s Still Missing #

I want to be honest about the gaps. SoundCork has a more flexible BMX service registry — a JSON file you can edit to add or mock new streaming providers without touching code. AfterTouch hardcodes the service list, which covers the common cases but is less extensible. That’s on the roadmap.

Stereo pair management for SoundTouch 10 is partially implemented. Basic group CRUD works; the finer-grained master/slave pairing logic is still incomplete.

The most intriguing open question is whether AfterTouch can run on the speaker hardware itself. The speakers use an armv7 processor, and the binary already executes on a SoundTouch 20 — the remaining challenge is getting it to start at boot and expose the right ports. If that works out, the whole setup becomes self-contained: no separate server, one speaker hosts the service for the entire network.

And some things AfterTouch can’t solve: no security updates is a real concern that no community project addresses. The speakers are running firmware that Bose will no longer patch. Running them on a firewalled private network (as Bose themselves recommends) is the pragmatic response, but it’s worth being clear that local emulation doesn’t fix the security picture.

The Bigger Picture #

Hardware that stops working because a vendor shuts down a cloud service is a recurring frustration. The SoundTouch community — SoundCork , ÜberBöse , OpenCloudTouch , SoundTouch Plus — built a body of knowledge through reverse engineering and documentation that makes projects like this possible. That’s the part that genuinely impresses me: a handful of people, none of them at Bose, figured out enough of the protocol to keep the devices running. Bose did release the speaker’s local Web API documentation when they announced the shutdown, which helped — though the cloud-side API that AfterTouch had to reverse-engineer was a different matter entirely.

AfterTouch is my contribution to that ecosystem. It stands on SoundCork’s shoulders. I hope it keeps a few more speakers out of the bin.

The project is at github.com/gesellix/bose-soundtouch . The Survival Guide has the full picture, and the Migration Guide walks through every step.