FIVEMFIVEM HOUSINGPS-HOUSINGQB-HOUSESQS-HOUSINGOX_PROPERTYQBCOREESXFIVEM SCRIPTSROLEPLAY April 14, 2026 · 11 min read

Best FiveM Housing Scripts for RP Servers

A housing script is one of those pieces of your server that either disappears into the background and just works, or becomes a support ticket factory for the next six months. I’ve installed most of the major options on client servers and on my own test boxes, and the differences between them get ugly fast once you have 40 players all trying to furnish apartments at the same time.

Here’s the honest breakdown of the FiveM housing scripts actually worth running in 2026, what each one is good at, and the specific ways each one can wreck your database if you’re not paying attention.

What Makes a FiveM Housing Script Actually Good

Before you pick one, get clear on what you’re grading. A housing script is not a fancy door menu. It’s a system that touches your inventory, your furniture system, your garages if you have shared storage, your permissions, and your database — usually all at once.

The stuff that actually matters: idle resmon cost, how cleanly it creates and destroys interiors (MLO vs shell), database schema sanity, whether it supports furniture that persists across restarts, permission systems for keys and realtors, framework compatibility, and whether it handles dozens of concurrent instanced interiors without stuttering.

Pretty screenshots do not matter. I’ve seen gorgeous housing scripts choke the server every time a player zones into their shell because the dev stuffed every furniture spawn into a single loop. If you’ve never measured this stuff, read the resmon guide before you buy anything — you cannot evaluate a housing script without knowing how to measure one.

ps-housing — The Community Standard for QBCore

If you’re on QBCore or Qbox, ps-housing by Project Sloth is the script most servers end up running. It’s free, actively maintained, and built on top of ps-ui which keeps the look consistent with other Project Sloth resources people already use.

What it does right: shell-based interiors so you’re not dependent on MLO mod servers, clean realtor/offer-to-buy flow, decent permissions for keys and co-owners, stash and outfit storage per house, and a furniture system that persists. The schema is reasonable and the exports are documented well enough that your devs can extend it without reverse-engineering the whole script.

The downsides are real. It’s QBCore-first, and while ESX forks exist, they range from barely working to abandoned. Shell loading has a noticeable flicker on lower-end clients when you enter and exit. The furniture UI is functional but not pretty, and once a player puts 80 items in a house you’ll feel the NUI slowdown when they open the placement menu.

Verdict: If you’re on QBCore or Qbox and you don’t want to pay, this is the pick. Don’t fight it.

qb-houses and qb-apartments — The Default Duo

qb-houses (sometimes paired with qb-apartments for starter spawns) is what ships close to default on a lot of QBCore installs. It works, it’s free, and it’s dead simple.

The catch is scope. qb-houses handles the property ownership, garage link, and stash per house, but there’s no built-in furniture system, no co-owner keys beyond a flat key table, and the realtor flow is the most basic version of “assign a player a house.” For a low-population server where ownership matters more than decoration, that’s fine. For a server where people actually want to decorate and invite friends, it’s thin.

Most servers that start on qb-houses migrate to ps-housing or a paid option within a year. The migration is painful because the database schemas don’t line up cleanly, and you either lose player data or write a custom migration script.

Verdict: Use it if you’re standing up a server this week and need something working. Plan to replace it.

qs-housing by Quasar — The Paid QBCore Option

qs-housing is Quasar’s paid housing script, and if you’ve bought any Quasar resource before, you know what to expect: polished UI, solid NUI performance, and a price tag that makes you think twice. It supports QBCore, Qbox, and has ESX adapters.

What’s genuinely good: the furniture system is the best-looking of the major options, placement is grid-aware and rotation-friendly, permissions are granular (keys, temporary access, family accounts), and realtor management actually has tooling instead of just SQL edits. Integration with qs-inventory is seamless if you’re already in that ecosystem.

What’s not so good: if you don’t run other Quasar resources, you’re paying premium price for something that overlaps less cleanly with your stack. Some servers complain about update cadence — fixes ship, but documentation lags. Also, the shell list is curated, so if you want some obscure MLO as a house interior, you’re editing configs yourself.

Verdict: Strong pick if you’re already running Quasar inventory or phone. Otherwise, weigh it against loaf and ps-housing.

loaf_housing — Polished Paid Option for ESX and QBCore

loaf_housing is the one I see on a lot of mid-to-high population ESX and QBCore servers. It’s paid, it’s clean, and it avoids a lot of the jank that plagues the free options.

The UI is modern, the placement system has snapping and layers, and the permission model handles roommates, visitors, and time-limited access. Framework support is broad — ESX Legacy, QBCore, and Qbox are all first-class, not afterthought ports. Performance is good, idle cost is minimal, and shell transitions feel less stuttery than ps-housing on low-end clients.

Where it falls short: the default shell catalog is modest, so you’ll end up buying or configuring additional shells to match your server’s aesthetic. The furniture catalog is solid but not massive, and adding custom furniture requires some config work that’s not zero-effort. Also, it’s not cheap.

Verdict: Best cross-framework paid option right now. Pick this if you’re on ESX and want a real housing experience.

ox_property — The Overextended Take

ox_property is the Overextended team’s housing system, built to integrate with ox_core, ox_inventory, and the rest of that ecosystem. If you’re already on ox_core, this is the path of least resistance.

It’s structurally different from ps-housing and loaf. It leans heavily on zones and permissions rather than shells-as-containers, which means the code is cleaner and easier to extend, but the out-of-the-box experience is sparser. You’re more likely to build exactly what you want and less likely to get a turnkey housing solution.

Performance is excellent — Overextended’s stuff always is. Documentation is a mixed bag, and the community around ox_property is smaller than ps-housing, so Googling your problem is less productive.

Verdict: Great if you’re all-in on the ox stack and have devs who can build. Rough if you want it to just work.

Renewed Housing and the Long Tail

There’s a long tail of housing scripts — Renewed Housing, bl-housing, bcs_housing, bm_housing, and random Tebex one-offs. Some of them are fine. A few are great for specific niches.

My rule with the long tail is the same as with phones: if the script doesn’t have at least six months of update history, or if the developer isn’t actively responding in their Discord, don’t buy it. Housing data is one of the hardest things to migrate out of, so locking yourself into an abandoned script is a six-month problem you’ll regret daily.

The Resmon Numbers That Actually Matter

Here’s a rough idea of what to expect on a stock install, no one inside a house, measured with resmon 1:

qb-houses:        0.01 - 0.03ms idle, 0.1 - 0.2ms active
ps-housing:       0.02 - 0.05ms idle, 0.3 - 0.6ms active
qs-housing:       < 0.02ms idle,       0.2 - 0.4ms active
loaf_housing:     < 0.02ms idle,       0.2 - 0.5ms active
ox_property:      < 0.01ms idle,       0.1 - 0.3ms active

These are ballpark numbers from my own testing, not gospel. Active cost spikes when multiple players are entering and exiting interiors at once, so test under realistic load. The resmon guide walks through how to do that properly.

The Database Reality Nobody Warns You About

Most housing scripts store furniture as serialized JSON inside a single column. That’s fine until a player puts 200 items in their house and their insert-or-update starts triggering slow query warnings.

Here’s the kind of schema you’ll see in something like ps-housing:

-- Typical ps-housing furniture column
CREATE TABLE IF NOT EXISTS `properties` (
    `property_id` INT AUTO_INCREMENT PRIMARY KEY,
    `owner_citizenid` VARCHAR(50),
    `street` VARCHAR(100),
    `description` TEXT,
    `furnitures` LONGTEXT,       -- JSON blob of all furniture
    `for_sale` TINYINT(1) DEFAULT 1,
    `price` INT,
    `shell` VARCHAR(50),
    INDEX `idx_owner` (`owner_citizenid`)
);

The furnitures column is the problem. Every time a player places or moves an item, the script rewrites the entire JSON. Do not trust a housing script that doesn’t batch these writes or debounce them. If you see inserts firing on every single furniture move in your MySQL general log, you’ve found your next server stutter.

Here’s the pattern you want your housing script to use — bad version first:

-- Bad: writes to DB on every furniture move
RegisterNetEvent('housing:moveFurniture', function(id, coords)
    local src = source
    MySQL.update('UPDATE properties SET furnitures = ? WHERE property_id = ?', {
        json.encode(getAllFurniture(id)),
        id
    })
end)

-- Good: debounce writes, only persist on meaningful boundaries
local pendingWrites = {}
RegisterNetEvent('housing:moveFurniture', function(id, coords)
    pendingWrites[id] = os.time()
end)

CreateThread(function()
    while true do
        Wait(15000)  -- batch every 15 seconds
        for id, _ in pairs(pendingWrites) do
            MySQL.update('UPDATE properties SET furnitures = ? WHERE property_id = ?', {
                json.encode(getAllFurniture(id)),
                id
            })
            pendingWrites[id] = nil
        end
    end
end)

Also persist on property exit and on server shutdown so you don’t lose a minute of player edits if the server crashes. Any housing script worth paying for already does this — and if you’re auditing a free one, this is the first thing I’d look at.

What I’d Pick In 2026

If you’re on QBCore or Qbox and you want free: ps-housing. It’s the community standard for a reason.

If you’re on ESX and you want free: honestly, there isn’t a great free option anymore. The ESX forks of ps-housing are inconsistent. Scrape together the cash for loaf_housing.

If you’re on any framework and you have money: loaf_housing if you want broad compatibility, qs-housing if you’re already in the Quasar ecosystem.

If you’re all-in on ox_core and you have devs: ox_property. You’ll build a better experience than anything turnkey, but you’re doing the work.

Pairing Housing With The Rest Of Your Server

Housing on its own doesn’t retain players. What retains players is giving them reasons to be in the house and reasons to have friends over. That means furniture variety, media integration, and tight hooks into your economy loop.

Media integration is the big one. Players spend hours in their apartments with friends — if there’s nothing to do in there but stand around, the novelty dies in a week. Something like LMX TV/Cinema Builder slots into any housing script to give players actual media in their apartments, which turns the house from a storage unit into a hangout spot. On the economy side, scripts like LMX Trap & Stores give stash-based interactions that make house storage feel meaningful rather than just a bigger inventory slot. Free alternatives exist — check free scripts — but audit them for performance before committing.

If you’re trying to build the full economy picture around housing, the make money on a FiveM server post covers monetization without pay-to-win, and the best FiveM scripts of 2026 post lists the full stack most serious servers are running.

Installation Reality Check

No matter which housing script you pick, installation takes longer than the readme claims. Plan a full day if it’s your first time. You’ll be importing SQL, configuring framework integration, mapping item names to your inventory’s naming scheme (this is where most installs break), adding the housing item to your item list, testing shell spawns on every interior, and seeding your realtor NPC locations.

If you’ve never installed a script before, the FiveM script installation guide walks through the general process. Housing is on the harder end of that spectrum because it touches inventory, money, garages, and zones all at once.

Test with at least two players before you go live. Buy a house, furnish it, give the second player a key, have them enter, move furniture, steal from the stash, leave, restart the server, and verify everything persisted correctly. Single-player testing will lie to you about co-owner and persistence bugs every time.

Still Stuck On Which To Pick

If after all this you’re still on the fence, hop into our Discord and tell me your framework, your player count, and your budget. I’d rather spend five minutes telling you “loaf is overkill for your 16-slot server, run ps-housing” than watch you spend $60 on a script your server doesn’t need yet. Housing is a script you want to pick once and forget about — get it right the first time.

YBN
YBN Scripts
FiveM script developer at YBN. Building premium ESX, QBCore & Qbox resources.

Related Posts

Need scripts for your server?

Check out our premium FiveM resources — ESX, QBCore & Qbox supported.

Browse Premium Scripts → Free Scripts →