Run overseerr on subpath, Base URL

Is your feature request related to a problem? Please describe.
I'm reverse-proxying all services on main domain with caddy. Like https://example.com/radarr/ and https://example.com/sonarr/ and I want to do same with https://example.com/overseerr/
But currently it expects to be available on / path.

Describe the solution you'd like
Solution would be either to use relative URL's throughout the project. Or allow to specify base url/path in startup parameters, like PORT is specific in env variables. Like export BASE=/overseerr would be good enough for me.

Have to agree with this, it's really only usable for me to tinker with once in awhile. Can't have any other users try it out without letting it through the proxy.

You could always run it through a proxy on a subdomain, if your setup permits.

Subpath will take some time to figure out. Might be awhile :(

@sct

Isn't this just a matter of setting the baseurl in next config and doing namespace in express? Can you elaborate on what is hindering this @sct ?

iirc next does not really support setting dynamic baseurls in runtime, so it would be have to built with it already set.

Oh, yeah that's true. So the solution for us would be to prepend every use we have of express, links etc with an env variable we can pass in to the docker image for instance?

Sounds a little hacky, unless you have something centralized that would generate links already. I didn't check your codebase yet.

I'd personally settle with setting it at build-time, it's not often you will change this i feel.

Changing base path in next.config.js is only part of solution. It works and makes app to listen on correct base path (this is a build time setting). I've tried it and it works.
But you need to change also all XHR requests in frontend from /api to $base/api. This involves all calls to axios.get/post and useSWR in frontend code.

I was planning to do this, but was busy past few weeks finishing #538.
My plan was to have build setting in some config file that gets used in both frontend and server. That would be good enough for my usage. Doing this as runtime settings would be much much more work to figure out how to do it.

But if somebody is doing this, then let me know and I won't look at this.

As far as I understand it, setting the base url at build time doesn't work super well with Docker because generally a base url change will require the frontend to be recompiled, which means that you'd either have to

do frontend compilation as part of the container entry point (at runtime), or
require that anybody changing their base url builds their own docker container.

Neither is very appealing in the long run, though they're both far better in the short term than not being able to use the app at all (for many of our use-cases).

To be able to set the base url at runtime, you'd need a couple things:

to be able to serve up the static files (js bundles, index.html, images, etc.) from a dynamic base url at runtime (server restart would be fine). In a normal non-SSR app this would be pretty easy, not sure how it changes with Next.
to know, in frontend code, what base url it's currently being served from (to prefix api calls).
Maybe next could dynamically hydrate the frontend with the base url that it's serving it from somehow? Not sure how that would affect asset paths like images and such, but it would make api call prefixing pretty simple.

Are there any configs for this to work in Apache and base URL? domain.tld/overseerr

i'm very interesting in this!!! have you find a solution with apache ?

Since there seems to exist mainly misunderstanding of what the issue with base URLs are, especially how the fixes for subdomains and matching paths do not apply for path rewriting (you just can't, especially without insane overhead, imagine subdomains working being more of a fluke than actual functionality).

Here's an apt writing about the subject:

https://caddy.community/t/the-subfolder-problem-or-why-cant-i-reverse-proxy-my-app-into-a-subfolder/8575

Long story short, with all URI factors in play (actual compatibility and standard implementation), implement "URL Base" support or watch the community forced to transition elsewhere.

And to be clear, we are still looking into building this support into Overseerr directly. But ETA for that is still unknown.

Still no progression?

New user here with apache reverse proxy. I need base url to use apache and not open a new port for Overseerr.
Any update?

Hi team, any progress ?

I was trying to do this with Traefik ingress in Kubernetes as follows :

apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: overseerr-stripprefix
  namespace: autopvr
spec:
  stripPrefix:
    prefixes:
      - /overseerr
---
apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: overseerr
  namespace: autopvr
spec:
  entryPoints:
    - websecure
  routes:
    - match: Host(`tv.redacted-domain.tld`) && PathPrefix(`/overseerr`)
      kind: Rule
      services:
        - name: overseerr
          port: web
      middlewares:
        - name: overseerr-stripprefix
  tls:
    secretName: autopvr-cert

I can access Overseer but of course everything fails and I get a page without CSS.

Looking at the Traefik docs for stripPrefix, one way of making Overseerr aware of the base URL would be to use the X-Forwarded-Prefix header. I would suppose there's somnething similar with other reverse proxies...

Has this been considered ?

Thanks !

When testing this with subfolders I noticed that the currently suggested sub_filter rules left certain parts broken, such as if you refreshed the page it wouldn't work since the URL wouldn't be correct. It works when clicking around, but a refresh would break. "sw.js" and "offline.html" were also missing.

In case someone else is interested, this is what I came up with for nginx:
location ^~ /pods/direct/overseerr {
    set $app 'pods/direct/overseerr';
    set $app_esc 'pods\/direct\/overseerr';
... 
}

I, too, am looking for a way to run Overseerr in a subfolder, rather than on a subdomain. The above code somewhat works but is definitely not as smooth as accessing the app from the local network. Yet, this is the best I've been able to find online to get Overseerr mostly functional when using a subfolder.

As with all other "arr" apps that run in a subfolder, I would very much appreciate to have this option for Overseerr. Any update on when it might be implemented?

+1 to the above

I'm also very interested in this!

Also interested.

Also interested

@sct

Please, could you update us? @sct
Thanks

+1 another voice surprised this isn't supported already. Would be an excellent addition.

Merge pull request #274 from Fallenbagel/pr269

Navigation Menu

Repository navigation

Run overseerr on subpath, Base URL #274

57 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Run overseerr on subpath, Base URL #274

Description

Activity

adamskoog commented on Dec 28, 2020

sct commented on Dec 28, 2020

jluis2k10 commented on Dec 28, 2020

adamskoog commented on Dec 28, 2020

ankarhem commented on Jan 4, 2021

flying-sausages commented on Jan 4, 2021

ankarhem commented on Jan 4, 2021

flying-sausages commented on Jan 4, 2021

mmozeiko commented on Jan 5, 2021

flying-sausages commented on Jan 9, 2021

mmgoodnow commented on Jan 21, 2021

RageInvader commented on Feb 1, 2021

57 remaining items

dieg0nob commented on Dec 5, 2023

luuvasara commented on Feb 11, 2024

johndoe804 commented on Mar 28, 2024

douggutaby commented on Aug 30, 2024

Twanislas commented on Nov 3, 2024

aodtcr commented on Nov 14, 2024

adrianipopescu commented on Dec 4, 2024

jonathanturcotte commented on Dec 27, 2024

wishx commented on Jan 1, 2025

bmdepesa commented on Mar 15, 2025

Ba3x91aL commented on May 21, 2025

hcooper commented on Oct 8, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions