How banner_detail and banner_connecting actually work in server.cfg

Both FiveM banners are convars, not uploads. You put a line in server.cfg pointing at a URL, the server replicates that value to every connecting client, and the client fetches the image itself. That design is why the banners are free to host wherever you like, and also why there are four separate ways to get it wrong, each of which produces the same symptom: nothing appears.

The two lines

sets banner_detail "https://cdn.example.com/velora/detail-v3.png"
sets banner_connecting "https://cdn.example.com/velora/connecting-v3.png"

banner_detail is the 1865x108 strip drawn across the top of your server's detail panel in the server browser. banner_connecting is the 1920x320 band drawn on the connecting dialog while a player joins. They are independent, they take different sizes, and setting one does not affect the other. Put them anywhere in server.cfg; convar order does not matter.

Reason one: set instead of sets

This is the most common failure and the least obvious, because the server starts without complaining. FiveM has three convar-setting commands and they differ in who can see the value.

The banners have to be readable by the client, because the client is what fetches the image. A plain set stores the value server-side and the client never learns about it, so the panel renders with no banner and nothing in the console suggests why. If your banner is not showing and you have not checked this, check this first.

Reason two: the URL is not an image

The client performs a plain HTTP GET and expects image bytes back. A surprising number of URLs that look like images are not. A link to a Discord message attachment page, an Imgur gallery URL, a Google Drive sharing link and a Dropbox share link all return HTML containing a reference to the image, not the image. The client gets a document, fails to decode it and shows nothing.

The test is quick: open the URL in a private browser window. If you see the image on a white background with nothing else, and the address bar still shows the same URL, it is a direct image. If you see any page furniture, or the URL changed, it is not.

Discord CDN links deserve a specific warning. They used to work and many guides still recommend them. Discord now appends signed expiry parameters to attachment URLs, so a link that works today returns a 403 in a matter of days or weeks. A server whose banners vanished without anybody touching server.cfg is almost always a server using Discord attachment URLs.

Reason three: HTTP rather than HTTPS

Use HTTPS. Plain HTTP fetches are unreliable from the client and there is no reason to host an image over HTTP in the first place. Any static host will give you a certificate for nothing, and if you are serving from your own box, a reverse proxy with an automatic certificate takes ten minutes to set up once and then never needs touching.

A related trap: a URL that redirects from HTTP to HTTPS is not the same as an HTTPS URL. Write the HTTPS URL in the convar directly rather than relying on a redirect, because the fetch does not necessarily follow one.

Reason four: the client cache

This is the one that costs people an afternoon. The FiveM client caches banner images aggressively and does not revalidate them on a schedule you can predict. If you overwrite detail.png on your host with new artwork, a player who has already opened your detail panel keeps seeing the old image, potentially for a very long time. You will see the new one because you cleared your own cache while testing, which makes the problem look like it is fixed when it is not.

The fix is to never overwrite a banner file. Version the filename, update the convar and restart:

sets banner_detail "https://cdn.example.com/velora/detail-v4.png"

Keep the old files on the host rather than deleting them, so clients mid-session that still hold the old URL get a 200 rather than a 404. Costs you a few kilobytes and saves a confusing week.

Where to host the files

The requirements are small: HTTPS, a stable URL, and a host that will not rate-limit you when a few thousand clients fetch the same file. That rules out personal Discord servers and most free image hosts, and leaves a lot of good options.

• An object storage bucket with a public prefix, such as Cloudflare R2 or an S3-compatible bucket, with a custom domain in front of it. This is the cheapest reliable answer and costs effectively nothing at this traffic level.
• Your existing website or web store, if it has one, in a static directory. Already has a certificate, already has a domain.
• A static site host, pointing a small repository at it. Free tiers cover this comfortably.
• Your game server box behind a reverse proxy, if you already run one for a web panel. Works, but ties your banners to your game server's uptime, which is the one thing you do not want them tied to.

Set long cache headers on the files deliberately. Since you are versioning filenames anyway, a one-year immutable cache header is correct and reduces the number of fetches your host sees to roughly one per player.

Animated banners

Both convars accept a GIF at the URL, and an animated banner is a genuine differentiator in a list where most entries are static. There are two things to weigh.

The first is size. Every client that opens your panel downloads the file, and every client that joins downloads the connecting banner. A GIF large enough to look good at 1865x108 is a few megabytes; one encoded carelessly is twenty. Keep the frame count modest, keep the palette tuned to the scene rather than full, and check the resulting file size rather than assuming. Six seconds at 24 frames a second is 144 frames, which is already a lot of data at that width.

The second is that you should host a still as well, at its own versioned URL, even if you are serving the animation. It costs nothing to keep around and it means switching back is a one-line change rather than a re-render, which matters if you ever need to cut your host's bandwidth in a hurry.

Verifying it worked

1. Restart the server after changing the convars. A convar change does not propagate to clients that are already connected.
2. Open the URL in a private browser window and confirm you get the bare image.
3. Find your server in the browser, open the detail panel, and check the strip appears.
4. Connect and watch the connecting dialog for the 1920x320 band.
5. Ask somebody who has never joined your server to check both, because your own client's cache is not representative.

That last step is the one people skip and it is the only one that actually tests the thing you changed. Your own client has every version of your banner you have ever shipped sitting in its cache. A friend's client has none of them, which is the state every new player is in.

One more convar worth setting

While you are in server.cfg, the two text convars that appear beside your banner in the browser are worth getting right at the same time:

sets sv_projectName "Velora Roleplay"
sets sv_projectDesc "Whitelisted EU roleplay. discord.gg/veloracity"

The description is the line underneath your name in the detail panel, next to the strip. A banner carrying your invite and a description that repeats it is not redundant, it is the invite being readable both to somebody skimming the list and to somebody who can only see the picture.