Publishing a FiveM resource

A resource that works on your server is half done. A resource other people can install, configure and update without messaging you is a release. This page covers what to ship, how to version it, where to post it, and how selling works.

Before you release

Make it configurable

Put everything a server owner might change in a config.lua (shared) and, if needed, a server/config.lua for secrets like webhooks:

Config = {}

Config.Locale = 'en'
Config.Debug = false

Config.Shops = {
    { label = 'Downtown 24/7', coords = vec3(25.7, -1347.3, 29.5), blip = true },
}

Nothing hard coded that someone else would need to change: coordinates, prices, job names, item names, keys.

Support the common stacks, or say which you need

If your resource uses a framework, either put framework calls behind a bridge (see Exports and dependencies) or clearly state “Qbox only” or “ESX Legacy only”. List every dependency in fxmanifest.lua so FXServer refuses to start with something missing.

Clean up

• Remove debug prints, test commands and your own server’s paths.
• No secrets in the files: webhook URLs, API keys, license keys.
• Remove unused files and assets.
• Run it on a clean test server (fresh recipe deploy) to make sure it doesn’t depend on something only your server has.
• Check performance: resmon idle should be near 0.00 ms. See Threads and performance.
• Streamed assets: textures at sensible sizes (the forum asks you to state file sizes, polygon counts and texture sizes for models).

Ship built files

If your UI uses React, Vue or similar, include the built web/build folder in the release zip. Server owners shouldn’t need Node.js to install your resource. Keep the source in the repository for people who want to change it.

Repository layout

my_resource/
├─ fxmanifest.lua
├─ config.lua
├─ client/
├─ server/
├─ locales/
├─ web/            (source) + web/build (built UI, in releases)
├─ install/        SQL files, item definitions for each framework
├─ README.md
├─ LICENSE
└─ CHANGELOG.md

Versioning

Use semantic versioning: MAJOR.MINOR.PATCH.

• PATCH (1.2.3 to 1.2.4): bug fixes, no config changes.
• MINOR (1.2.4 to 1.3.0): new features, old configs still work.
• MAJOR (1.3.0 to 2.0.0): breaking changes (config format, database schema, events renamed).

Put the version in fxmanifest.lua (version '1.3.0'), tag the release in git (v1.3.0), and write what changed in CHANGELOG.md and the GitHub release notes. If the database schema changes, ship a migration SQL file and say so loudly.

A simple version check on start helps users know an update exists. Many resources compare GetResourceMetadata(GetCurrentResourceName(), 'version', 0) with the latest GitHub release via PerformHttpRequest. Keep it to one request on start, and let owners turn it off.

The README

A good README answers, in this order:

1. What it does, in two sentences, with a screenshot or a short video.
2. Requirements: artifact build, game build, OneSync, framework, dependencies with links.
3. Installation: exact steps. Where to put the folder, ensure order, SQL to import, items to add, convars to set.
4. Configuration: what the main config options do.
5. Exports and events other developers can use.
6. Support: where to report bugs (GitHub issues is best).
7. License.

The Script Thumbnail Creator turns your screenshots into release thumbnails for the forum, YouTube, Discord and Tebex in every size at once.

Pick a license

Without a license, nobody legally may use or change your code. Common choices in the FiveM world:

Respect the licenses of what you use: if you fork a GPL resource and distribute it, your version is GPL too. Don’t sell someone else’s free work.

Releasing on forum.cfx.re

The Releases category on forum.cfx.re is where most server owners look. Read the pinned Releases Rules and FAQ before posting. Key points from it:

• Tag the post free or paid, and escrow if the resource uses asset escrow.
• Free resources must be available through a public git repository, a direct forum upload, or a free Tebex package with escrow.
• Paid resources must be sold only through Tebex with Cfx.re’s asset delivery system.
• List the features, show them (a demonstration video is preferred over screenshots), and for models and maps give sizes, polygon counts, textures and LOD details. Paid and escrowed releases use a small table: code accessible, subscription based, approximate lines, requirements, support.
• Not allowed: requiring users to join a Discord, enter license tokens or register accounts to get or run the resource; third party encryption or obfuscation; remote code execution; IP infringement (“de-badging does not make your asset compliant”); resource packs and huge asset packs; deprecated code patterns like GetPlayerPed(-1).
• Don’t paste AI output as your description.
• You need forum trust level 1, and you can post one release every 48 hours. The first image must be uploaded to the forum so it shows as the preview.

Selling on Tebex with asset escrow

Cfx.re partners with Tebex for selling resources. The flow:

1. Create a Tebex store and link it to your Cfx.re account through the Cfx.re Portal.
2. Upload your resource to Cfx.re’s asset escrow system. Files you list under escrow_ignore in the manifest stay readable, everything else is encrypted:

escrow_ignore {
    'config.lua',
    'locales/*.lua',
    'client/open.lua',
    'server/open.lua',
}

3. Create a Tebex package that delivers that asset.
4. Buyers get the resource tied to their Cfx.re account and download it from the Cfx.re Portal. It only runs on servers whose license key belongs to that account.

Good practice for paid resources:

• Leave config, locales and framework bridge files open so buyers can adapt them.
• Say clearly what’s open and what’s escrowed.
• Offer support through a proper channel (the forum rules say you can’t require Discord to get or run the resource).
• Follow the platform rules: no selling Rockstar’s content or other people’s IP. See Requirements.

After release

• Answer issues, tag fixes as PATCH releases, keep a changelog.
• Test on new recommended artifacts and new game builds. Check our Artifacts page now and then.
• When you stop maintaining it, say so in the README (and archive the repository), so people don’t wait for fixes.