BookCars is a MERN car rental platform with supplier, admin and mobile sides

What BookCars is and who it is for

BookCars is a car rental platform with an admin panel for managing fleets and bookings, a frontend and a mobile app for renting cars. The primary language is TypeScript, the licence is MIT, and the repository topics name react, react-native, mongodb, stripe, paypal and mern.

The audience is a business that rents cars and wants to run it as a marketplace rather than as a single fleet. The README is explicit that it supports both single-supplier and multi-supplier modes, and that suppliers can manage their fleets and bookings through a dedicated admin panel. Each new supplier receives an email prompting them to create their account and gain access to the system, which is the onboarding flow for an aggregator model where several independent suppliers sell through one storefront.

The customer side is a web frontend and a mobile app. Customers can register through either, search for available cars based on pickup and drop-off points and time, choose a car and complete checkout in a few clicks. The README lists iOS, Android, Web and Docker as supported platforms, and the feature list notes a native mobile app for Android and iOS from a single codebase.

The admin panel covers the catalogue and the commercial side: admins manage suppliers, cars, countries, locations, parking spots, customers, bookings and payments. That last item, parking spots, tells you the domain model is detailed enough to model a real airport or city location rather than a generic pickup address.

The project also ships a documentation wiki with an overview, an install guide for self-hosting and a separate one for Docker, a price calculation page, a rental date and time constraints page, a payment gateways page and an FAQ. The presence of a price calculation page as a first-class document is a good sign about where the complexity lives.

The repository layout tells you it is three applications

The top level of the repository shows the structure, and it is worth reading because it tells you what you are adopting.

There is an admin directory, a frontend directory and a mobile directory, which are the three deployable applications: the operator's admin panel, the customer-facing web app, and the React Native app. A backend directory holds the API, and it is the backend that owns the seeding scripts, since the root package.json delegates with npm --prefix backend run seed:dev and npm --prefix backend run clean:dev. There is also a packages directory, which in a monorepo layout usually holds code shared between those applications rather than duplicated in each.

Alongside those are directories with names that read like a template generator rather than application code: __config__, __scripts__ and __services__. The underscores are a convention used by scaffolding tooling to mark directories that are copied into a new project, and their presence together with the releases.js file and a __config__ directory suggests the repository doubles as the source for generating new deployments.

The build tooling is at the root. eslint.config.js for linting, a pre-commit.js script wired into husky through the prepare hook, a codecov.yml for coverage reporting, and docker-compose.yml with docker-compose.dev.yml for the two deployment shapes. There are llms.txt and llms-full.txt files at the root, which are the conventional files that let a language model read the repository documentation, a small but telling detail about a project that expects to be explored by automated tools.

The version numbers tell a similar story about scale. The root package.json reads 8.9.0 while the most recent tagged release listed for the project is v8.8, and the previous tags are v8.7 and v8.6, so the main branch runs slightly ahead of the last release. The last push was on 2026-10-19 and the repository is not archived.

Pricing is the part that needs the most of your attention

The feature list gives dynamic price calculation with hourly, daily, weekly, bi-weekly and monthly rates, date-based price rates and a price change rate. On its own that is a list, but the fact that the wiki carries a dedicated price calculation page and a separate page on rental date and time constraints tells you these are the two areas where the domain gets complicated.

Multi-period pricing is the part that trips implementations up. A rental that starts at 10am on a Tuesday and ends at 2pm on the following Friday touches an hourly rate, then a daily rate, then weekly rates, and the question of whether the week is charged as seven days or as the remaining partial period depends on rules you have to define. A price change rate then applies to a base price rather than a fixed one, which is how a supplier expresses a seasonal or dynamic adjustment.

Date and time constraints are the second half of that. A car is available if it is not booked, and availability is not just a date range, it is a time range within a date. The feature list mentions flexible time-based car availability and flexible rental date and time constraints, and the customer search is explicitly by pickup and drop-off points and time. A booking system that only tracks dates will let two bookings overlap at 09:00 and 11:00 on the same day unless the conflict logic is written in terms of intervals.

Neither of those two pages is reproduced in the README, so the rules themselves are not visible here. That is the honest gap: the platform gives you the mechanism for multi-period pricing and interval-based availability, and the actual commercial rules are in the wiki, where you need to read them before you trust a computed total.

Seeding a local database with fixtures and known accounts

The development database quick start is a recent and useful addition, and it is documented well enough to follow exactly.

# Seed development database (idempotent)
npm run seed:dev

# Clean development database (safely removes only seed-owned records)
npm run clean:dev

The two properties are the important part. The seed is idempotent, so running it twice does not double your data, and the clean removes only seed-owned records, so it will not delete bookings or accounts you created by hand while testing. Both scripts delegate to the backend workspace.

The fixture set is described as complete, and it names what is included: admin, suppliers, customers, locations, cars, bookings and notifications. The README also points to DEVELOPMENT_SEEDING.md for the full contributor documentation and what it calls the safety guarantees.

The sample credentials are published in the README, which is normal for a development seed and is also the thing to be careful about:

| Role | Email | Password | Access Level & App URL | |---|---|---|---| | Admin | `[email protected]` | `B00kC4r5` | Admin Panel (`http://localhost:3001/`) | | Supplier | `[email protected]` | `B00kC4r5` | Supplier Admin Panel (`http://localhost:3001`) | | Customer | `[email protected]` | `B00kC4r5` | Frontend App (`http://localhost:3002`) |

The admin panel runs on port 3001 and the customer frontend on 3002 in this setup. The seed exists to give a new contributor a working system with data in it on the first day, which is a genuinely useful thing to have.

Docker deployment with MongoDB, Redis and a replica set

The compose file shows the intended production shape, and it is a conventional but complete one.

MongoDB is the datastore, on image mongo:7.0.12, and the command is not the default one. It generates a keyfile at startup, sets its permissions, and starts mongod with a replica set named rs0, bound to all interfaces, using that keyfile. The keyfile is what enables internal authentication for a replica set, and the replica set is what the backend needs for transactions and for change streams.

The healthcheck is worth reading because it is doing double duty. It runs mongosh, tries rs.status(), and if that throws it calls rs.initiate with a single member at mongo:27017, so the very first container start initialises the replica set instead of failing. The service publishes port 27018 to the host, so the database is not on the standard port, and it has its own volumes for the data and the config.

Redis is on redis:7-alpine with a ping healthcheck, a data volume and the standard port published. Both services are depended on with the service_healthy condition, so the backend waits for a genuinely working database rather than an open port.

mongo-express comes with its own basic auth and points at mongodb://admin:admin@mongo:27017/, and it is published on 8084 against the container's 8081.

The backend service is built from the repository with its own Dockerfile, reads its environment from ./backend/.env.docker, publishes port 4002, depends on both MongoDB and Redis being healthy, and mounts a cdn volume at /var/www/cdn/bookcars, which is where uploaded images and documents live.

Where BookCars is the wrong tool

There are three honest objections, and the first one is about the gap between a working system and a product.

The first is that a complete feature list is not a finished product. The feature list covers supplier management and contracts, a vehicle scheduler, auto-notifications, a dynamic price calculation engine, multiple payment gateways, multiple payment methods including Google Pay, Apple Pay, Link, pay at the counter, pay in full and pay deposit, hierarchical locations with map and parking integration, multiple login options through Google, Facebook, Apple and email, three languages, multiple currencies, two pagination styles, push notifications, and a security section claiming protection against XSS, XST, CSRF, MITM and DDoS. That is an unusually broad list for a project of this age, and each item on it is a feature to build, integrate with a third party and keep working as those third parties change their APIs. A team buying this is buying a starting point and a lot of remaining work, and the claims in the list are the claims of the project, not a security assessment of your deployment.

The second is the aggregation model, which is a business decision disguised as a technical one. In multi-supplier mode, BookCars is running a marketplace, and marketplaces carry obligations that a single-fleet rental business does not: contract handling between the platform and each supplier, revenue splitting, dispute resolution, and the supplier's own access to the customers. If your business is one company with one fleet, the multi-supplier machinery is complexity you do not need, and if your business is a marketplace, the contracts and payments split are work the software cannot do for you.

The third is the operational surface. Three applications, a mobile app to build and release for two platforms, a backend, MongoDB with a replica set, Redis, a CDN volume for uploaded files, two payment gateways, four identity providers, three languages and multiple currencies. Every one of those is a thing that can break, and the total system is larger than any single piece of it.

The alternative approach is to build a narrow product first, and it is worth stating plainly. A single-supplier rental site with Stripe, a handful of locations and a booking calendar is a much smaller project, and several of the existing open source booking and calendar components would cover the scheduling and availability logic without a marketplace model. The difference in approach is that BookCars has already made the domain decisions for you, including the multi-supplier ones, and if those decisions match how you intend to run the business the code is a large head start. If they do not match, the domain decisions are the part you will spend the most time undoing, because they are woven through the schema.

Editorial conclusion

Adopt BookCars if you are building a car rental business and want a working marketplace rather than a starting skeleton, since it ships the admin panel, the customer flow, the supplier portal, the mobile app and the Docker deployment together, and the multi-supplier mode with per-supplier admin is the part that is genuinely hard to build from scratch. Do not adopt it if you need a product you can put in front of paying customers without a security review, since the README's own demo credentials and the default admin and mongo-express passwords in the compose file are development conveniences, and the MIT licence gives you the code but not the legal or operational cover of a commercial vendor. Verify first that the pricing rules match how you price, reading the price calculation and rental date and time constraint pages in the wiki, that the payment gateways you need are available in your country, and that the mobile app builds from the mobile directory for both platforms before you commit to a release date.

Frequently asked questions

Official sources

1. aelassas/bookcars on GitHub
2. License: MIT
3. Project website
4. README
5. Releases