BTCPay Server 2.4.5 Kills Default Tor: One Command Saves Your Onion Address

BTCPay Server shipped version 2.4.5, and the headline change is this: Tor is no longer part of the standard Docker deployment. If you run a Bitcoin payment server and you want people reaching it through an onion address, you now have to say so out loud.

How It Unfolded

The project announced the deployment change on October 5. The GitHub release page logged the 2.4.5 code on October 6. A one-day gap between blog post and tagged release is ordinary housekeeping, but what rode along inside that version isn't ordinary at all.

Tor used to ship inside the core BTCPay Server fragment for standard Docker deployments. Fragments are the building blocks that assemble the Docker stack, so when Tor lived in the core set, it just worked. Nobody had to think about it. That's gone.

Here's the line that actually matters for anyone who wants onion access back:

sudo btcpay-fragments add opt-add-tor

One command. Root required, and the fragment change reapplies setup immediately rather than waiting for a restart. The optional Tor fragment adds hidden services and the onion connectivity that goes with them, and BTCPay's documentation is clear that nothing about this is deprecated. Tor is still supported. It's just no longer presumed.

For existing installations, the trigger isn't the setup you ran months ago. It's your next Docker setup or update. That's the deadline, and it's one you're setting for yourself.

Reading between the lines, this is a project deciding that a privacy feature shouldn't be invisible. Which raises a fair question. Does an operator who never chose Tor actually want Tor, or did they just never notice it was on?

What Actually Breaks

The obvious casualties are merchants and node operators who advertise.onion endpoints to their customers. Update without adding the fragment and the onion service stops.

The stored data survives. That's the key detail BTCPay is careful to flag, and it's worth repeating because it's easy to misread. Existing data stays in the current Tor volumes. But data retention and service continuity are two entirely different promises, and only the first one is guaranteed. Your keys aren't at risk. Your reachability is.

So who notices? Anyone whose customers arrive through Tor, which includes operators in places where clearnet payment processing draws unwanted attention. Capital controls, banking restrictions, ISP-level filtering. For those merchants, an onion address isn't a novelty. It's the storefront.

Then there's the second change in 2.4.5, and I'd argue it's the one that'll generate more support tickets than the Tor decision. Outbound HTTP requests to private-network destinations are now blocked by default. That covers Lightning connections, LNURL requests, invoice notification URLs, and webhooks.

The intent is server-side request forgery prevention, and the reasoning is sound. An invoice metadata field that can point your server at an internal address is a genuinely dangerous thing. But block-by-default means anyone running a Lightning node on a private IP, or aiming webhooks at an internal service, will watch those calls fail silently after updating. The fix is the ssrfexceptions setting. Restart the application, then exercise the affected integration, because a config that looks correct and a webhook that fires aren't the same thing.

From a compliance standpoint, this is the right direction. Explicit allowlists create audit trails. Silent defaults don't. If you've ever had to explain your infrastructure to a regulator, an auditor, or a nervous payment processor, you know which one of those is easier to defend.

My hotter take: the SSRF change is underrated and the Tor change is overrated. Nobody loses money because Tor became optional. People lose money when invoice notifications quietly stop firing and orders sit unconfirmed for six hours. That's the failure mode to lose sleep over.

What Comes Next

Expect more of this, not less. The pattern across Bitcoin infrastructure over the past several months is smaller defaults and more explicit configuration. Bitcoin Core pushed a privacy fix into v32 code while leaving the v31 patch open. Lightning Labs disclosed a critical bug that could mark canceled invoices as paid, which risks free product delivery for any merchant trusting the wrong state. The whole field is moving from convenient to documented.

The precedent here's important, and it cuts in one direction. The precedent here's important, and it cuts toward opt-in. Convenience defaults are being retired across the stack because they hide decisions from the people who own the consequences.

So what should a BTCPay operator do this week? Start with inspection, not action. The btcpay-fragments show command reports your saved, additional, and excluded fragments alongside the effective fragments from the last generated manifest. It changes nothing. It just tells you what you're actually running, which is information a surprising number of operators don't have.

Then decide. Rely on onions? Add the fragment. Point at private services? Write your exceptions before the update, not after your first failed Lightning payment. Restart. Test the integration end to end.

One more thing worth watching. Fragment-changing commands require root, which means every one of these adjustments is an elevated-privilege operation on a machine holding payment credentials. That's a small operational tax per change, and it adds up for anyone managing multiple deployments. Hosting providers and managed BTCPay services are going to feel that more than solo merchants, and I'd expect some of them to bake the Tor fragment into their default templates within weeks.

Defaults are policy. BTCPay just rewrote one, and announced it five days before most operators needed to care. The ones who read the notes will keep their onions. The rest will find out from a customer.