Lakasir: a Laravel and Filament point of sale with a Flutter companion app

Three front ends over one Laravel core, which is the architectural bet

Lakasir is a Point of Sale application built using Laravel for the API, the Filament admin panel for the web application, and Flutter for the mobile application. That three-way split is the central design decision and it dictates what you can build with it. Laravel holds the domain logic and exposes it as an API, Filament generates the administrative back office on top of that API, and Flutter is what a cashier or a field worker uses. The practical payoff is that the admin side does not need a separate project. Filament produces the screens for roles, products, purchasing and reporting directly from Laravel models, so there is no second codebase to keep in sync with the API. The cost is that everything inherits the constraints of the stack: Filament admin screens have their own conventions, and the Flutter client is a separate release cycle from the PHP server, so a feature that lands in the API may not appear on mobile for a while.

The feature list is an inventory and accounting workflow, not a payments platform

Read the feature list as a description of what a shop actually does all day. Role management defines roles and permissions for users. Transaction management handles sales transactions. Product management covers inventory, and unit pricing gives a product a different price based on its basic unit, which is what makes weighted goods workable. Discounts can be applied per item or globally. Purchasing covers purchase orders and supplier relationships. Stock opname is the stock take and inventory audit feature, and it is named with the Indonesian term because the project is developed for that market. Receivables track what is owed to and by the business. Payment methods, vouchers with tracked usage, reporting, simple accounting for income, expenses and profits, and a real-time dashboard for business metrics complete the set. Two features stand out as unusual for a small POS: web USB direct printing, which drives a thermal printer straight from the browser in Chrome or Firefox, and barcode support that works across stock takes, purchasing and the POS itself. Neither requires a native print driver.

Installing means Laravel setup, asset build, then creating the first user

The install steps are the standard Laravel sequence with a couple of project-specific commands. You need PHP 8.4, MySQL 5.7 or higher, and the PHP extensions Laravel requires. Clone and move into the directory, then prepare the environment and dependencies:

cp .env.example .env
composer install
php artisan key:generate

The migration step is the one to read carefully, because it carries a specific path and a seed flag:

php artisan migrate --path=database/migrations/tenant --seed

Publishing the Filament and Livewire assets follows, and then the front end is built with npm:

npm install
npm run build

Finally you create the first user:

php artisan app:create-user

That last command is the entry point to the system, since Filament admin panels normally require you to create a user record manually before you can log in. The README also gives the two URLs you will use, the API at localdomain.test/api/test and the web application at localdomain.test/member/login.

Redis, queues and sessions are the services you need before production

The .env.example in the repository shows what the application expects to talk to, and it is not only a database. CACHE_DRIVER, QUEUE_CONNECTION and SESSION_DRIVER are all set to redis, with REDIS_HOST, REDIS_PORT and REDIS_PASSWORD alongside them, and mail is routed to mailpit on port 1025 for local work. So a working local setup needs Redis, not just MySQL, and if you deploy with different drivers you are changing behaviour rather than just configuration. The docker-compose file in the repository wires the three together: an app service built from the Dockerfile, a mysql:8.0 service with a healthcheck based on mysqladmin ping, and a redis service on the alpine image, with the app depending on both being healthy. The app container publishes the APP_PORT variable, defaults to port 80, and mounts the source directory while excluding vendor and node_modules as anonymous volumes. That compose file is the fastest way to see the intended topology, which is a PHP application plus MySQL plus Redis rather than a single container.

Multi-tenant mode is a commented-out line in the environment file

The migrate command points at database/migrations/tenant, which tells you that tenancy is part of the design, and the .env.example confirms it with a commented APP_CENTRAL_DOMAIN line and a note saying to enable it if you want multi tenant mode. That is a meaningful architectural detail for a POS, because a multi-tenant deployment lets one installation serve several stores or resellers with separate data, which is how a software vendor running this for many small businesses would work. It also means the tenant migrations are a separate concern from the ordinary application schema, and the README does not walk through enabling the mode, so anyone intending to run it that way needs to read the code rather than the install guide. The SPA_MODE and DARK_MODE flags sit alongside it, and SELLING_METHOD is set to normal, which suggests the sales flow is configurable rather than fixed.

Docker, PHP versions and the gap between the Dockerfile and the requirements

The repository ships a Dockerfile and a docker-compose.yml, which makes container deployment the likely route for anyone evaluating it quickly. The Dockerfile is built on php:8.2-fpm-alpine with nginx and supervisor, and it compiles a set of PHP extensions explicitly, gd with freetype and jpeg, pdo_mysql, mysqli, mbstring, xml, zip, bcmath, intl and opcache, plus the redis extension installed through pecl. Node.js and npm are installed in the same layer, which is what the asset build needs. Composer is installed with a signature check against the published installer hash. One inconsistency is worth flagging before you build: the README states the requirement is PHP 8.4, while the container image is php:8.2-fpm-alpine. If you go the container route you are running 8.2, so check the code paths that assume 8.4 before assuming the container and the documented requirements agree.

Where the simple accounting stops

The honest limitation is the accounting. The feature list says simple accounting, described as basic accounting features to track income, expenses and profits, and that phrasing is doing real work. There is no general ledger, no chart of accounts, no double entry, no period closing and no reconciliation. If your business runs on accrual accounting, or if local tax rules require a documented fiscal report, this is where the tool stops. The other limit is scope of operation. Role management and permissions are described in one line, with no mention of branch-level segregation of duties, and the receiving side of receivables is described as tracking what is owed by and to the business, which is a ledger of amounts rather than a collections workflow. For a single-counter shop with a bookkeeper handling tax outside the system, that is a workable boundary. For a chain, it is not.

A project built in Indonesia, with the support channels that implies

The details in the repository point to a project developed in Indonesia for that market. The stock take feature is called stock opname, the topic tags include indonesia, and the support contact is a [email protected] address, with the alternative being the GitHub discussions feature. There is a live demo at demo.lakasir.com, the project site is lakasir.com, and the README links a roadmap discussion on the organisation's GitHub. Funding runs through Trakteer and Buy Me a Coffee rather than a company, which fits the shape of a self-funded open source product. The default branch is 1.x and the releases are 1.1.11, 1.1.10 and 1.1.9 from May 2026, with the last push on 2026-10-12, so the 1.x line is still being worked on. The licence is GPL-3.0, which is a consideration for anyone who wants to run a modified version as a hosted service for their own chain, since that is the kind of use the copyleft reaches.

Editorial conclusion

Lakasir suits a small shop or reseller that wants a working cashier, inventory and purchasing workflow in one package without paying for a commercial suite, particularly in a market where the maintainers operate. It does not suit an enterprise that needs a tax engine certified for local regulation, multi-branch control or an audited accounting ledger, because what the project calls simple accounting is basic income, expense and profit tracking. Before you deploy it, run the install steps on PHP 8.4 and check the migrate command with the tenant path and seed flag, because that seeding step is what creates your first records, and read the .env.example for the Redis, cache, queue and session drivers before you go to production.

Frequently asked questions

Official sources

1. lakasir/lakasir on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases