CryptoSlate
BTCPay Server has removed Tor from the automatically included components of its standard Docker deployment, starting with version 2.4.5 announced Oct. 5 and released on GitHub on Oct. 6. Operators who rely on onion access, including their server's onion address, must now explicitly select Tor during their next setup or update to keep it running.
The move turns a previously bundled service into an administrator's configuration choice. Docker deployments are assembled from fragments, the configuration components that make up the stack, and Tor now lives in an optional fragment rather than the core BTCPay Server fragment. After updating, the instruction to re-enable it is: sudo btcpay-fragments add opt-add-tor.
BTCPay says Tor remains supported and that existing data stays in the current Tor volumes, so stored data is preserved. Continued onion access, however, depends on including and running Tor in the deployment. Administrators are advised to review the deployment changes before updating, and can inspect their configuration with btcpay-fragments show, a read-only command that reports saved additional and excluded fragments alongside the effective ones from the last generated manifest.
Why it matters
For merchants and payment processors running BTCPay, the default configuration is often the configuration. An operator who updates without reading the release notes could silently lose the onion address that customers or internal tooling depend on, without any data loss to flag the problem. The change shifts Tor from an ambient default to a deliberate privacy decision.
Market impact
The 2.4.5 release also carries a breaking change for outbound HTTP requests: private-network destinations are blocked by default for Lightning connections, LNURL requests, invoice notification URLs and webhooks, a measure designed to prevent server-side request forgery (SSRF). Operators intentionally using private services must allow the needed destinations through ssrfexceptions, then restart the application and test the affected integration. Between the Tor opt-in and the SSRF hardening, administrators should treat this update as a configuration review, not a routine patch.
Frequently asked questions
-
What happens if I update BTCPay without opting into Tor?
Your Docker deployment will no longer include Tor, so your server's onion address stops working. Existing data stays in the current Tor volumes, and you can restore onion access by running sudo btcpay-fragments add opt-add-tor.
-
Which BTCPay version made Tor an opt-in component?
Version 2.4.5, announced on Oct. 5 and recorded on the official GitHub release page on Oct. 6. The trigger for existing installations is their next Docker setup or update.
-
How do I check whether Tor is enabled in my BTCPay Docker deployment?
Run btcpay-fragments show. It is a read-only command that reports saved additional and excluded fragments alongside the effective fragments from the last generated manifest, without changing configuration.
-
Why did BTCPay block private-network HTTP requests by default?
The restriction in v2.4.5 applies to Lightning connections, LNURL requests, invoice notification URLs and webhooks, and is intended to prevent server-side request forgery (SSRF), where an attacker tricks the server into making requests to internal services.
-
How do I allow private webhook or LNURL destinations after the SSRF change?
Add the needed destinations through ssrfexceptions, then restart the application and exercise the affected integration. BTCPay's operator guide recommends testing the connection after changing the setting.
CoinTelegraph
WatcherGuru
WuBlockchain
CoinDesk
Crypto Rank News