Summary
The current starter kit provides a clean base for spinning up a FiveM server with Bun, but it has no built-in story for database access, containerized development, or similar concerns yet.
This issue proposes adding the following optional flags, each of which executes a defined set of setup steps:
-
--db [<provider>] — Sets up database infrastructure for a given provider (SQLite, MySQL, PostgreSQL, etc.):
- Creates an empty database for the selected provider
- Creates a dedicated database user
- Configures environment variables and server config variables for connectivity
-
--docker [<provider>] — Depends on the --db flag. Sets up a containerized development environment:
- Generates a Docker Compose file for the configured provider
- Builds and starts the container
- Triggers the same database setup that
--db would perform, but targets the container instead
-
--orm [<provider>] — Sets up a TypeScript-based ORM project at the root of the server:
/fxserver
|_ /database ← here
|_ /scripts
|_ /server-data
- Scaffolds a new TypeScript project in
/database
- Installs the dependencies required by the selected ORM (MikroORM, Prisma, etc.)
- Optionally invokes the
--docker or --db setup for further configuration
Motivation
I've been working on personal projects like this on and off for the past four or five years. The biggest gap I see in the FiveM community is the lack of automated deployment pipelines and any real approach to database maintainability. Let's be honest — the databases across virtually every framework out there are unorganized, poorly structured, unnormalized, and difficult to maintain. These things aren't strictly required for a hobby project, and from a professional standpoint they may seem like overkill. But that's exactly the point: most people working in this space are hobbyists, and many of them — myself included — would enjoy having proper tooling to experiment with.
Possible Benefits
- Automated deployment
- Migration history for databases
- Better-structured databases overall
- Type safety within application code
Risk of Scope Creep
Features like these are nice to have, but there is a potential downside — and the main reason I'm proposing them as optional flags. They could lean too far toward replacing existing infrastructure provided by txAdmin (which, honestly, I think is lacking) and inadvertently push the project toward becoming a meta-framework. So my core question is: where do you see this project going, and to what extent should its tooling extend beyond the current scope?
Implementation Notes
When I built this out myself, I found that a resource is not a good fit for housing the database layer directly. The CFX runtimes (Lua, Node, etc.) don't expose standard filesystem or I/O APIs, so read and write operations through fs or io aren't available by default. The workaround is straightforward: place the database project outside the CFX ecosystem entirely — specifically, outside the resources folder, as shown in the directory structure under the --orm flag above. From there, it can be consumed as a local package by one or more resources. Ideally, a single resource would act as a thin wrapper, exporting functions that call into the database layer. This keeps the setup clean and ensures only one client instance is active at a time.
Summary
The current starter kit provides a clean base for spinning up a FiveM server with Bun, but it has no built-in story for database access, containerized development, or similar concerns yet.
This issue proposes adding the following optional flags, each of which executes a defined set of setup steps:
--db [<provider>]— Sets up database infrastructure for a given provider (SQLite, MySQL, PostgreSQL, etc.):--docker [<provider>]— Depends on the--dbflag. Sets up a containerized development environment:--dbwould perform, but targets the container instead--orm [<provider>]— Sets up a TypeScript-based ORM project at the root of the server:/database--dockeror--dbsetup for further configurationMotivation
I've been working on personal projects like this on and off for the past four or five years. The biggest gap I see in the FiveM community is the lack of automated deployment pipelines and any real approach to database maintainability. Let's be honest — the databases across virtually every framework out there are unorganized, poorly structured, unnormalized, and difficult to maintain. These things aren't strictly required for a hobby project, and from a professional standpoint they may seem like overkill. But that's exactly the point: most people working in this space are hobbyists, and many of them — myself included — would enjoy having proper tooling to experiment with.
Possible Benefits
Risk of Scope Creep
Features like these are nice to have, but there is a potential downside — and the main reason I'm proposing them as optional flags. They could lean too far toward replacing existing infrastructure provided by txAdmin (which, honestly, I think is lacking) and inadvertently push the project toward becoming a meta-framework. So my core question is: where do you see this project going, and to what extent should its tooling extend beyond the current scope?
Implementation Notes
When I built this out myself, I found that a resource is not a good fit for housing the database layer directly. The CFX runtimes (Lua, Node, etc.) don't expose standard filesystem or I/O APIs, so read and write operations through
fsorioaren't available by default. The workaround is straightforward: place the database project outside the CFX ecosystem entirely — specifically, outside the resources folder, as shown in the directory structure under the--ormflag above. From there, it can be consumed as a local package by one or more resources. Ideally, a single resource would act as a thin wrapper, exporting functions that call into the database layer. This keeps the setup clean and ensures only one client instance is active at a time.