[Feature Request] Need baseURL for reverse proxy support

Description

We need a baseURL setting (like Radarr and Sonarr have).

Desired Behavior

Allow Jellyseerr to run on https://my.url.com/jellyseerr/.

Additional Context

No response

Code of Conduct

I agree to follow Overseerr's Code of Conduct

Looks like there was a failed attempt to implement in sct/overseerr#2383.

I wouldn't say failed really. It's just more hacky than we'd like since Next.js doesn't allow for changing the base URL after build time. But the PR worked just fine for as long as I was testing it.

There's a preview image for it if you guys wanna try it out (one image was accidentally made, so it's either this one or this one)

Hm someone on discord said they got baseurl working with swag

@ddimick

@ddimick I have the detailed instructions on how to get it to work as well if needed

@fallenbagel

@fallenbagel please post instructions for the baseurl mod

So here's my conf. Mind you, this is just how I got it working, but there's other things you could fix if you wanted to, in my case, they are not running in the same docker network, so I had to pass it the .1.28 ip address, but you normally would just have the name overseerr in that spot. You can also change the /overseerr to /jellyseerr, I just left them as that.

location ^~ /overseerr {
   set $app 'overseerr';

   # Remove /overseerr path to pass to the app
   rewrite ^/overseerr/?(.*)$ /$1 break;
   proxy_pass http://192.168.1.28:5055; # NO TRAILING SLASH

   # Redirect location headers
   proxy_redirect ^ /$app;
   proxy_redirect /setup /$app/setup;
   proxy_redirect /login /$app/login;

   # Sub filters to replace hardcoded paths
   proxy_set_header Accept-Encoding "";
   sub_filter_once off;
   sub_filter_types *;
   sub_filter 'href="/"' 'href="/$app"';
   sub_filter 'href="/login"' 'href="/$app/login"';
   sub_filter 'href:"/"' 'href:"/$app"';
   sub_filter '/_next' '/$app/_next';
   sub_filter '/api/v1' '/$app/api/v1';
   sub_filter '/login/plex/loading' '/$app/login/plex/loading';
   sub_filter '/images/' '/$app/images/';
   sub_filter '/android-' '/$app/android-';
   sub_filter '/apple-' '/$app/apple-';
   sub_filter '/favicon' '/$app/favicon';
   sub_filter '/logo_' '/$app/logo_';
   sub_filter '/site.webmanifest' '/$app/site.webmanifest';
}

the only bug I have noticed is that if you go to another page such as settings, and reload, it won't recognize where you are because you'd now be under domain.com/settings etc. I'm 90% sure fixing the proxy_redirect or the $app variable to the IP address would fix that in my case
This is the settings in the app itself

Make sure your proxy is working because if you enable proxy support, you can still go to the app via IP and port, but it will not save anything, so you will have to go back and change the setting in the config file if you accidentally lock yourself out.

Hope this helps. I have not tried it myself so

@fallenbagel

@fallenbagel your config was working great until recently. Login screen just loops now.

@fallenbagel

@fallenbagel your config was working great until recently. Login screen just loops now.

Since Overseerr 1.30.0 which is 1.2.0 of jellyseerr, the config is now different.

sct/overseerr#274 (comment)

Why am I the last person still using Apache? Haha.
Anyone have any hints on getting Jellyseerr working with a baseurl in Apache?

You are not. I am stuck too, looking for an Apache solution

You are not. I am stuck too, looking for an Apache solution

In my limited knowledge of apache, isn't nginx and apache very similar in its configuration? 🤔
Maybe a translation to it could be achieved

I hope to see this feature in future versions. There's no way to set a baseurl inside jellyseerr. Ombi has this but not jellyseerr

I would also love to see this much needed feature added :)

Yes, a work-around would've been for Jellyseerr to add base href and set all URLs to relative including what NextJS outputs (simple patch) since it'd be just a few lines of code and an adjustment on their part of how they do links

That's the thing you don't understand. It's not "just a few lines of code".

Next.js performs a lot of optimizations during build time (i.e. static assets optimization, code splitting or server side rendering). That's also why Jellyseerr is quite fast despite being a fairly large web app. And you can't just do a "simple patch" to add base URLs to the outputs of Next.js.

The only thing that would work would be an option for users that are building the app from source, but it would not work for Docker users, and they are the majority of users.

If someone does have a reliable solution to implement base URLs, we would be glad to consider it, feel free to make a PR. But we didn't find any for now, we just found some tricks to make it work.

sorry for dropping into the conversation but doesn't nextjs already support this per https://nextjs.org/docs/app/api-reference/next-config-js/basePath ?

genuinely asking, since that's what we used internally during dev for this, but we could be doing it wrong

sorry for dropping into the conversation but doesn't nextjs already support this per https://nextjs.org/docs/app/api-reference/next-config-js/basePath ?

As far as i understand it- the keyword is "runtime" . You can use basePath during build stage. So anyone who want to use it on subfolder, basically, have to compile it from sources, or use tricky middleware. It's fine for those who understand what they do, but most of userbase use releases or docker containers. вт, 10 дек. 2024 г. в 01:15, Adrian Popescu ***@***.***>:

…

sorry for dropping into the conversation but doesn't nextjs already support this per https://nextjs.org/docs/app/api-reference/next-config-js/basePath ? — Reply to this email directly, view it on GitHub <#97 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG34IYFZGKUQBFSBXV7AFOL2EYI65AVCNFSM5WR7HT52U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TENJSHE3DIMZRHAZQ> . You are receiving this because you commented.Message ID: ***@***.***>

@adrianipopescu

@adrianipopescu, as @Rumbiz correctly wrote, this is a compile-time option, not a run-time option. Meaning that you'd need to rebuild the application from source to make it work. That's exactly what @gauthier-th mentioned before.

That's the thing you don't understand. It's not "just a few lines of code".

Next.js performs a lot of optimizations during build time (i.e. static assets optimization, code splitting or server side rendering). That's also why Jellyseerr is quite fast despite being a fairly large web app. And you can't just do a "simple patch" to add base URLs to the outputs of Next.js.

The only thing that would work would be an option for users that are building the app from source, but it would not work for Docker users, and they are the majority of users.

Instead of being wrong you can simply ask how. Then you'd be told "Sure it's possible." One line of sed to binary patch recursively and a predefined base url. I literally told you I used to maintain a patch. You can even do it to the Docker maintained here by overriding the entrypoint (this of course means compiling your own Docker but my aim was universal since a few people were being supported by this at the time, so I chose a 2048-char path and simply binary-patched it by adding a nullbyte at the position at the end of their env-variable domain). Docker. This isn't the only project I've had to tinker with to fix. If I hadn't lost a bunch of projects in a RAID loss I'd have posted it (if I'd have remembered to anyway).

Edit: For those curious, I used one line in a Docker compose (entrypoint: /bin/sh -c 'sed && ...', pseudo obviously, can't remember since it's been well over six months) and one line that automated the build to include a pre-defined base url, so it was multistep but again, was just a few lines.

Edit: And no, it's also possible to address it at runtime as well if you don't mind hijacking to run scripts to resize some files to stretch the string (sometimes in more than one location, sometimes need to skip one or the other occurrence) and then sed-patch as mentioned. This way didn't require compilation which was the end solution I chose for us until they finally got subdomains at which point I said screw it and did the same. Edit: My original attempt was to try to inject base href and make all links relative but sometimes links were generated dynamically so that was an immediate failure. Trying to remember what I did.

Edit: @qriff, If I remember what I did I'll post an entrypoint line for you so you can try it (keep backups, etc, usual "beware this is experimental" applies). I think I started out by cloning, compiled, added base path, compiled, binary-compared, knew where to start SAR-patching (search-and-replace), used an environmental variable which could be specified in the entrypoint (export) or via compose env variables. Been a while though and I've got a number of projects on the backburner at the moment. Edit; Bewarned, I never used tini and if you use any healthchecking based on that I'd avoid it. Edit: It'd also again be experimental because I would certainly not be maintaining it anymore. I settled on a one-liner to keep things simple for the others I was maintaining for.

Probably some sort of understatement, but it would seem like the majority wouldn't have issues by the default build path being static /jellyseerr/ instead of root / and quite rare for someone stricktly needing /strawberrypotato . Afaik this would make it automatically compatible with both sub.domain.tld/jellyseerr/ and domain.tld/jellyseerr/ without any modifications. For now.

Probably some sort of understatement, but it would seem like the majority wouldn't have issues by the default build path being static /jellyseerr/ instead of root / and quite rare for someone stricktly needing /strawberrypotato . Afaik this would make it automatically compatible with both sub.domain.tld/jellyseerr/ and domain.tld/jellyseerr/ without any modifications. For now.

I don't think others would want a base href if they didn't have to use it so I'd disagree with a default base path.

run scripts to resize some files to stretch the string (sometimes in more than one location, sometimes need to skip one or the other occurrence) and then sed-patch

I'm sorry, but we won't consider adding such a feature. The workaround to make it function is overly complex and relies on modifying compiled code, which is a major violation of best practices. These practices exist for good reasons: modifying compiled binaries can lead to unpredictable behavior and long-term issues that far outweigh any short-term convenience.

Using a reverse proxy to handle this is a way better approach, as it avoids tampering with compiled output and aligns with development standards. And implementing tweaks like this goes against the fundamental principles of frameworks like Next.js, which are designed to manage such configurations cleanly and reliably.

Subdomains work because that’s how the internet is designed. That's a standard of the web, and don’t require anything more to make it work. Base URLs, on the other hand, are completely optional, even if it's a nice to have. It is something that has to be implemented on an app level.

I would certainly not be maintaining it anymore.

We would have to maintain it, and maintaining this kind of hack is not feasible. It creates a unsustainable codebase, unpredictable behavior, bugs down the line.

The reason why this feature request is open and not closed as not planned is BECAUSE we want to implement it. It's just we are currently limited by the framework until we can figure out a cleaner way to implement this. You could take this case to Overseerr and they'd tell you the same thing.

Feel free to send a PR for supporting base URL before compilation, or share your tweak somewhere so that people can use it at their own risk, but I'm done with this conversation.

This project is entirely free and open source, driven by the dedication of its contributors. Contributions, whether through code, constructive feedback, or professional discussions, are always welcome and greatly appreciated.

That said, I kindly ask everyone to maintain a respectful and professional tone when engaging in this thread. Criticism is welcome when it's constructive, but any unprofessional comments that undermine the hard work of our contributors (including those of related projects like Overseerr) will not be tolerated.

This is a request for an optional feature, one we are committed to exploring despite current limitations. If there’s any confusion about what this entails, what these limitations are, and why implementing it in a hacky way (modifying compiled code) is bad, I advise you to look it up before undermining other's hardwork.

That said, this discussion is over for now.

@fallenbagel

run scripts to resize some files to stretch the string (sometimes in more than one location, sometimes need to skip one or the other occurrence) and then sed-patch

I'm sorry, but we won't consider adding such a feature. The workaround to make it function is overly complex and relies on modifying compiled code, which is a major violation of best practices. These practices exist for good reasons: modifying compiled binaries can lead to unpredictable behavior and long-term issues that far outweigh any short-term convenience.

Using a reverse proxy to handle this is a way better approach, as it avoids tampering with compiled output and aligns with development standards. And implementing tweaks like this goes against the fundamental principles of frameworks like Next.js, which are designed to manage such configurations cleanly and reliably.

Subdomains work because that’s how the internet is designed. That's a standard of the web, and don’t require anything more to make it work. Base URLs, on the other hand, are completely optional, even if it's a nice to have. It is something that has to be implemented on an app level.

I would certainly not be maintaining it anymore.

We would have to maintain it, and maintaining this kind of hack is not feasible. It creates a unsustainable codebase, unpredictable behavior, bugs down the line.

The reason why this feature request is open and not closed as not planned is BECAUSE we want to implement it. It's just we are currently limited by the framework until we can figure out a cleaner way to implement this. You could take this case to Overseerr and they'd tell you the same thing.

Feel free to send a PR for supporting base URL before compilation, or share your tweak somewhere so that people can use it at their own risk, but I'm done with this conversation.

I wasn't telling you to adopt that I was merely saying it's possible because I maintained a solution for a while after you argued it wasn't possible. I also wasn't telling you to do those things, you seem to have missed quite a bit in that post. I also never suggested anyone to do it, I simply said it was possible. As for reverse-proxying, that itself is a hack-job that doesn't work reliably unless you rewrite the body as well and even then the JavaScript doesn't always execute in order correctly (which is what drove a few people to ask me to make a temporary working solution until they finally decided to switch to subdomains. Again, I never suggested it as a solution to this issue (and if your memory works you'll recall I said they should bring it up with NextJS) and I never suggested you maintain anything. Feel free to read the posts again.

Edit: Above was a reply to gauthier-th.

As per @fallenbagel's request: Walking away from this Issue discussion.

use of port 5055 rather than port 80.

That's literally the default port configuration. Every web service attaches to a port, which must be unique to avoid conflicts with other services.
If port 5055 doesnt suit your needs, you can easily change it by setting the PORT=80 environment variable.

perhaps you intend to implement subdomain-to-port application routing as an extension to the current "design of the internet"? For example, potato.domain.tld could go to port 4044, and tomato.domain.tld could go to port 5055 all on its own—maybe through some modern SNI implementation, similar to DNS over HTTPS (DoH).

There is no such thing as this, and this makes no sense. Web apps work by attaching to a default port, and reverse proxies handle routing requests to appropriate services. Typically, reverse proxies operate on port 80 (HTTP) or 443 (HTTPS). **Subdomains are not an application-level feature. They're handled at the DNS level and function as prefixes to your base domain while working exactly the same as a base domain. The internet inherently supports subdomains, and their behavior doesn't depend on application-specific code.

Regarding basepath: while they are a useful feature for consolidating services under one domain, they are not required for a fully functional web service. In this case, our framework (nextjs, I.e the tech stack we use) has limitations that prevent proper basepath support, as has been explained previously multiple times.
Your analogy of a car does not apply here as basepath is ENTIRELY, and COMPLETELY optional. It is not required to proxy your service. I would recommend reading up on this before making ill-informed comments (no offense).

This issue is a feature request to implement an OPTIONAL quality-of-life feature. The application already achieves its intended scope and supports proper proxying as any other self-hosted services. While we value constructive discussion on how to properly implement this, but off-topic comments and repeated misconceptions hinder the progress, and waste valuable time of others.

I do not want this issue discussion to be a place for education as it has come to be. And as there have not been any constructive discussion that are on-topic (except for a few informed comments above), that is not repeating the same nonsense, and my request to end this discussion was not properly respected and wasted the valuable time of everyone who are genuinely trying to contribute to the discussion, this thread will remain LOCKED until further notice.

I sincerely apologise to any of those who were looking to have a constructive discussion about this issue, and if you have any insights or want to discuss further on implementing basepath support given our framework, feel free to reach out to me via our discord server.

Navigation Menu

Repository navigation

[Feature Request] Need baseURL for reverse proxy support #97

Description

Desired Behavior

Additional Context

Code of Conduct

40 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Feature Request] Need baseURL for reverse proxy support #97

Description

Description

Desired Behavior

Additional Context

Code of Conduct

Activity

ddimick commented on May 21, 2022

danshilm commented on Jun 20, 2022

fallenbagel commented on Jul 3, 2022

fallenbagel commented on Jul 4, 2022

M-MDev commented on Sep 1, 2022

fallenbagel commented on Sep 1, 2022

M-MDev commented on Oct 20, 2022

fallenbagel commented on Oct 20, 2022

ajdunevent commented on Oct 23, 2022

DuvelCorp commented on Dec 4, 2022

fallenbagel commented on Dec 4, 2022

Yankees4life commented on Jan 2, 2023

ramkrishna757575 commented on Jan 31, 2023

40 remaining items

gauthier-th commented on Dec 9, 2024

adrianipopescu commented on Dec 9, 2024

Rumbiz commented on Dec 9, 2024

Shadowghost commented on Dec 9, 2024

OdinVex commented on Dec 10, 2024

luuvasara commented on Dec 10, 2024

OdinVex commented on Dec 10, 2024

gauthier-th commented on Dec 10, 2024

fallenbagel commented on Dec 10, 2024

OdinVex commented on Dec 10, 2024

luuvasara commented on Dec 10, 2024

fallenbagel commented on Dec 11, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions