Add Cars to FiveM

How add-on cars work in FiveM

There are two ways to put a custom car on a server. A replace vehicle overwrites an existing model like adder or sultan: no new meta work, but you lose the original car. An add-on vehicle gets its own brand-new model name and spawns next to every stock car, losing nothing. Add-on is the right default for a custom vehicle, and it is what this guide covers.

An add-on car is just a FiveM resource with a specific shape. The model geometry and textures (the .yft and .ytd files) go in a folder named stream, which FiveM auto-streams to players with no manual files list. A handful of .meta data files describe the car to the game engine, and each is registered with a data_file line in the manifest. Once the resource is ensured in server.cfg, the model spawns by name like any GTA V vehicle. The same model works on ESX, QBCore, Qbox or standalone, because streaming happens at the game level, not the framework.

Step 1: get the right files

Open the vehicle you downloaded. A car built for FiveM already contains a stream folder, a data folder and an fxmanifest.lua, so you can mostly drop it in. A car built for single-player GTA V will instead be a loose set of files with no manifest, and you assemble the resource yourself. Either way you need, at minimum:

the model file mycar.yft and its textures mycar.ytd (an optional mycar_hi.yft is the high-detail LOD), plus the meta files vehicles.meta, carvariations.meta, carcols.meta and handling.meta. Note the model name (here mycar), the string inside vehicles.meta that also names the .yft. That name is what you will type to spawn it, so keep it lowercase and unique across every car on the server.

Step 2: build the resource folder

Create one folder per car inside your server's resources directory. Grouping cars in a category folder like [cars] keeps things tidy; the square brackets only group resources, they do not start them. The layout below is the shape FiveM expects, model files under stream/, meta files under data/:

resources/
└── [cars]/
    └── mycar/
        ├── fxmanifest.lua
        ├── vehicle_names.lua        -- optional, sets the in-game name
        ├── stream/
        │   ├── mycar.yft            -- the model
        │   ├── mycar_hi.yft         -- high-detail LOD (if the pack ships one)
        │   └── mycar.ytd            -- the textures
        └── data/
            └── mycar/
                ├── vehicles.meta
                ├── carvariations.meta
                ├── carcols.meta
                ├── handling.meta
                └── vehiclelayouts.meta

Folder names in stream/ and data/ are yours to choose, only the manifest paths have to match what you pick. What matters is that the model files sit somewhere inside a folder literally named stream, otherwise FiveM will not stream them and the car spawns invisible or as a default model.

Step 3: write the fxmanifest.lua

The manifest tells FiveM the resource is a modern one (fx_version 'cerulean'), that it targets gta5, and where every meta file lives. The stream folder needs no entry, it is auto-loaded, but each meta file needs both a files glob and a data_file line so the game registers it:

-- fxmanifest.lua | resources/[cars]/mycar/fxmanifest.lua
fx_version 'cerulean'
game 'gta5'

-- meta files must be declared as files{} AND as data_file lines
files {
    'data/**/*.meta',
}

data_file 'VEHICLE_METADATA_FILE'  'data/mycar/vehicles.meta'
data_file 'VEHICLE_VARIATION_FILE' 'data/mycar/carvariations.meta'
data_file 'CARCOLS_FILE'           'data/mycar/carcols.meta'
data_file 'HANDLING_FILE'          'data/mycar/handling.meta'
data_file 'VEHICLE_LAYOUTS_FILE'   'data/mycar/vehiclelayouts.meta'

-- optional in-game make + model label
client_script 'vehicle_names.lua'

A wrong data_file path is the single most common cause of a broken add-on: the resource starts with no error, but the car spawns gray, untuned or as a default model because the meta never loaded. Double-check that every path matches your data/ folder exactly.

The meta files, explained

Five data files do the real work, plus one optional label file. You rarely edit them by hand for a finished pack, but knowing what each one controls tells you exactly which file to check when something looks wrong:

Some packs also ship a vehiclelayouts.meta for custom seating and, more rarely, a carcontentunlocks.meta. Declare whatever the pack includes with its matching data_file line, and leave out the ones it does not ship rather than pointing at files that do not exist.

Step 4: set the in-game name

Without a display name the car shows up as its raw model string in menus and dealerships. The simplest fix is a one-line client script that maps the model name to a readable label with AddTextEntry. The key must match the model name in vehicles.meta:

-- vehicle_names.lua | the key must match the model name in vehicles.meta
Citizen.CreateThread(function()
    AddTextEntry('mycar', 'Custom Coupe')
end)

The alternative is a dlctext.meta registered with the DLCTEXT_FILE data_file, which many polished packs use to set both the manufacturer and the model label. Either approach is fine; pick one so the two labels do not fight.

Step 5: ensure it in server.cfg

Resources do not start on their own. Add one ensure line per car to server.cfg (or edit it in the txAdmin CFG Editor), then restart the server or run refresh and ensure mycar live from the console:

# server.cfg | start the add-on car with the rest of your resources
# a [cars] folder only groups resources, it does not start them,
# so you still ensure each car by name:
ensure mycar

If you run many cars, keep the ensure lines grouped in one block of the config so you can see at a glance which vehicles are live. Watch the server console on start: a missing file or a bad data_file path prints a warning here, which is the fastest way to catch a typo before you even join.

Step 6: spawn and test the car

The most reliable test is a raw spawn native, because it removes menus and frameworks from the equation: if this command produces the car, the install is correct. Drop it in a small client.lua (in a separate dev resource, not the car resource) and type /mycar in-game:

-- client.lua | /mycar spawns the add-on car in front of you (dev testing)
RegisterCommand('mycar', function()
    local model = GetHashKey('mycar')   -- must match the model name in vehicles.meta
    RequestModel(model)
    while not HasModelLoaded(model) do
        Wait(0)
    end

    local ped = PlayerPedId()
    local pos = GetEntityCoords(ped)
    local veh = CreateVehicle(model, pos.x, pos.y, pos.z, GetEntityHeading(ped), true, false)
    SetPedIntoVehicle(ped, veh, -1)
    SetModelAsNoLongerNeeded(model)
end, false)

GetHashKey('mycar') turns the model name into the hash the engine wants, RequestModel loads it, and CreateVehicle places it at your feet. If the car spawns and drives, ship it. If not, the troubleshooting list below covers every common failure.

Troubleshooting: invisible or default car

Nearly every add-on problem is one of these, in order of how often it bites:

Scripts to sell, deliver and store your cars

Streaming the model is only half the job: once it spawns, players need a way to get it and keep it. A FiveM car dealership script loads its catalog from a vehicles2 SQL table, so you add the model name there and players can browse it, test-drive it in a private instance and buy it straight into owned vehicles. To gate a premium add-on behind Tebex-topped currency instead, a FiveM coins shop delivers vehicles into owned_vehicles / player_vehicles and supports gifting and bundle packs. And once players own the car, a FiveM property script with instanced garages gives them somewhere to park it, persisting condition, engine health and tire state across sessions. All three work on ESX and QBCore (Var-Property is ESX).

Related: FiveM vehicle list · FiveM blips list · FiveM weapon list