I am running LNbits behind a reverse proxy on a subdomain while serving public LNURLP-PayLinks identities for a separate root domain. In v1.4.0 I have encountered a frontend regression that breaks LNURLP-PayLinks deep links, and an architectural limitation that forces unnecessary proxy complexity.

These issues do not occur in v1.3.1.

1. Frontend regression in v1.4.0 (relative paths)

When accessing public LNURLP-PayLinks pages directly (e.g. via QR or copied link):

/lnurlp/link/<id>

the frontend attempts to load assets using relative paths instead of absolute paths.

Actual requests:

GET /lnurlp/static/routes.json   -> 404
GET /lnurlp/static/logo.png      -> 404

Expected:

GET /static/routes.json
GET /static/logo.png

This causes the LNURLP-PayLinks UI to partially or completely fail when accessed as a deep link.

This appears to be a regression introduced in v1.4.0’s frontend build pipeline. The issue reproduces consistently across:

Nginx reverse proxy

WordPress proxy

direct Tor (.onion) access

2. LNURLP-PayLinks lacks a “Public Identity Domain” configuration

LNURLP-PayLinks currently binds identifiers and links to the LNbits hosting domain (via LNBITS_BASE_URL or request headers).

This makes it difficult to support the common deployment pattern:

LNbits hosted on a service subdomain (e.g. lnbits-proxy.example.com)

Public LNURLp identities served for a root domain (e.g. [email protected])

In contrast, the Nostr NIP-05 extension includes an explicit domain field, allowing clean separation between:

service location (LNbits proxy e.g. lnbits-proxy.example.com)

public identity domain ([email protected] for NIP-5 and LNURLP, not [email protected])

LNURLP-PayLinks extension lacks this abstraction, forcing users into complex reverse-proxy and header-rewriting setups.

Environment

OS: Umbrel OS 1.5

LNbits: v1.4.0 (Docker, lnbits/lnbits:v1.4.0)
(LNbits for Core Lightning as only LND LNbits is currently offered on Umbrel App Store)

Backend: Core Lightning (RPC socket mount)

Proxy: Nginx Proxy Manager

Cloudflare Tunnel (provides SSL and proxy of public IP)

Also tested via Tor (.onion)

v1.3.1 does not exhibit the frontend regression

Impact

The combination of:

The frontend regression breaking deep links

The rigid coupling of LNURLP-PayLinks to the hosting domain

makes it difficult to deploy LNbits cleanly in production when:

LNbits is not on the root domain

Tor is a first-class interface

HTTPS and Tor must coexist

Public identity should remain stable

Offer:

I am happy to test patches or PRs and am offering a 50,000 sat bounty toward resolving this for others running LNbits behind a separate public site.