🚀 Feature: Reverse-proxy on a subpath #355

Closed
opened 2025-10-08 00:04:48 +03:00 by OVERLORD · 1 comment
Owner

Originally created by @drzezga on GitHub.

Feature description

It seems there is currently no way to configure pocket-id to work inside a reverse-proxy on a subpath.

When I configure nginx to route pocket-id through the /pocket-id/ path and configure pocket-id to use this subpath, it gets ignored and all URLs still lead to /. This makes the web interface unusable, as it either redirects to /login (which 404s) or opens a blank error page with broken URLs.

# nginx reverse proxy default.conf

server {
    listen 80;
    listen [::]:80;
    server_name localhost;

    location /pocket-id/ {
        proxy_pass http://pocket-id:3000/;
        proxy_busy_buffers_size   512k;
        proxy_buffers   4 512k;
        proxy_buffer_size   256k;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}
# Environment variables for pocket-id
# See the README for more information: https://github.com/pocket-id/pocket-id?tab=readme-ov-file#environment-variables
PUBLIC_APP_URL=http://localhost/pocket-id
TRUST_PROXY=true
MAXMIND_LICENSE_KEY=
PUID=1000
PGID=1000

In all examples I was able to find, pocket-id runs on the root of the domain - the demo, the caddyfile, the user management page, etc.

Pitch

It would be really useful if this could be done. Some deployments require all services to be accessible through only one domain. The way it's currently implemented, nothing else can be hosted on the / path except pocket-id.

When the PUBLIC_APP_URL env var is set to a subpath of a domain, this feature should be enabled and the correct path should be used.

If this behaviour is intentional and is a security consideration, I would appreciate learning about it.

Originally created by @drzezga on GitHub. ### Feature description It seems there is currently no way to configure pocket-id to work inside a reverse-proxy on a subpath. When I configure nginx to route pocket-id through the `/pocket-id/` path and configure pocket-id to use this subpath, it gets ignored and all URLs still lead to `/`. This makes the web interface unusable, as it either redirects to `/login` (which 404s) or opens a blank error page with broken URLs. ``` # nginx reverse proxy default.conf server { listen 80; listen [::]:80; server_name localhost; location /pocket-id/ { proxy_pass http://pocket-id:3000/; proxy_busy_buffers_size 512k; proxy_buffers 4 512k; proxy_buffer_size 256k; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } ``` ``` # Environment variables for pocket-id # See the README for more information: https://github.com/pocket-id/pocket-id?tab=readme-ov-file#environment-variables PUBLIC_APP_URL=http://localhost/pocket-id TRUST_PROXY=true MAXMIND_LICENSE_KEY= PUID=1000 PGID=1000 ``` In all examples I was able to find, pocket-id runs on the root of the domain - the demo, the caddyfile, the user management page, etc. ### Pitch It would be really useful if this could be done. Some deployments require all services to be accessible through only one domain. The way it's currently implemented, nothing else can be hosted on the `/` path except pocket-id. When the PUBLIC_APP_URL env var is set to a subpath of a domain, this feature should be enabled and the correct path should be used. If this behaviour is intentional and is a security consideration, I would appreciate learning about it.
OVERLORD added the feature label 2025-10-08 00:04:48 +03:00
Author
Owner

@stonith404 commented on GitHub:

I’m not sure if implementing this makes sense. Running services on a subpath, rather than a subdomain, isn’t generally recommended and could add complexity in both implementation and maintenance.

From a security perspective, if services manage cookies correctly, it shouldn’t be a major issue. However, it would be possible that another service overwrites Pocket ID’s cookies.

Could you share more details on your use case? What’s the advantage of running multiple services on the same domain rather than using subdomains?

@stonith404 commented on GitHub: I’m not sure if implementing this makes sense. Running services on a subpath, rather than a subdomain, isn’t generally recommended and could add complexity in both implementation and maintenance. From a security perspective, if services manage cookies correctly, it shouldn’t be a major issue. However, it would be possible that another service overwrites Pocket ID’s cookies. Could you share more details on your use case? What’s the advantage of running multiple services on the same domain rather than using subdomains?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pocket-id-pocket-id-1#355