[GH-ISSUE #102] [Feature request] Support hosting under a relative path

kerem commented

2026-03-02 11:46:26 +03:00

Owner

Originally created by @optroodt on GitHub (Apr 15, 2024).
Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/102

First of all, I really like this project, well done!

I have multiple dockerized apps that I host under a single domain. I using Nginx to proxy requests to the correct container, based on the path.

For example, requests to https://mydomain.com/app1 are proxied to a container on http://127.0.0.1:2000, requests to https://mydomain.com/hoarder are proxied to http://127.0.0.1:3000 and so on.

The rules in Nginx look like this:

    location /hoarder/ {
        access_log /var/log/nginx/hoarder.access.log;
        error_log /var/log/nginx/hoarder.error.log;
        rewrite /hoarder/(.*) /$1 break;
        proxy_pass http://127.0.0.1:3000;
        proxy_redirect / /hoarder/;
    }

Hoarder-app has no setting to set this base path, so I'm running into various issues:

static resources are retrieved from /_next/
login urls come from /providers and others
main app urls go to /dashboard

I can add multiple locations in my Nginx config, but this is cumbersome and error prone (i.e. higher probability of conflicts between apps using the same paths). It would be much more convenient if there would be a setting that lets you define the base path. Any url generated by the app would then be relative to this base path. (e.g. /hoarder/_next/..., /hoarder/dashboard/...)

Thanks!

Originally created by @optroodt on GitHub (Apr 15, 2024). Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/102 First of all, I really like this project, well done! I have multiple dockerized apps that I host under a single domain. I using Nginx to proxy requests to the correct container, based on the path. For example, requests to `https://mydomain.com/app1` are proxied to a container on `http://127.0.0.1:2000`, requests to `https://mydomain.com/hoarder` are proxied to `http://127.0.0.1:3000` and so on. The rules in Nginx look like this: ``` location /hoarder/ { access_log /var/log/nginx/hoarder.access.log; error_log /var/log/nginx/hoarder.error.log; rewrite /hoarder/(.*) /$1 break; proxy_pass http://127.0.0.1:3000; proxy_redirect / /hoarder/; } ``` Hoarder-app has no setting to set this base path, so I'm running into various issues: - static resources are retrieved from `/_next/` - login urls come from `/providers` and others - main app urls go to `/dashboard` I can add multiple locations in my Nginx config, but this is cumbersome and error prone (i.e. higher probability of conflicts between apps using the same paths). It would be much more convenient if there would be a setting that lets you define the base path. Any url generated by the app would then be relative to this base path. (e.g. `/hoarder/_next/...`, `/hoarder/dashboard/...`) Thanks!

kerem added the

feature request

status/icebox

long-term

labels

2026-03-02 11:46:26 +03:00

kerem commented

2026-03-02 11:46:27 +03:00

Author

Owner

@MohamedBassem commented on GitHub (Apr 15, 2024):

Unfortunately, this is going to be hard to implement due to limitations in the framework I'm using. NextJS allows specifying the baseUrl only during build time, and can't be configured in runtime with env variables.

I'm curious, why did you opt into hosting stuff under relative paths versus subdomains?

@MohamedBassem commented on GitHub (Apr 15, 2024): Unfortunately, this is going to be hard to implement due to limitations in the framework I'm using. NextJS allows specifying the `baseUrl` only during build time, and can't be configured in runtime with env variables. I'm curious, why did you opt into hosting stuff under relative paths versus subdomains?

kerem commented

2026-03-02 11:46:27 +03:00

Author

Owner

@optroodt commented on GitHub (Apr 16, 2024):

I use Duck DNS, which gives you a limited number of free dns entries. I would have to automatically renew multiple certificates and remember the domains. I just found that hosting under a path would be quicker (and dirtier... 😅).

Ultimately I guess I will have to set up another domain. :)

Thanks for the quick response!

@optroodt commented on GitHub (Apr 16, 2024): I use [Duck DNS](https://www.duckdns.org/), which gives you a limited number of free dns entries. I would have to automatically renew multiple certificates and remember the domains. I just found that hosting under a path would be quicker (and dirtier... 😅). Ultimately I guess I will have to set up another domain. :) Thanks for the quick response!

kerem commented

2026-03-02 11:46:27 +03:00

Author

Owner

@MohamedBassem commented on GitHub (Apr 16, 2024):

hmmmm, the limited number of dns entries is probably solved by just using DuckDNS for the dynamic dns and then having another domain with a CNAME to the duckdns one. That other domain can then have as many subdomains as you want.
As for the certs, yeah you'll have to manage them (unless you're using something like caddy for auto certs). Putting stuff behind cloudflare also can help you avoid the need for managing the certs as well.

Sorry for intruding on your homelab setup 😅 While not strictly related to hoarder, I love homelabbing and if you have any questions about what I mentioned above, I'm more than happy to help on the hoarder discord ;)

As for the feature request itself, to be honest, it's unlikely to happen anytime soon given the framework limitation, sorry :(

@MohamedBassem commented on GitHub (Apr 16, 2024): hmmmm, the limited number of dns entries is probably solved by just using DuckDNS for the dynamic dns and then having another domain with a CNAME to the duckdns one. That other domain can then have as many subdomains as you want. As for the certs, yeah you'll have to manage them (unless you're using something like caddy for auto certs). Putting stuff behind cloudflare also can help you avoid the need for managing the certs as well. Sorry for intruding on your homelab setup 😅 While not strictly related to hoarder, I love homelabbing and if you have any questions about what I mentioned above, I'm more than happy to help on the hoarder discord ;) As for the feature request itself, to be honest, it's unlikely to happen anytime soon given the framework limitation, sorry :(

kerem commented

2026-03-02 11:46:27 +03:00

Author

Owner

@optroodt commented on GitHub (Apr 16, 2024):

No worries, feel free to close the issue if you like (or keep it open to see if there is more interest).

I use certbot for cert renewal and I've set up a new domain just for hoarder, it works perfectly. 👌

Thanks again, really appreciate your work and keep it up!

@optroodt commented on GitHub (Apr 16, 2024): No worries, feel free to close the issue if you like (or keep it open to see if there is more interest). I use certbot for cert renewal and I've set up a new domain just for hoarder, it works perfectly. 👌 Thanks again, really appreciate your work and keep it up!

kerem commented

2026-03-02 11:46:27 +03:00

Author

Owner

@AlmightyFrog commented on GitHub (Jul 21, 2024):

Besides having less certificates and hosts to manage, I have a different use case why i like to host under a relative path: Security by obscurity

I know, that you should not rely on that, but it proved well already to reduce the attack surface from the internet where you get crawled.
Since i am doing this for several years already the crawlers / and "hacking" attempts are reduced to a level where it does not interfere that much anymore with my limited internet bandwidth I have at home.

Yes, security by obscurity is a bad idea when it comes to security, but if your obscured service you host itself is secure by state of the art it is no problem at all...

TLDR: Is there a way to make it possible @MohamedBassem in future maybe or do you not see it the list of stuff you plan to do?

@AlmightyFrog commented on GitHub (Jul 21, 2024): Besides having less certificates and hosts to manage, I have a different use case why i like to host under a relative path: Security by obscurity I know, that you should not rely on that, but it proved well already to reduce the attack surface from the internet where you get crawled. Since i am doing this for several years already the crawlers / and "hacking" attempts are reduced to a level where it does not interfere that much anymore with my limited internet bandwidth I have at home. Yes, security by obscurity is a bad idea when it comes to security, but if your obscured service you host itself is secure by state of the art it is no problem at all... TLDR: Is there a way to make it possible @MohamedBassem in future maybe or do you not see it the list of stuff you plan to do?

kerem commented

2026-03-02 11:46:27 +03:00

Author

Owner

@kamtschatka commented on GitHub (Jul 23, 2024):

What do you mean with Security by Obscurity?
AFAIK there is no way to find all subdomains for a domain, same as you can't query all paths that are served for a given domain, so I don't understand the benefit you are seeing?
I found some tools that brute force search for subdomains, but if you simply don't name it "hoarder.yourdomain.com", but something random, that should not be an issue anymore?

@kamtschatka commented on GitHub (Jul 23, 2024): What do you mean with Security by Obscurity? AFAIK there is no way to find all subdomains for a domain, same as you can't query all paths that are served for a given domain, so I don't understand the benefit you are seeing? I found some tools that brute force search for subdomains, but if you simply don't name it "hoarder.yourdomain.com", but something random, that should not be an issue anymore?

kerem commented

2026-03-02 11:46:27 +03:00

Author

Owner

@AlmightyFrog commented on GitHub (Jul 25, 2024):

In principal general mistrust: Depending on DNS config of your machine, that requests are cleartext over the network. Also there is in theory axfr which might expose information in case of wrongly configured DNS server.

Sure i can use superlongyouneverguess.example.com but that is cumbersome to type and also kind of obscurity game then.

In contrast when supporting relative paths i could host under www.example.com a static generated webpage which when scanned most likely will not be tried to attack or something well maintained like nextcloud.
Then i cold host www.example.com/mypasswords/ for my key vault and www.example.com/hoarder/ for other services.

I only need to publically maintain one SSL certificate also and everything is fine.

@AlmightyFrog commented on GitHub (Jul 25, 2024): In principal general mistrust: Depending on DNS config of your machine, that requests are cleartext over the network. Also there is in theory axfr which might expose information in case of wrongly configured DNS server. Sure i can use superlongyouneverguess.example.com but that is cumbersome to type and also kind of obscurity game then. In contrast when supporting relative paths i could host under www.example.com a static generated webpage which when scanned most likely will not be tried to attack or something well maintained like nextcloud. Then i cold host www.example.com/mypasswords/ for my key vault and www.example.com/hoarder/ for other services. I only need to publically maintain one SSL certificate also and everything is fine.

kerem commented

2026-03-02 11:46:28 +03:00

Author

Owner

@chrishoage commented on GitHub (Oct 14, 2024):

For me it is around the simplicity of exposing - and by extension securing - publicly accessible services.

I find the cognitive load of securing a single (sub)domain via some sort of tunnel far easier than doing the same thing for all exposed domains

For this reason I try to keep what services I can behind a single domain exposed through tunnel.

(of course this isn't the only self hosted application I host which does not support a base url - for these I've just been putting them behind tailscale - but I do like having some public in case I can't use my VPN for whatever reason)

@chrishoage commented on GitHub (Oct 14, 2024): For me it is around the simplicity of exposing - and by extension securing - publicly accessible services. I find the cognitive load of securing a single (sub)domain via some sort of tunnel far easier than doing the same thing for all exposed domains For this reason I try to keep what services I can behind a single domain exposed through tunnel. (of course this isn't the only self hosted application I host which does not support a base url - for these I've just been putting them behind tailscale - but I do like having some public in case I can't use my VPN for whatever reason)

kerem commented

2026-03-02 11:46:28 +03:00

Author

Owner

@adjokic commented on GitHub (Feb 9, 2025):

Audiobookshelf, YASHA (yet another self-hosted app), recently decided that they would have a default base path.
There was some talk of supporting a dynamic base path, but that was deemed too complicated to implement as well.

Having Hoarder follow the same suit and hard-code the path to something like /hoarder (and redirect to /hoarder from /) would at least satisfy all those who cannot dedicate a (sub-)domain.

@adjokic commented on GitHub (Feb 9, 2025): Audiobookshelf, YASHA (yet another self-hosted app), recently decided that they would have a [default base path](https://github.com/advplyr/audiobookshelf/pull/3810). There was some talk of supporting a dynamic base path, but that was deemed too complicated to implement as well. Having Hoarder follow the same suit and hard-code the path to something like `/hoarder` (and redirect to `/hoarder` from `/`) would at least satisfy all those who cannot dedicate a (sub-)domain.

kerem commented

2026-03-02 11:46:28 +03:00

Author

Owner

@mikelococo commented on GitHub (Feb 11, 2025):

Audiobookshelf, YASHA (yet another self-hosted app), recently decided that they would have a https://github.com/advplyr/audiobookshelf/pull/3810.
There was some talk of supporting a dynamic base path, but that was deemed too complicated to implement as well.

Having Hoarder follow the same suit and hard-code the path to something like /hoarder (and redirect to /hoarder from /) would at least satisfy all those who cannot dedicate a (sub-)domain.

Please not this. I and others with existing subdomain installations are quite irritated about the audiobookshelf change: https://github.com/advplyr/audiobookshelf/issues/3874.

For systems with an existing subdomain install-base, forcing a URL change to add a path:

Forces a url change on all existing users, which itself is annoying.
Leads to a complex request routing setup, which will permanently make debugging more complex for everyone.
Perversely, imposes the cost of the subpath migration primarily on users who aren't using them. While new subpath installs will "just work", all the existing installs now have to figure out before they upgrade whether their proxy setup is going to "just break". Any bugs in the routing monstrosity are much more likely to impact subpathless users since the canonical routes MUST now become subpaths... all the old subpathless routes must flow through the more complex redirect routes and redirection bugs are quite likely to break things for subpathless users and not subpath users.

If NextJS gets fixed (audiobookshelf faces this problem as well) then adding proper configurable dynamic subpaths would be a great feature to support alternative deployment models. Flipping a system that doesn't support subpaths into a system that requires them is a messy and miserable compromise though.

@mikelococo commented on GitHub (Feb 11, 2025): > Audiobookshelf, YASHA (yet another self-hosted app), recently decided that they would have a https://github.com/advplyr/audiobookshelf/pull/3810. > There was some talk of supporting a dynamic base path, but that was deemed too complicated to implement as well. > > Having Hoarder follow the same suit and hard-code the path to something like /hoarder (and redirect to /hoarder from /) would at least satisfy all those who cannot dedicate a (sub-)domain. Please not this. I and others with existing subdomain installations are quite irritated about the audiobookshelf change: https://github.com/advplyr/audiobookshelf/issues/3874. For systems with an existing subdomain install-base, forcing a URL change to add a path: 1. Forces a url change on all existing users, which itself is annoying. 2. Leads to a complex request routing setup, which will permanently make debugging more complex for everyone. 3. Perversely, imposes the cost of the subpath migration primarily on users who aren't using them. While new subpath installs will "just work", all the existing installs now have to figure out before they upgrade whether their proxy setup is going to "just break". Any bugs in the routing monstrosity are much more likely to impact subpathless users since the canonical routes MUST now become subpaths... all the old subpathless routes must flow through the more complex redirect routes and redirection bugs are quite likely to break things for subpathless users and not subpath users. If NextJS gets fixed (audiobookshelf faces this problem as well) then adding proper configurable dynamic subpaths would be a great feature to support alternative deployment models. Flipping a system that doesn't support subpaths into a system that requires them is a messy and miserable compromise though.

kerem commented

2026-03-02 11:46:28 +03:00

Author

Owner

@daenney commented on GitHub (Jul 16, 2025):

Would it be possible to provide two sets of containers, since basePath is a build time option in NextJS? I suspect that for most people a separate build with basePath: "/karakeep" would be enough. That doesn't require any changes to Karakeep or waiting for NextJS to support this at runtime, but it does double the amount of containers.

@daenney commented on GitHub (Jul 16, 2025): Would it be possible to provide two sets of containers, since `basePath` is a build time option in NextJS? I suspect that for most people a separate build with `basePath: "/karakeep"` would be enough. That doesn't require any changes to Karakeep or waiting for NextJS to support this at runtime, but it does double the amount of containers.

Rows
Columns

[GH-ISSUE #102] [Feature request] Support hosting under a relative path #87