Akaunting: self-hosted accounting for small businesses and freelancers

Who Akaunting is aimed at, and what it replaces

Akaunting is online accounting software designed for small businesses and freelancers. The README states that plainly, and the topics attached to the repository list invoices, expenses, billing, payroll and CRM alongside the Laravel and PHP tags. So the intended user is someone who needs to issue invoices, record expenses and keep books, and who is willing to run the application rather than rent it.

The problem it solves is ownership of the ledger. A hosted accounting service keeps your books on someone else's infrastructure and ties your access to a subscription. Akaunting, by contrast, is code you clone and install. Your database holds the records. That matters for freelancers and small firms in jurisdictions where bookkeeping data is expected to stay on premises, and for anyone who has been burned by a service changing its plan.

It is not aimed at accountants running multi-entity consolidations, and nothing in the repository suggests that scope. It is also not a spreadsheet replacement for someone who wants zero setup: the installation section assumes a working PHP environment and a database. The trade is explicit. You get control and you pay for it in operational work.

The Laravel and Vue split, and what the modular structure actually means

Akaunting uses Laravel as its foundation framework and the akaunting/module package for apps. The README describes a modular structure and points to an App Store for users and developers. The repository layout backs this up: there is a modules/ directory at the top level, separate from app/, and an overrides/ directory beside it.

The front end is a Vue 2 application built through Laravel Mix. The package.json file lists vue 2.7.14, vue-router 3, element-ui, tailwindcss 3, axios and vee-validate 2, with build scripts named development, watch, hot and production that all run through mix. So the data flow is the conventional one for this stack: Laravel serves routes and persists to the database, Vue components render the interface, and Mix compiles the assets into public/.

Two details in the repository are worth noting because they shape how you deploy. The first is index.php at the project root, next to server.php and LocalValetDriver.php. The second is nginx.example.com.conf alongside web.config and .htaccess. The project ships server configuration for all three major web servers, which tells you the maintainers expect people to run this behind Nginx, IIS or Apache rather than only through a PHP development server.

The modular structure is the part with real consequences. Because apps plug in through a module package, extending Akaunting means writing against that package rather than patching core files, and the overrides/ directory exists for the cases where you must replace something. The Developer Portal link in the README frames this as a way for developers to generate income, which is consistent with an App Store model. If you plan to customise heavily, budget time for learning the module conventions first.

Installing Akaunting from the repository

The README gives a four-step install. First clone the repository, then install dependencies with Composer and npm, then run the artisan install command, and optionally seed sample data. The requirements section states PHP 8.1 or higher, Node.js 18 or 20, a database such as MariaDB, MySQL, PostgreSQL or SQLite, and a web server.

The dependency install and the initial build look like this. The README lists composer install, npm install and npm run dev as the sequence, and package.json confirms that dev maps to the development script, which runs mix.

git clone https://github.com/akaunting/akaunting.git
composer install
npm install
npm run dev

After that, the install command takes the database and administrator details as flags. The README shows this exact invocation.

php artisan install --db-name="akaunting" --db-username="root" --db-password="pass" --admin-email="[email protected]" --admin-password="123456"

If you want data to look at immediately, the README offers an optional seeder.

php artisan sample-data:seed

For a quick local run the README notes that php artisan serve also works. For anything else, there is a deployment detail that is easy to get wrong and that the README states directly: point the web server document root at the project root, not at public. Akaunting serves itself through the index.php in the project root and builds its asset URLs accordingly. If you point at public out of habit, expect broken assets.

Configuration lives in .env, and .env.example is the template. It sets APP_NAME=Akaunting, APP_LOCALE=en-GB, DB_CONNECTION=mysql, DB_PORT=3306, QUEUE_CONNECTION=sync, MAIL_PORT=2525 and FIREWALL_ENABLED=false. APP_INSTALLED=false is the flag the installer flips. Note that APP_DEBUG=true and LOG_LEVEL=debug are the shipped defaults, which is not what you want on a public server.

Where the Node version constraint bites

The README says the asset pipeline does not build on Node 21+ yet, and package.json enforces the same constraint with an engines field of >=18 <21. This is a real limitation rather than a footnote, because Node 22 and later are the versions a new machine will hand you by default. If npm install or npm run dev fails on a modern Node, the cause is likely this, not your code.

The fix is to pin the runtime for the build step, which is why the repository ships an .npmrc and why the README calls out versions 18 and 20 specifically. Anyone deploying Akaunting on a build server that tracks the latest Node release will hit this, and the error surfaces during asset compilation rather than at install time, which makes it slower to diagnose.

There is a second constraint in the same area. The front end is Vue 2, and Vue 2 reached end of life upstream. Akaunting pins vue ^2.7.14 and vue-router ^3.6.5, so the application is on a branch of the ecosystem that no longer receives framework updates. That is a maintenance consideration for anyone planning to contribute front-end code, and it is visible in package.json rather than stated in the README.

The licence is the decision point, not the feature list

Akaunting is released under the BSL license, per the README and LICENSE.txt. The repository metadata reports the licence as NOASSERTION, which is what GitHub shows when it cannot map the file to a recognised SPDX identifier. That mismatch is worth understanding before you build a business on it.

BSL is not the same as MIT or GPL. It is a source-available licence whose terms are set by the licensor, and the README does not summarise those terms. It links to LICENSE.txt and stops there. So the honest position is that you must read LICENSE.txt yourself and, if the use is commercial or you intend to redistribute, get your own legal reading of it. Nothing in the repository states a change date, a permitted-use carve-out, or an automatic conversion to an open source licence.

The practical consequence is that Akaunting sits in a different category from projects like GnuCash, which is commonly distributed under the GPL. If licence permissiveness is a requirement for you, that difference is the whole evaluation. If you only care that the source is available and you can self-host, the BSL terms may be fine, but that is a judgement you make against the actual text.

Akaunting against GnuCash and QuickBooks

The two comparisons people reach for are GnuCash and QuickBooks, and they differ from Akaunting in ways that are structural rather than cosmetic.

GnuCash is a desktop application. Your books live in a local file, and there is no web server, no database service and no browser session. That makes it genuinely offline and trivially backed up, and it makes multi-user access awkward. Akaunting is the opposite: a server application with a database, reachable over the network, which is what you want when a bookkeeper and an owner both need to work in the same ledger. Choosing between them is mostly a question of whether the books should be a file or a service.

QuickBooks is hosted software with a vendor behind it. You get support, updates and someone else's uptime, and you give up the ability to run the application yourself or to keep the data on your own hardware. Akaunting's answer is self-hosting, with the operational burden that implies. The README points to a forum and a documentation site for support rather than a support contract, and the App Store is the extension path.

If you want a middle option, the related searches around Akaunting include a Docker phrase, but the README does not document a Docker install. The installation section is the clone-and-composer path above. Treat any container route as something you would assemble yourself from the requirements list.

Maintenance, upgrades and what to verify before you commit

The repository is not archived, and the last push was on 2026-09-21. Recent releases are 3.2.4 on 2026-09-17, 3.2.3 on 2026-08-31 and 3.2.2 on 2026-08-10, which is a steady cadence over roughly six weeks. That is the maintenance picture the facts support, and it is a favourable one for a self-hosted application.

Upgrade cost is where self-hosting gets expensive, and the README is thin here. It points to the releases page for the changelog and says nothing about rollback, database migration strategy, or whether a minor version bump can be applied in place. There is a migrations directory implied by the Laravel structure and a database/ folder in the repository, but no upgrade procedure is documented in the README. Before you put real books in Akaunting, take a database dump and confirm you can restore it, because that is your rollback plan whether or not the project documents one.

The other cost is the stack itself. You are maintaining PHP 8.1 or higher, a database, a web server, and a Node 18 or 20 toolchain for builds. The .env.example ships with APP_DEBUG=true, LOG_LEVEL=debug, FIREWALL_ENABLED=false and MODEL_CACHE_ENABLED=false. Turning debug logging off and deciding whether you want the firewall and model cache enabled are configuration decisions the file presents but does not explain. For a production deployment, changing APP_DEBUG and LOG_LEVEL before you expose the instance is the first thing to do, and the file gives you the keys to do it.

Editorial conclusion

Adopt Akaunting if you want accounting data on your own server and can run PHP 8.1, Node 18 or 20, and a database yourself; skip it if you need a vendor to hold the ledger or you cannot pin the Node version. Before committing, check LICENSE.txt for what the BSL terms mean for your use and confirm your web server points at the project root rather than public.

Frequently asked questions

Official sources

1. akaunting/akaunting on GitHub
2. Issues
3. Project website
4. README
5. Releases