> For the complete documentation index, see [llms.txt](https://docs.cuxial.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cuxial.com/scripts/core/cuxial-garages/installation.md).

# Installation

Install Cuxial Garages step by step: dependencies, inventory items, start order and sample data.

Cuxial Garages creates its own tables on first start. The only manual work is adding the inventory items and removing the garage and key resources it replaces.

{% stepper %}
{% step %}

## Check the dependencies

These resources must be installed and working first:

* `ox_lib`
* `oxmysql`
* `cuxial_bridge`, with one of the supported frameworks: QBox, QBCore or ESX
* OneSync enabled on the server
* `ox_inventory`, for the key, lockpick and rental contract items

The rest are optional integrations. Each one is detected when it is running: `ox_target`, `cuxial_gang`, `cuxial_police`, `cuxial_license`, `cuxial_fuel`, `lb-phone`, `jg-dealerships` and `rahe-speakers`. `jg-dealerships` and `rahe-speakers` also need `finance.enabled = true` and `speakers.enabled = true` in `shared/config.lua`. The [overview](/scripts/core/cuxial-garages.md#requirements) says what each one adds.

{% hint style="info" %}
On ESX the resource adds the columns `id`, `model`, `state`, `garage`, `depotprice` and `mileage` to `owned_vehicles` on first start. On QBox and QBCore it uses `player_vehicles` as it is.
{% endhint %}
{% endstep %}

{% step %}

## Copy the resource

Place the `cuxial_garages` folder inside your `resources` directory. Keep the folder name as it is.
{% endstep %}

{% step %}

## Remove what it replaces

Delete or comment out every other garage resource and every other vehicle key resource:

{% code title="server.cfg" %}

```cfg
# your previous garage resource
# ensure qbx_vehiclekeys
```

{% endcode %}

{% hint style="danger" %}
Stop `qbx_vehiclekeys` before starting Cuxial Garages. Cuxial Garages registers its exports `GiveKeys`, `HasKeys` and `RemoveKeys` itself, so scripts that call them keep working.
{% endhint %}
{% endstep %}

{% step %}

## Add the items

Paste this block into `ox_inventory/data/items.lua`, inside the `return { }` table:

{% code title="ox\_inventory/data/items.lua" %}

```lua
['vehiclekeys'] = {
    label = 'Vehicle keys',
    weight = 100,
    stack = false,
    close = true,
    description = 'Key of one specific vehicle.',
    client = {
        image = 'vehiclekeys.png',
    },
},

['rentalticket'] = {
    label = 'Rental contract',
    weight = 10,
    stack = false,
    close = true,
    description = 'Contract of a rented vehicle. Use it to see the receipt.',
},
```

{% endcode %}

Then copy `install/vehiclekeys.png` and `install/rentalticket.png` to `ox_inventory/web/images/`.

{% hint style="warning" %}
`stack = false` is required on both. Each key and each contract carries its own data (plate, ticket code). Stacked items get mixed and lose the vehicle they belong to.
{% endhint %}

The lockpick items `lockpick` and `advancedlockpick` come with `ox_inventory` by default. Add them if your install does not have them.

Item names can be changed, as long as they match the config:

| Item                           | Where it is set                                                    |
| ------------------------------ | ------------------------------------------------------------------ |
| `vehiclekeys`                  | `data/keys.lua` → `item`                                           |
| `lockpick`, `advancedlockpick` | `data/keys.lua` → `lockpick.normal.item`, `lockpick.advanced.item` |
| `rentalticket`                 | `data/rental.lua` → `ticketItem`                                   |
| {% endstep %}                  |                                                                    |

{% step %}

## Set the convars

Both are optional.

{% code title="server.cfg" %}

```cfg
# Language of notifications, prompts and command help (en and es are included)
setr ox:locale "en"

# Debug traces in the console
setr cuxial_garages_debug "0"
```

{% endcode %}

{% hint style="info" %}
The language of the interface is set separately, with `language` in `shared/config.lua`. Set both to the same language.
{% endhint %}
{% endstep %}

{% step %}

## Start the resource

Start it after its dependencies, your framework and the optional integrations you use:

{% code title="server.cfg" %}

```cfg
ensure ox_lib
ensure oxmysql
# your framework here (qbx_core, qb-core or es_extended)
ensure ox_inventory
ensure cuxial_bridge
ensure cuxial_garages
```

{% endcode %}

No SQL to run. On first start the resource creates `cuxial_garages`, `cuxial_garages_meta`, `cuxial_garages_impound`, `cuxial_garages_rental` and `cuxial_garages_rentals`, and prints a line that starts with `[cuxial_garages][mysql]` in the server console.
{% endstep %}

{% step %}

## Give yourself staff access

The admin panel checks the permission in `admin.permission` (`'admin'` by default) through your framework. `/adminkey`, `/carwipe` and `/cancelwipe` also need the ACE group `group.admin`:

{% code title="server.cfg" %}

```cfg
add_principal identifier.license:xxxxxxxxxxxxxxxx group.admin
```

{% endcode %}

Details in [Commands & permissions](/scripts/core/cuxial-garages/commands.md#permissions).
{% endstep %}

{% step %}

## Import the sample data (optional)

A new install has no garages. Create them from the panel, or import the examples in `install/` to start from a populated map:

| File                 | Installs                                                                                                    |
| -------------------- | ----------------------------------------------------------------------------------------------------------- |
| `garages_public.sql` | Six public garages: Legion Square, Del Perro Pier, Sandy Shores, Paleto Bay, a marina and an airport hangar |
| `garages_jobs.sql`   | One job garage: the Mission Row police, with a fleet of base-game vehicles                                  |
| `impounds.sql`       | Impound depots                                                                                              |

Import them after the first start, when the tables exist, then restart the resource. They can be imported again without creating duplicates. Job names and fleets in these files are examples: adjust them in the panel.

Rental points have no sample file. They are created from the panel.
{% endstep %}

{% step %}

## Check that it works

1. Join the server and type `/garageadmin`. The panel opens.
2. Create a public garage and place its access point and parking spots in game.
3. Walk to the marker and press <kbd>E</kbd>. The garage opens with your vehicles.
4. Take a vehicle out. A key with its plate arrives in your inventory and <kbd>L</kbd> locks it.
5. Drive back to the marker and press <kbd>E</kbd>. The vehicle is stored and the key is removed.
   {% endstep %}
   {% endstepper %}

Next: adjust the script to your server in [Configuration](/scripts/core/cuxial-garages/configuration.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.cuxial.com/scripts/core/cuxial-garages/installation.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.