Loading article…
How to Configure fileserver_add and adhesive_cdnKey in FiveM
Configure FiveM resource downloads with fileserver_add and adhesive_cdnKey, verify the cache path, and avoid common server.cfg mistakes.
Configure FiveM resource downloads with fileserver_add and adhesive_cdnKey, verify the cache path, and avoid common server.cfg mistakes.
Loading article…
FiveM uses fileserver_add to send resource-download requests through an external file server or cache proxy. adhesive_cdnKey supplies the shared secret used for that delivery path.
With FiveMesh Cache, the dashboard generates both lines for the selected server. Copy them together, keep the key private, restart through your normal deployment process, and verify the first cold download before assuming the setup is complete.
A FiveMesh Cache configuration follows this shape:
fileserver_add ".*" "https://cache.fivemesh.io/YOUR_SERVER_ID/files"
adhesive_cdnKey "YOUR_SECRET_KEY"
Do not copy these placeholder values into production. The Cache dashboard provides the URL and secret for the server you registered.
The ".*" pattern matches every resource name. The URL tells FiveM where those resource files should be requested. The URL should not end with an extra slash.
The key is not a public identifier. Treat it like a credential: keep it in server-side configuration, do not paste it into client scripts, and do not publish it in screenshots or a public repository.
fileserver_add associates a resource-name pattern with an external file-server URL.
When a player connects and needs the server's current resources, FiveM can request the files through that URL instead of making FXServer deliver every byte directly. With a managed cache in that path, the cache can fetch a missing version from the origin and reuse it for later matching requests.
The command changes the connection resource path. It is not a general redirect for every file used by your community.
Read FiveM CDN vs Cache Proxy: What's the Difference? if you are unsure which service owns a file.
adhesive_cdnKey sets the shared secret used by the FiveM resource-delivery flow.
The key belongs to the configured server and cache path. A typo, stale key or key copied from another server can prevent the expected cache flow from working. Keep the generated fileserver_add and adhesive_cdnKey values together when moving configuration between environments.
Avoid defining the key several times across server.cfg, nested exec files and hosting-panel settings. The last active value may not be the one you intended to use.
Connect the production server to the intended FiveMesh workspace. If you operate development and production environments, confirm which server ID you selected before copying the setup block.
Open the Cache dashboard and use the generated values. Copy both lines without changing the server ID, URL path or secret.
Search your active configuration files for older fileserver_add and adhesive_cdnKey entries. Keep one deliberate configuration for the resource pattern unless you are intentionally operating a more advanced multi-pattern setup.
Place the generated block in the configuration executed by the intended FXServer instance. Do not put the secret in a client resource, NUI bundle or public environment file.
Use your normal restart or deployment process. Test with a client that does not already have the current resource versions, because a warm local FiveM cache can hide an incorrect server-side path.
The first request for a resource version may be a MISS. That is expected: the cache needs to fetch the valid file from the origin before later players can receive a HIT.
The FiveM Cache HIT vs MISS guide explains what to expect after updates and why repeatedly purging the cache makes the result harder to evaluate.
Verification should cover the player experience and the infrastructure path.
Do not rely only on whether one player eventually connected. A direct-origin fallback, local client cache or previously downloaded resource can make an incomplete setup look healthy.
The file-server URL should end at /files, not /files/. Use the generated value exactly.
Each registered server has its own context. Label production and development environments clearly and avoid moving an old setup block without checking it.
Do not place the secret in a repository, client-side Lua or JavaScript, a public support message, or a screenshot. Rotate it if it has been exposed.
A MISS means the cache did not already hold that exact version. An origin error means the requested file could not be fetched successfully. They are different conditions.
A client that already has the resource does not exercise the complete download path. Include a controlled cold-cache test when verifying a new configuration.
Cfx.re also documents sv_httpFileServerProxyOnly for advanced deployments that restrict the FXServer file endpoint to configured proxy IP ranges. Do not enable it casually: the matching proxy ranges and network path need to be correct first. See the current Cfx.re server command documentation for that separate control.
Rotate adhesive_cdnKey when it has been exposed or when your credential policy requires it.
Generate the replacement from FiveMesh, update the server-side configuration, confirm old duplicate definitions are gone, then restart through your normal process. Test the cold resource path again and watch for origin errors.
Plan the change for a controlled window. Updating the dashboard value without updating FXServer, or updating only one of several server instances, creates a mismatch that is harder to diagnose than a planned restart.
FiveMesh Cache generates the fileserver_add URL and adhesive_cdnKey for each registered server, then exposes HIT, MISS, bandwidth, latency and origin behavior from the dashboard.
Use the FiveMesh Cache setup documentation for the current dashboard workflow. For the broader reason behind this architecture, read FiveM Downloads Slow? When a Cache Proxy Helps.
The configuration is only two lines, but the verification matters. Copy the correct values, keep the secret private, test a cold client, and judge the cache from the requests that follow—not from one isolated MISS.