Onion Address

BTCPay Server, the widely used Bitcoin payment processor, is making Tor privacy access opt-in rather than automatic for Docker deployments starting with version 2.4.5, forcing operators to explicitly enable onion connectivity at their next update. For institutional payment processors and merchants relying on Tor’s anonymity features, this represents a material operational change requiring immediate configuration review.

• BTCPay Server 2.4.5 removes Tor from default Docker components; operators must run sudo btcpay-fragments add opt-add-tor to retain onion access
• The change takes effect at the next Docker setup or update for existing installations, with no automatic migration
• BTCPay also blocked private-network destinations by default for Lightning connections and webhooks to prevent server-side request forgery attacks

• Oct. 5 Date BTCPay announced version 2.4.5 alongside deployment simplification
• 9 Altcoin and legacy integrations removed from Docker stack due to abandoned upstream maintenance
• Jan. 24, 2027 Deadline for Feathercoin, Groestlcoin and Monacoin maintainers to step forward or face removal

BTCPay Server announced in its October 5 release notes that version 2.4.5 shifts Tor from an automatic component to an explicit administrator choice, part of a broader effort to reduce attack surface and container bloat in its standard Docker deployment. The change means operators who rely on their server’s onion address, a common requirement for privacy-conscious merchants and those operating in restrictive jurisdictions, must manually enable Tor or lose access at their next update cycle. Existing Tor data persists in current volumes, but continued onion connectivity depends entirely on the operator running the opt-in command after updating.

Tor becomes optional amid default deployment simplification

BTCPay said the decision reflects years of accumulated optional services, many of which accumulated little actual use or maintenance.

The organization stated that “Tor remains supported, but is no longer included by default,” and that making it opt-in “reduces the default attack surface and resource use without taking the choice away from operators who rely on it.” The shift places responsibility on administrators to consciously select privacy infrastructure rather than inheriting it through the core deployment.

For Docker operators, the trigger is clear: any setup or update to 2.4.5 requires the manual btcpay-fragments command to restore Tor functionality. BTCPay advises all administrators to review deployment changes before updating, particularly those running payment flows through onion addresses or relying on Tor for network anonymity.

The change is not reversible through simple rollback; operators must actively opt in at update time.

Private-network blocking and SSRF protection now mandatory

Alongside the Tor change, 2.4.5 enforces blocking of private-network destinations by default for outbound HTTP requests from Lightning connections, LNURL requests, invoice notification URLs and webhooks. This protection targets server-side request forgery (SSRF) attacks, where an attacker tricks a server into making requests to internal or private resources.

Operators intentionally using private services, such as internal Lightning nodes or private webhook endpoints, must explicitly whitelist those destinations using ssrfexceptions configuration.

The SSRF hardening affects anyone using Lightning integration, notification webhooks or LNURL services. BTCPay requires administrators to restart the application and test affected integrations after changing the setting. This represents a material shift in default security posture for deployments relying on internal infrastructure.

Nine legacy integrations removed; three altcoins face January deadline

BTCPay removed nine integrations entirely: Electrum Personal Server, BlueWallet LNDHub, NDLC, Snapdrop, BTCTransmuter, the Configurator tool, LibrePatron, Isso and Firefly III. Each had either ceased receiving upstream maintenance, relied on unsafe dependencies or mutable container images, or lacked observed usage within the BTCPay operator community.

The organization stated that “continuing to present them as supported options would give operators a false sense of safety.”

Three altcoin integrations, Feathercoin, Groestlcoin and Monacoin, remain for now but face removal on January 24, 2027 (Wednesday), unless active maintainers step forward to keep them current in the btcpayserver-docker repository. BTCPay also removed the old Ethereum configuration, noting that native ETH and ERC-20 support requires a plugin rather than core deployment.

These removals do not delete existing container images from their original registries, only remove them from BTCPay’s supported Docker stack.

The CCS read. We see a payment processor prioritizing operational security and resource efficiency over convenience defaults, a prudent stance for institutional deployments. However, the Tor change creates operational friction: merchants and services that depend on onion access must now actively reconfigure at update time, and the lack of automatic migration means outages are possible if updates happen without explicit Tor re-enablement. This is less a technical flaw than an operational burden that will catch some operators unprepared.

The critical question is adoption among institutional payment processors: how many large merchants and custody providers operating BTCPay Docker deployments will miss the opt-in requirement and lose Tor connectivity mid-update, and whether BTCPay will add a pre-update warning or migration utility before the change reaches production. The January 24, 2027 deadline for altcoin maintainers also signals tightening maintenance discipline across the project, with implications for operators of privacy coins and lesser-used chains.