Skip to content
LokumTech.

Installation and hardening

Akaunting installed on your server, with the cron and the mail proven before we leave.

Most failed Akaunting installs are neither Akaunting's fault nor yours. They are a host that cannot run it and an installer that does not say so clearly. We check the host first, in writing, and if the answer is "not on this hosting" you hear it before you have paid for an installation.

Book an install slotHosting pre-flight only

Why installs fail

Twelve ways this goes wrong, all of them documented.

These are real reports from the issue tracker and the forum, including the Turkish category. The official installation documentation is known to be wrong — there is an open issue titled to that effect, and it is not a new one.

The host

  • "Ask your hosting provider to use PHP 8.1.0 or higher" — while the site is already running 8.2.
  • CLI PHP is a different build from web PHP, and the binary is called php8.2, not php.
  • proc_open and proc_get_status disabled for security reasons, which stops the installer dead.
  • Softaculous or Plesk starts a wizard that freezes before the language list appears.
  • Installed into public_html and it took the rest of the site down with it.
  • Max execution time cuts the installer off in the middle of a migration.

The installer

  • Step 3, creating the admin user: no error, empty log, nothing in the browser.
  • "Not able to create a new user." at the end of php artisan install.
  • "Unsupported cipher or incorrect key length" — APP_KEY was never generated.
  • A timed-out install leaves the database half-migrated, so the retry fails on a table that already exists.
  • Assets 404 because the code references /public/css and you are running artisan serve.
  • node-gyp fails on Node 22 and succeeds on Node 18, with no message that says so.

Pre-flight

We check the host before anybody buys anything.

A go or no-go verdict on the server you already have, in writing. If it is a no, you get the list of what would have to change — and that list is yours to take to your host, to us, or to a different provider.

  • PHP version for HTTP and for CLI, checked separately, because they are frequently not the same
  • Which binary the scheduler will actually call: php, php8.2, or a full path
  • All 13 required extensions: bcmath, ctype, curl, dom, fileinfo, gd, intl, json, mbstring, openssl, tokenizer, xml, zip
  • proc_open and proc_get_status, the two functions Turkish shared hosts disable most often
  • memory_limit, max_execution_time, upload_max_filesize, and the separate app-level attachment limit people miss
  • mod_rewrite or its nginx equivalent, and whether the document root can be pointed at the public directory
  • Database engine and version: MySQL, MariaDB or PostgreSQL, and which one you should actually be on
  • Whether outbound HTTPS to akaunting.com works, because the app phones home for version checks and app installs
  • Disk headroom for the storage directory, where every attachment you will ever upload lives
  • Whether a real cron entry can be created, rather than a web-triggered pseudo-cron that only runs when someone visits

What we do

Five days, and a runbook at the end of them.

Two tiers: a clean server we provision, or the host you already have, adopted as it stands. The steps are the same. The second tier takes longer because the first job is finding out what is already there.

  1. 01

    Pre-flight and a go or no-go

    Day 1

    The checklist above, run against your server, with a written verdict. If your host cannot run Akaunting properly we say so at this point, before an installation has been bought.

  2. 02

    Provision or adopt

    Day 1–2

    Nginx or Apache with PHP-FPM, the database, TLS with automatic renewal, a deploy user, and the document root on the public directory. Or your existing Plesk, cPanel or Docker setup, brought up to the same standard.

  3. 03

    Install and configure

    Day 2–3

    The artisan installer with the time limit raised so it cannot die mid-migration. APP_KEY generated, APP_URL correct, APP_DEBUG off. A second break-glass admin account, because assigning yourself the wrong role and locking yourself out of the role screen is one of the most common support calls there is.

  4. 04

    Prove cron and mail

    Day 3–4

    A real cron entry, then a recurring invoice and a reminder test-fired so you watch them arrive. SMTP with SPF, DKIM and DMARC, and one invoice PDF delivered to a real inbox — generated invoice attachments do get flagged as spam, and that is cheaper to fix before it happens to a customer.

  5. 05

    Backups, restore test, handover

    Day 4–5

    Database and the storage directory on a schedule, then a restore performed into a scratch environment and checked for attachments, because a database-only backup silently loses every file. Then the runbook, the app inventory with renewal dates, and a training call.

What you are holding at the end

  • Root or sudo access that was yours all along, and ours revoked whenever you ask
  • An env file we walk you through line by line, rather than one you inherit
  • A cron entry you can read, on a schedule you chose
  • A backup job with the restore already performed once, in front of you
  • Two admin accounts, so a role mistake is an inconvenience rather than an outage
  • A written licence-tier statement for your real company, user and invoice counts
  • A runbook for your setup, not a copy of the generic documentation
  • An inventory of every paid app installed, what it does, and when it renews
We reply within one business day. Turkish and English.

How it is priced

Fixed price, two tiers, and the pre-flight sold on its own.

The pre-flight is cheap and separable on purpose. If the honest answer is that your hosting has to change, that is something you should find out before buying an installation, not during one.

Hosting pre-flight

Quoted after assessment

The checklist run against your current server, with a go or no-go verdict and a list of what would have to change. Credited in full against an installation if you go ahead.

  • 1–2 days
  • Written verdict, yours to keep
  • No commitment to anything else

Install on a clean server

Quoted after assessment

We provision the stack from scratch on a VPS in your own cloud account, then install, prove and hand over. The predictable tier, and the one we recommend.

  • 3–5 days from access
  • Backups with a tested restore
  • Runbook and a training call

Adopt an existing host

Quoted after assessment

Your shared host, Plesk, cPanel or Docker setup, brought to the same standard. Priced higher because the first day is spent finding out what is already there.

  • 5 days, longer if the host fails pre-flight
  • A migration path if it cannot be saved
  • Identical handover
Invoicing entity: Lokum Tech LLC
Server, domain and licence stay in your name
Akaunting licence and apps bought by you at list price
Written scope before any work begins

Starting prices for these packages are being finalised. Ask on a call and we will give you a number, not a range.

Scope

In scope, and firmly out.

An installation that quietly expands into a migration is how fixed prices stop being fixed. So here is the boundary.

Included

  • A VPS in your own cloud account, provisioned and hardened
  • Docker, using our own compose setup rather than the official image, which currently lags the application by several months
  • TLS, cron, SMTP, backups, a restore test, and two admin accounts
  • Installing and configuring the paid apps you have already bought
  • Moving an existing install to a better host, attachments included
  • A licence-tier statement in writing, before you build on it

Not included

  • Hosting sold by us. The server is your account, your card, your keys.
  • Reselling the Akaunting licence or any App Store app.
  • Data migration from another accounting system. That is a separate engagement, and it starts with a paid data assessment.
  • Custom modules or e-Fatura work, which have their own pages and their own prices.
  • Ongoing monitoring, unless you take the maintenance retainer.
  • High availability on MySQL Group Replication. Four Akaunting tables are reported to have no primary key, so we will not promise it works.

Straight answers

Questions we get before an install.

Can it run on our shared hosting?
Sometimes. The two things that decide it are whether CLI PHP matches web PHP and whether proc_open and proc_get_status are available — Turkish shared hosts disable those two more often than anywhere else we have looked, and without them the artisan-driven installer and the one-click updater both fail. The pre-flight answers it for your specific host in a day or two, and we have delivered a no.
You keep saying cron is required. Required for what?
Recurring invoices, invoice reminders and scheduled reports. All three are driven by the scheduler, and all three silently do nothing when it is not set up — no error, no log entry, no email. It is one of the most common "Akaunting is broken" reports and it is almost always a missing cron entry, which is why we test-fire a recurring invoice in front of you rather than declaring it configured.
Do we need a VPS, or is Docker fine?
Either works. We do not use the official Docker image as-is: its repository has been pushed to far less recently than the application itself and it carries a stack of open issues, so we ship our own compose setup with the versions pinned. If you already run containers, that is the cheaper path. If you do not, a plain VPS is easier for your own admin to reason about at two in the morning.
What does "proven" mean for cron and mail?
That you watch it happen. We create a recurring invoice with a due date in the near future and let the scheduler fire it while you are on the call. We send an invoice PDF to an inbox you nominate and check the headers for SPF and DKIM. Configuration you cannot see working is configuration nobody has tested.
Can we keep our existing data?
Usually, but it is a separate engagement with a paid assessment first, because we have never seen two of these that were alike. One trap worth knowing now: attachments live on disk, not in the database, so a database-only export leaves every uploaded file behind. If your current backup is a SQL dump, your attachments are not in it.
How long until we are live?
Three to five business days from the moment we have server access, for a clean install with cron, mail, backups and a restore test. Add roughly a week if the pre-flight fails and the host has to change, and add time for paid apps that need configuring. If somebody quotes you an afternoon, ask them who tested the restore.

Every good build starts with a conversation.

Tell us the process that hurts. We will tell you honestly whether we are the right studio for it — and if we are not, who is.

Book a 30-minute callWho does the work