inventory-management-system is a Laravel and Livewire stock, sales and purchasing app

A full shop floor application rather than a library

The README calls this a comprehensive inventory management system built with Laravel and Livewire, designed to handle inventory tracking, sales, purchasing processes and financial ledger management with dynamic localization. The modules are the clearest way to judge it. There is an analytics dashboard with real-time total sales and net cash flow tracking, interactive ApexCharts for sales and cash flow trends, and quick insights for top selling products, top customers and low stock alerts. There is a sales and point of sale module with a fast checkout interface, support for global discounts, exact cash computation and change tracking, direct integration with invoice and receipt printing, and a cart that persists across sessions. There is a purchases and receiving module with an end to end purchase order workflow and a receive items action that updates real inventory balances automatically. Master data covers products with stock, buy and sell margins and associations, categories and units, and customers and suppliers. The primary language of the repository is PHP and the topics are inventory management, Laravel and point of sale, so this is an application to deploy rather than a package to add to a codebase.

The finance ledger and how sales become income

The finance module is the part worth reading closely before you trust the numbers. It is described as integrated double-entry style tracking for all income and expenses, with dynamic cash flow reporting mapping POS sales to income and purchases to expenses automatically, plus custom income and expense categorisation. The wording double-entry style is doing real work there: it signals an accounting shape rather than a claim of full double-entry bookkeeping, and there is no mention of accounts, journals, trial balance or period closing, so this is a cash flow view of trading activity rather than a general ledger you could run statutory accounts from. The automatic mapping is the practical point. A completed sale lands in income and a purchase lands in expenses without a bookkeeper choosing a category, which is what makes the cash flow chart in the dashboard update as the shop trades rather than after a manual import. The custom categorisation is what lets a manager split those two buckets further. If your requirement is a cash position for one store, this is proportionate. If your requirement is a set of financial statements for several entities or a fiscal year end, the model here is not enough and you would need real double entry underneath it.

The currency and localization framework

Localization is called out as a first class feature rather than an afterthought, and the mechanism is unusually concrete. The README describes a fully dynamic currency framework with customizable currency symbols, positions on the left or the right, thousands separators, decimal separators and fractional precision, and states that changes apply globally to charts, tables, inputs and receipts instantly. That last clause is the interesting one, because it means the formatting rules are applied in one place rather than being repeated in each Blade template, so a currency with three fractional digits and a different separator does not need every view updated. Global store information management is the other half, which is the settings that apply across the whole installation. This is the feature that makes the application usable outside the country it was written in, and it is also the feature that needs testing after you change it, since a currency change touches every chart axis, every table column and every printed receipt at once.

The Docker route and what starts on first boot

The recommended path is Docker, and the README is explicit that it runs the entire stack, Nginx, PHP, frontend assets and PostgreSQL, with one command and no local PHP, Composer, Node or database installation required. The prerequisites are Docker 20.10 or newer and Docker Compose v2 or newer. You clone the repository and start the containers.

    git clone https://github.com/fajarghifar/inventory-management-system.git
    cd inventory-management-system

    docker compose up --build -d

You then open the app at http://localhost:8080 and log in with the default admin credentials, admin and password. On first start Docker builds the frontend assets with Vite, starts a PostgreSQL container, runs the migrations and seeders, and starts Nginx, PHP-FPM and the queue worker. That list is the interesting part, because it means the entrypoint script waits for the database, applies the schema and seeds reference data before the application accepts traffic. The compose file confirms the arrangement: an app service on the inert/laravel-app:new image with the port mapped from APP_PORT or 8080, and a postgres service on postgres:16-alpine, with the app depending on the database reaching a healthy state. The health check on the app service curls the login page every 30 seconds with a 60 second start period, and the database check runs pg_isready against the inventory database.

Configuration, volumes and the daily commands

Default Docker settings live in .env.docker and docker-compose.yml, and the compose file sets the app name, APP_ENV local, APP_DEBUG true, the pgsql connection pointing at the postgres service, and the session, cache and queue drivers all on database. Data persists in two named volumes, storage_data and postgres_data, so it survives a container restart. The useful commands are short, and the README lists them in a table: docker compose up --build -d to build and start in the background, docker compose down to stop and remove containers, docker compose down -v to also remove the database and storage volumes, and docker compose logs -f to follow the application logs.

To use a different port you set APP_PORT, either in a .env file in the project root or exported.

APP_PORT=9000 docker compose up --build -d

One point deserves emphasis before anything else: APP_DEBUG is true in the compose configuration and the seeded account is admin with the password password. Both are development defaults, and the compose file is a development and evaluation setup, so if you put this in front of a real shop you change the debug flag, the credentials and the database password, which the compose file sets to secret, before the first boot rather than after.

The manual installation path and its MySQL assumption

The alternative route avoids Docker entirely and needs PHP 8.2 or higher, Composer, Node.js with NPM and a MySQL database. The sequence is a standard Laravel setup, and the database credentials are edited in the .env file.

    cp .env.example .env

    php artisan key:generate

    php artisan migrate:fresh --seed

The .env.example shipped in the repository defaults to a sqlite connection, so the manual path expects you to change it.

    DB_CONNECTION=mysql
    DB_HOST=127.0.0.1
    DB_PORT=3306
    DB_DATABASE=your_database_name
    DB_USERNAME=root
    DB_PASSWORD=

Then the assets are built and the development server started.

    npm install
    npm run build

    php artisan serve

The mismatch between the two paths is worth noting. The manual instructions specify MySQL while the Docker stack runs PostgreSQL and the compose environment sets the connection to pgsql, so a schema or query that works under the manual path is not automatically working under the container path, and the two databases are not interchangeable without testing. The README also says the Docker image builds frontend assets with Vite and that the Docker route needs no local Node, while the manual path needs npm run build, so the asset pipeline differs between the two deployments.

The front end stack and the versions in question

The UI is Livewire 3 with Alpine.js for reactivity, Tailwind CSS with Shadcn inspired components, Livewire PowerGrid for data tables with customised AJAX filters, ApexCharts for charts and Blade Heroicons for icons. The package.json in the repository root is a small Vite project with the build and dev scripts, a tailwindcss vite plugin, postcss and autoprefixer, axios, flatpickr for date input and tom-select for enhanced selects, and alpinejs and concurrently among the dev dependencies. One oddity in the dependency list is that both tailwindcss v3 and the @tailwindcss/vite plugin are declared, which suggests the styles setup is mid migration between Tailwind versions rather than settled on one. The bigger oddity is the framework version. The repository description says the system is built with Laravel 10, while the README's tech stack section says Laravel 12.x and the Dockerfile builds against PHP 8.3. The repository also has no GitHub releases, so there is no tag to pin and the licence on the repository is one GitHub cannot classify. Those three facts together mean you should read the actual composer.json before planning a deployment.

Where this inventory system is the wrong choice

Four limits are worth naming. The first is the accounting depth, as discussed: the ledger is a cash flow view of trading with an automatic sales to income and purchases to expenses mapping, so a business that needs invoices with tax handling, credit terms, multi currency ledgers or a real trial balance needs something else for the finance half. The second is the licence and the release discipline. The repository's licence field is unknown to GitHub, so the terms for commercial use are something you have to establish yourself, and with no releases and no tags, upgrading means taking whatever is on the default branch, which for an application holding inventory and financial records is a real operational concern. The third is the single-store shape. There is global store information and a global currency framework, but nothing in the module list suggests multiple warehouses, multi site stock, consignment, batch or serial number tracking, lot expiry, or production recipes, and a shop with more than one location or with expiry dated stock will find those missing. The fourth is the development defaults, the debug flag and the seeded credentials, and the fact that the compose configuration is clearly a development and evaluation setup rather than a production template. The realistic alternative for a business that needs the finance discipline is to keep this application for stock and point of sale and put a proper accounting package behind it, with the cash flow figures exported as the hand-off, and for a business that needs multi warehouse and traceability an ERP with inventory modules is the better shape, since the cost of retrofitting those onto this codebase is higher than the cost of starting from one that has them.

Editorial conclusion

Adopt this project if you are running a small retail or trading operation and want a working point of sale, purchase receiving and stock ledger in one application you can host yourself, because the Docker Compose route brings up Nginx, PHP-FPM, a queue worker and a database with one command. Do not adopt it if you need a general purpose accounting system, since the finance module is described as double-entry style tracking with a simplified mapping of sales to income and purchases to expenses, and do not adopt it as a starting point for a custom product without reading the code, because the licence on the repository is not one GitHub can classify. Verify two things first: which Laravel version the code actually targets, since the repository description says Laravel 10 while the README and the Docker build use Laravel 12, and whether the default credentials and debug settings are changed before the site is exposed, since APP_DEBUG is set to true in the compose file. The practical first step is to run docker compose up --build -d, open http://localhost:8080 and sign in with the admin account before touching any data.

Frequently asked questions

Official sources

1. fajarghifar/inventory-management-system on GitHub
2. Issues
3. README