Product
Why we run FleetForge single-tenant — and when you should care
Shared-database SaaS is cheaper to run. Here's why we give every leasing operator their own server, database and brand anyway, and what the trade-offs really are.
Avi Technologies · · 4 min read
Most software you rent online is multi-tenant: one big application and one big database, with every customer’s data in the same tables, separated by a customer ID on each row. It’s an efficient way to run a software business, and for plenty of products it’s the right call.
FleetForge doesn’t work that way. Every operator gets their own deployment: their own server, their own database, their own file storage, their own domain and their own branding. There’s no shared database and no “tenant” column anywhere in the schema.
That’s a deliberate choice with real costs. Here’s why we made it, and how to tell whether it matters for your business.
What “single-tenant” means in practice
For each FleetForge operator:
| Layer | What they get |
|---|---|
| Server | A dedicated application server on AWS |
| Database | Their own MySQL database, which holds only their data |
| Files | Their own storage bucket for documents, photos and backups |
| Configuration | Their own settings, integrations and credentials |
| Domain | FleetForge runs on the operator’s own website domain |
| Brand | Their name, logo, colours, letterhead and login screen |
The same codebase runs everywhere, and improvements made for one operator flow to the others. But at runtime, each deployment is its own island.
Reason 1: your data is never one bug away from someone else’s
In a shared database, isolation depends on every single query remembering to filter by customer. Get that wrong once, in one report or one API endpoint, and one company can see another’s invoices. The industry has plenty of examples.
With a database per operator, that whole class of mistake can’t happen. There is simply no other company’s data in the database to leak. For a leasing business, whose data includes customer credit applications, banking details, contracts and pricing, that’s not a theoretical concern.
The safest cross-customer query is the one that can’t be written, because the other customer’s data isn’t there.
Reason 2: white-label means really white-label
Leasing operators put FleetForge in front of their own customers: the customer portal, invoices, statements, payment pages and emails. Those need to look like the operator’s business, not ours.
Each deployment has a Settings → Design page where the operator controls:
- company name, logo and favicon,
- primary and accent colours,
- PDF letterhead on invoices, contracts and statements,
- the login screen background, including video,
- the footer and contact details.
And because it runs on their own domain, customers sign in at the operator’s address, not a shared portal with a dropdown of company names.
Reason 3: one operator’s busy day doesn’t slow down another
On shared infrastructure, a big month-end billing run for one customer competes for the same database as everyone else’s. With separate deployments, Mainland’s invoice run can’t slow Northland down, and vice versa. Scheduled jobs run on each operator’s own timetable, and each can be switched on or off from that operator’s settings.
Reason 4: backups and restores are yours
Each deployment is backed up on its own: database snapshots to cloud storage every six hours, plus an off-site copy in Dropbox, with versioned file storage. Restoring an operator’s data never means carefully extracting their rows from a shared backup. It’s their database, restored on its own. An administrator can even trigger a restore from inside the app.
Reason 5: integrations stay separate
Every operator connects their own QuickBooks Online company, their own Samsara account, their own email sending domain and their own payment set-up. Credentials never sit in a shared store alongside other businesses’ keys, and one operator’s integration problems never touch another’s.
The honest trade-offs
Single-tenant isn’t free, and anyone who says otherwise is selling something.
| Multi-tenant | Single-tenant (FleetForge) | |
|---|---|---|
| Running cost per customer | Lower | Higher: a server and database each |
| Data isolation | Depends on code discipline | Built into the architecture |
| Branding | Usually a logo on a shared app | Full white-label on your domain |
| Performance | Shared with everyone | Your own capacity |
| Rolling out updates | One deploy for all | One deploy per operator |
| Customisation | Limited | Possible per operator |
The two costs that matter most are running cost and update logistics. We handle the second with a one-command deploy: it switches the operator into maintenance mode (with an exception for staff testing), pulls the release, runs database migrations and brings the app back. Each deployment updates on its own, so one operator can trial a new release before it reaches the next.
When you should care
Single-tenant is worth it when some of these are true:
- You hold sensitive customer data: credit applications, banking details, signed contracts.
- Your brand matters to your customers, and the software is part of their experience of you.
- You need your own integrations with your own accounting, telematics and payments.
- You’re a regional operator who wants to own your data and your set-up, not be one row among thousands.
If you’re a five-person team that just needs a shared to-do list, you don’t need any of this. If you’re running a leasing business with hundreds of units and real money moving through it every month, you probably do.
What this means for you
FleetForge runs this way at both of its live deployments, and new operators get the same: their own isolated, white-labelled deployment on AWS, set up and maintained by us. See the platform in detail, or get in touch to talk about running it for your fleet.
