As others have mentioned, the mixed content aspect was a major reason we used this for Sonoran CAD/CMS/Radio and other scripts. Being able to serve content from a user’s FiveM server through our HTTPS site avoided the usual mixed-content issues that browsers block.
In our case, we primarily used it for community/FiveM-side image hosting, and we were planning to extend it to bodycam recording storage as well. With the deprecation, that workflow unfortunately won’t be possible anymore.
It also provided a reliable way to detect and resolve the address of a community’s server (so our backends know where to send webhooks and events). We already have a fallback method implemented that detects the server’s direct IP and port once this is deprecated, so we can work around that part.
However, the mixed-content problem still remains. Hopefully there will be some sort of replacement for this functionality.
From a tooling perspective, minimizing configuration and making integrations difficult to break is very important. We’ll engineer an alternative if needed, even something like our own proxy system, but realistically most server owners prefer solutions that work with minimal setup. The Nucleus proxy has been a great service for quite some time now.
Thank you for your feedback on the Nucleus reverse proxy deprecation announcement, we’ve been reading through the thread carefully.
In response to your feedback, we’ve extended the deprecation date to June 30, 2026.
We also want to address a point of confusion that came up early in the thread (thanks to those of you who helped clarify this point for others!): the https://cfx.re/join/ join links are not going away.
Regarding the technical concerns raised around SetHttpHandler endpoints and web_baseUrl: we will be updating both the client and server so that anything that would have previously resolved through the Nucleus URL will instead fall back to the server’s actual connectEndpoint. This includes web_baseUrl, which will return the connectEndpoint directly once Nucleus is deprecated, as will the server profiler.
For use-cases that specifically require HTTPS — such as NUI fetch requests or external web integrations — handling SSL will need to be done at the server owner or resource creator level, for example via a third-party reverse proxy.
On the topic of built-in SSL or ACME automation inside FXServer: we don’t have plans for this at this time, but we appreciate the suggestions and understand why it would be valuable for a number of setups.
If you have further questions, please reply to this topic, we will keep it open for an additional two weeks for comments.
I would say automatic SSL would solve a lot of problems requiring the reverse proxy as it’s very commonly used for applications that need an SSL certificate that isn’t self-signed and it would reduce the technical burden on many server owners who may not how to safely set up a reverse proxy. The best example of this is those hosting via ZapHosting or other container app hosting providers that do not provide a full shell to customers so they would be unable to install a proxy alongside the server without additional costs, potentially substantial.
Make it opt-in, have the user supply a domain name and whatever else is required for the certificate deployment to work, and magic happens. I think you could also provide a way to supply a custom certificate bundle if required, but that would be even less common I feel.
The server loads server-tls.crt and server-tls.key with fixed filenames.
There is no hot-reload mechanism for these certificates, so updating them requires a server restart.
HTTP and HTTPS traffic are handled on the same TCP port.
Given this behavior, I think it would be very helpful to at least have official documentation that clearly describes these details.
Having this documented would reduce confusion and help server operators better understand the current limitations and expectations around TLS handling.
With that said, if operators can obtain a proper domain name and a valid certificate (or potentially an IP-based certificate, e.g. via Let’s Encrypt RFC 8738), the deprecation of Nucleus itself might not be a major issue in practice.
This is used by so many devs for communications with outside webpanels, bots etc…
Why would this be removed despite requiring limited upkeep, this in my eyes seems like a cost saving method related to bandwidth… Is this not something that can remain in place with bandwidth limits in place just to prevent people pushing data like images and video, could this be limited strictly to JSON data?
Small developers can’t manage a proxy service for a small userbase realistically and asking clients to setup CF tunnels is out of the picture within simplicity at least…