Analysis

FiveM and RedM Server Owners Must Migrate Away from Cfx.re Nucleus Proxy

Cfx.re's Nucleus proxy is being deprecated, and FiveM/RedM server owners who rely on it for HTTP endpoints, NUI assets, or admin tools need to act now.

Sam Ortega5 min read
Published
Listen to this article0:00 min
Share this article:
FiveM and RedM Server Owners Must Migrate Away from Cfx.re Nucleus Proxy
AI-generated illustration

If your FiveM or RedM server uses anything routed through `*.users.cfx.re`, you're on borrowed time. Cfx.re's Nucleus reverse proxy, the infrastructure that quietly handled HTTP endpoints, NUI assets, and admin tooling for countless servers and resources, is being deprecated. When it goes, anything still pointing at Nucleus goes with it. This guide walks you through what Nucleus actually does, what breaks when it's gone, and how to migrate cleanly before it becomes your emergency.

What Nucleus actually is

Nucleus is a reverse proxy service built into the Cfx.re ecosystem. It gave server owners and mod authors a convenient way to expose HTTP endpoints and serve NUI (in-game browser) assets without needing to manage their own web infrastructure. Admin panels, resource dashboards, and custom UI pages could all be tunneled through a `*.users.cfx.re` subdomain and made accessible without opening ports, configuring a web server, or touching DNS.

That convenience came with a cost that's now due: tight coupling to Cfx.re infrastructure you don't control. Nucleus was always a platform-side service, not a self-hosted one, and its deprecation is a reminder that any resource built on top of it inherited that dependency.

What breaks when Nucleus goes away

The blast radius depends entirely on how deeply your server or resources leaned on Nucleus. At minimum, you need to audit for three categories of breakage.

The first is HTTP endpoints. If any of your server-side scripts register HTTP handlers and then expose them via a Nucleus-proxied URL, those endpoints will become unreachable. This includes anything using the `*.users.cfx.re` domain as its base URL in configuration files, documentation, or hardcoded strings inside Lua, JavaScript, or C# resource code.

The second is NUI assets. Resources that load external pages or assets through Nucleus-proxied URLs will fail silently or throw NUI errors once the proxy is gone. This is particularly common in older resources and admin UIs that were built when Nucleus was the standard way to serve browser-based interfaces inside the game.

The third is admin tools. Any web-based admin panel or monitoring dashboard that relied on Nucleus for its external-facing URL needs a new home. These tools often get set up once and then forgotten until something breaks, which makes them a high-risk category for post-deprecation surprises.

Auditing your server before you migrate

Before you touch a single config file, do a full audit. Search your entire resource directory for any string containing `cfx.re`, `users.cfx.re`, and the specific subdomain patterns Nucleus used. This means grepping through Lua files, JavaScript, JSON configs, HTML pages inside `__resource.lua` or `fxmanifest.lua` declarations, and any external config files your admin tools pull from.

Don't overlook your NUI HTML files. A resource can look clean in its server-side code but still have a hardcoded Nucleus URL sitting in a `<script src>` tag or a `fetch()` call inside a browser-side JavaScript file. These are the ones that will catch you off guard after you think you've finished the migration.

Document every hit. A spreadsheet with the resource name, file path, line number, and what the URL is doing gives you a migration checklist you can work through methodically and verify against once the work is done.

How to replace Nucleus for HTTP endpoints

The direct replacement for Nucleus-proxied HTTP endpoints is hosting them yourself. FiveM and RedM both support registering HTTP handlers natively through the `SetHttpHandler` export, and those handlers are accessible on your server's IP and the port defined in your `server.cfg` via the `sv_httpPort` convvar (default is 30120, same port as the game, but you can separate them).

If you need those endpoints to be accessible from outside your local network without exposing your server's raw IP, you have a few options:

  • Run a lightweight reverse proxy like Nginx or Caddy in front of your game server and route specific paths to your HTTP handler port. Caddy is worth considering here because it handles TLS certificates automatically via Let's Encrypt, which matters if your NUI pages need HTTPS to load correctly inside the Chromium-based NUI browser.
  • Use a dedicated VPS or cloud instance to host a small web server for asset delivery, separate from your game server entirely. This is the cleaner long-term architecture for anything serving large NUI assets.
  • For mod authors distributing resources publicly, document the migration in your resource's README and provide updated configuration examples so server owners who installed your resource aren't left debugging a broken `*.users.cfx.re` URL they didn't write.

Migrating NUI assets specifically

NUI assets deserve their own treatment because the Chromium engine inside FiveM has specific behavior around mixed content, CORS headers, and local file access. If you're moving assets from a Nucleus URL to a self-hosted server, make sure your web server sends appropriate CORS headers if the NUI page is making cross-origin requests. A bare Nginx config that doesn't include `Access-Control-Allow-Origin` will produce errors that look like network failures rather than CORS issues, which wastes debugging time.

The cleanest approach for NUI assets that don't need to be externally accessible is to bundle them directly into your resource and reference them via the `nui://` scheme or through `LoadResourceFile`. This removes the external dependency entirely and makes your resource self-contained. It's more work upfront but eliminates an entire class of future breakage.

Replacing Nucleus-based admin tools

Admin panels are the messiest part of this migration because they vary wildly by framework. If you're running txAdmin, that's already self-hosted and not Nucleus-dependent. The concern is custom admin resources or third-party tools that were configured to expose their web UI through a Nucleus URL.

For these, the migration path is straightforward in principle: point the tool at a self-hosted URL instead. In practice, this means either hosting the admin panel behind a reverse proxy with a proper domain, or running it on a VPS and locking it down with authentication and IP allowlisting. Do not expose admin interfaces to the open internet without authentication, regardless of what URL they're sitting behind.

Testing after migration

Once you've replaced every Nucleus reference and updated your configs, test in a controlled environment before pushing to your live server. Connect with a fresh client cache cleared, open the NUI browser for any affected resources, trigger HTTP endpoints manually with a tool like curl or Postman, and verify your admin panel loads and authenticates correctly.

The Nucleus deprecation is a forced cleanup of technical debt that many servers accumulated over years of convenient shortcuts. The migration is real work, but the result is infrastructure you actually control, not infrastructure that can be deprecated under you.

Know something we missed? Have a correction or additional information?

Submit a Tip
Your Topic
Today's stories
Updated daily by AI

Name any topic. Get daily articles.

You pick the subject, AI does the rest.

Start Now - Free

Ready in 2 minutes

Discussion

More GTA News