# Bose Killed Your SoundTouch. Here's How to Fix It _You didn't break it. Bose did. Here's the fix — and why you shouldn't have to do this._ --- I have a SoundTouch 20. Solid hardware, years of daily use, and as of may 6th the preset buttons no longer work. This post explains what actually broke and why, then walks through how to bring the speaker back using [AfterTouch](https://github.com/gesellix/Bose-SoundTouch), a free open-source toolkit that replaces everything Bose's servers used to handle. No cloud, no Bose account, no app required. Tested on the SoundTouch 20; the process is the same or very similar across all SoundTouch models: 10, 30, Portable, and the home theater systems. ## The Architecture Problem Each of the six preset buttons on the device doesn't store a link to what it's supposed to play. Pressing one sends a request to Bose's servers asking what to stream. Without a server response, nothing plays. There was never a way to make it work locally. Bose knew this when they shipped the product and never disclosed it. For over a decade they sold a "press a button and listen" device with a hidden server dependency that customers had no way of knowing about. The [Consumer Rights Wiki](https://consumerrights.wiki) — which tracks anti-consumer practices in consumer tech — documented this as a clear example of undisclosed cloud dependency leading to functional loss of purchased hardware. In October 2025, Bose announced the servers would go dark. Under pressure from customers, they extended the deadline from February 18 to May 6, 2026. They also published the [SoundTouch Web API documentation](https://assets.bosecreative.com/m/496577402d128874/original/SoundTouch-Web-API.pdf) — though the community had largely documented this local device interface already, and Bose's release appears to have changed little beyond the version number. More to the point, it covers the port 8090 device API, not the cloud-side endpoints the preset buttons actually depend on. Those Bose never documented. The community had to [reverse-engineer them](https://www.gesellix.net/posts/aftertouch-bose-soundtouch/). Bose's official workaround is to save your stations as favourites inside individual music apps and stream from there. That's not really a replacement for preset buttons — it requires having your phone out, opening the right app, and navigating to the right place every time. ## What Still Works | Feature | Status | | -------------------------------- | -------------------- | | Bluetooth playback | ✅ Works | | AUX input | ✅ Works | | AirPlay / Spotify Connect / UPnP | ✅ Works | | Preset buttons (1–6) | ❌ No longer working | | TuneIn / Pandora / iHeartRadio | ❌ No longer working | | SoundTouch app music browsing | ❌ No longer working | You can still play audio, you just need your phone every time. The physical buttons, the thing that let you use the speaker without a phone, no longer work. ## The Fix: AfterTouch [AfterTouch](https://github.com/gesellix/Bose-SoundTouch) is an open-source toolkit by developer [Tobias Gesellchen](https://www.gesellix.net/posts/aftertouch-bose-soundtouch/) that emulates Bose's cloud services on your local network. Once your speaker is pointed at AfterTouch instead of Bose's servers, the preset buttons work again — along with TuneIn lookups and the internal account and device management the speaker expects. It ships as a single binary with no runtime to install, and the steps below only need a basic level of comfort with a terminal. AfterTouch needs to run on a machine that stays on. A Raspberry Pi, a NAS, or any always-on home server works. It doesn't require a lot of resources as it's mostly just serving a link to where the Speaker should play the music from. There are plans to eventually run AfterTouch directly on the SoundTouch hardware itself, which would make the whole setup self-contained, but that's out of scope for this post. AfterTouch builds on [SoundCork](https://github.com/deborahgu/soundcork), the Python-based server originally written by Deborah Gu that first cracked the Bose cloud protocol. AfterTouch extends it with a web UI, automatic device discovery, Docker support, and a migration wizard. Full documentation is at [gesellix.github.io/Bose-SoundTouch](https://gesellix.github.io/Bose-SoundTouch/). This guide will show you how to set up AfterTouch, migrate your speaker, and program the preset buttons with your own stations. **What you need:** - A Raspberry Pi, NAS, or any computer that stays on at home - Docker installed on that machine - Your SoundTouch speaker and home network ### Step 1: Run AfterTouch The easiest method is Docker. On your always-on machine: ```sh docker run -d \ --name soundtouch-service \ --network host \ --restart unless-stopped \ -v $(pwd)/AfterTouch-Data:/app/data \ ghcr.io/gesellix/bose-soundtouch:latest ``` > **Linux:** `--network host` lets AfterTouch discover your speaker automatically via multicast. On macOS or Windows, use `-p 8000:8000 -p 8443:8443` instead and add your speaker's IP manually in the UI. Or if you prefer Docker Compose: ```yaml services: soundtouch-service: image: ghcr.io/gesellix/bose-soundtouch:latest container_name: soundtouch-service network_mode: host volumes: - ./AfterTouch-Data:/app/data restart: unless-stopped ``` Once running, open `http://:8000` in a browser. AfterTouch will start scanning for SoundTouch devices on your network. Bluetooth and AUX playback work regardless of whether AfterTouch is running — they don't touch the network at all. {{< figure src="AfterTouch-page.jpg" alt="Screenshot of the AfterTouch web interface displaying a list of discovered Bose SoundTouch devices on the local network" caption="AfterTouch web UI showing discovered devices" >}} ### Step 2: Migrate Your Speaker Your speaker will appear in the Devices tab. Click **Migrate**. AfterTouch picks the best method for your model automatically. For most SoundTouch devices, including the SoundTouch 20, it uses the **telnet method**: the speaker has an internal diagnostic port (port 17000) that allows repointing the server URLs without opening the device or enabling SSH. There's also a USB SSH method for some models, but telnet works without touching the hardware at all. On the SoundTouch 20, I couldn't get SSH working anyway. AfterTouch will connect to the diagnostic port, repoint all server URLs to your local instance, and reboot the speaker. After rebooting, the speaker checks in with your server instead of Bose's. The preset buttons will respond, but the slots are empty after migration — you need to program them. The [AfterTouch migration guide](https://gesellix.github.io/Bose-SoundTouch/guides/MIGRATION-GUIDE.html) covers every model and edge case if you run into anything. {{< figure src="AfterTouch-migrate.jpg" alt="Screenshot of the AfterTouch device migration screen showing a successful migration for a SoundTouch 20" caption="AfterTouch migration success screen" >}} The speakers will not receive firmware or security updates going forward. Bose recommends keeping them on a private, firewalled network, which is reasonable advice regardless. If you're setting up a speaker that's been factory reset or has never been connected to Wi-Fi, you don't need the SoundTouch app for that part. The speaker broadcasts its own access point during setup; connecting to it brings up a webpage where you can enter your Wi-Fi credentials directly. #### How It Actually Works Your SoundTouch speaker has a configuration file listing the server URLs it calls for different functions — TuneIn lookups, account management (internally called "Marge"), software updates ("BMX"), and so on. Out of the factory they all point at `*.bose.com`. Migration rewrites those URLs to point at your AfterTouch instance. From that point on, when you press preset button 1, the speaker asks your server what to play. AfterTouch looks up what you configured for slot 1 and tells the speaker to stream it. The speaker fetches the audio directly from the radio station. Bose is out of the picture entirely. The only thing leaving your home network is the audio stream itself, going straight to the station's servers — the same as it always did. ### Step 3: Find Your Stream URLs After migration the preset slots are empty. You assign each button a stream URL. This is the genuinely liberating part: you're no longer limited to whatever Bose's curated service list included. Any publicly accessible audio stream works. **Option A: Direct stream URLs (recommended)** Most radio stations publish a raw stream URL on their own website — look for "Listen live" or "Stream", often buried in the footer — or via [radio-browser.info](https://www.radio-browser.info), a community-maintained directory covering tens of thousands of stations worldwide. Stream URLs usually end in `.mp3`, `.aac`, or `/stream`. These are the most durable option because nothing sits between you and the station. If the station keeps broadcasting, the URL keeps working. No Bose, no TuneIn, nothing in between. **Option B: TuneIn station IDs** AfterTouch includes a TuneIn emulation layer. In my testing both direct stream URLs and TuneIn station IDs worked reliably. To use a TuneIn station, pull the ID out of the station's URL: ``` https://tunein.com/radio/Example-FM-s112738/ ``` The `s112738` at the end is the station ID. Pass it with `--source TUNEIN` as shown in Step 4. That said, TuneIn is itself a service with its own longevity risks, so use direct stream URLs where you can find them. ### Step 4: Program the Preset Buttons AfterTouch ships with `soundtouch-cli` for local speaker control. You'll need [Go installed](https://go.dev/dl/) to get it, or grab a pre-built binary directly from the [releases page](https://github.com/gesellix/Bose-SoundTouch/releases) for Linux, macOS, or Windows. **Install with Go:** ```sh go install github.com/gesellix/bose-soundtouch/cmd/soundtouch-cli@latest ``` Find your speaker's IP in the AfterTouch web UI or your router's device list, then: **Discover your device:** ```sh soundtouch-cli discover devices ``` **Program a preset — direct stream URL:** ```sh soundtouch-cli --host 192.168.1.50 preset store \ --slot 1 \ --source LOCAL_INTERNET_RADIO \ --location "http://stream.example.com/live.mp3" \ --name "Example Radio" ``` **Program a preset — TuneIn station ID:** ```sh soundtouch-cli --host 192.168.1.50 preset store \ --slot 2 \ --source TUNEIN \ --location "/v1/playback/station/s112738" \ --name "Example FM" ``` **Verify everything saved:** ```sh soundtouch-cli --host 192.168.1.50 preset list ``` Press button 1 on the physical speaker. It should start playing within a few seconds. The full CLI reference — multiroom zones, scripting, home automation hooks — is at [gesellix.github.io/Bose-SoundTouch](https://gesellix.github.io/Bose-SoundTouch/). ## Home Assistant and Smart Home If you already have SoundTouch in Home Assistant and were using the UPnP integration, it should continue working without any changes. The UPnP was working locally the same as before. ## Other Options AfterTouch isn't the only project that came out of this. [ÜberBöse](https://github.com/julius-d/ueberboese-api) — German for "supremely evil", which is apt — offers native Spotify OAuth support and has an [Android app on F-Droid](https://f-droid.org/packages/io.github.juliusd.ueberboese.app/). Multiple working replacements existed before Bose flipped the switch. The community was ahead of the deadline. ## The Bigger Pattern The hardware works. The firmware works. What failed was an undisclosed, deliberate dependency on a remote server for something as basic as recalling a preset — a dependency that was never given a local fallback, never disclosed to buyers, and eventually terminated with a few months' notice. The right-to-repair conversation has traditionally focused on physical repairability: the right to open a device, replace a part, source components. But the same principle applies to software. If a device is functional hardware running functional firmware, consumers should have a meaningful right to keep using it even after the manufacturer decides the server costs aren't worth maintaining. What Bose did here — architect in a silent cloud dependency, sell the product for a decade, then kill the servers — is the software equivalent of building a car with a component that stops working the moment the dealer closes. The community fixed this one. A handful of developers reverse-engineered the cloud protocol in their own time and built working replacements before the deadline. That's a good outcome. It shouldn't have been necessary. If you want to follow more cases like this, [Consumer Rights Wiki](https://consumerrights.wiki) tracks this pattern across the industry — cloud-dependent hardware, planned obsolescence, and the companies behind it.