Akaunting Docker Image

You can pull the latest image with docker pull docker.io/akaunting/akaunting:latest

Description

This repository defines how the official Akaunting images are built for Docker Hub.

Akaunting is online, open source and free accounting software built with modern technologies. Track your income and expenses with ease. For more information on Akaunting, please visit the website.

Prerequisites

1. docker-compose, or the knowhow to use docker or podman to run these images.
2. You'll need to use some other reverse proxy for TLS termination. HAProxy, Nginx, or Apache work fine and have integrations with Let'sEncrypt that let you request wildcard certificates. See Reverse proxying for TLS termination for more information. Reverse proxies are all trusted in these images to support use cases like Kubernetes Ingress.
3. Your own cache, if you need to scale to lots of users. Memcached and Redis are popular choices. See the configuration for cache and redis if necessary. You can provide the variables for configuration via run.env.

Usage

git clone https://github.com/akaunting/docker
cd docker
cp env/db.env.example env/db.env
vi env/db.env # and set things
cp env/run.env.example env/run.env
vi env/run.env # and set things

docker-compose up -d -e AKAUNTING_SETUP=true

Then head to HTTP at port 8080 on the docker-compose hostand finish configuring your Akaunting company through the interactive wizard.

After setup is complete, bring the containers down before bringing them back up without the setup variable.

docker-compose down -v
docker-compose up -d

Included is a watchtower container. This will automatically pull updates for the MariaDB and Akaunting images daily, restarting the containers with the new images when there has been an update.

Backup and restore

You could use something like the following commands to make backups for your deployment:

mkdir -p ~/backups
for volume in akaunting-data akaunting-db; do
    docker run --rm -v $volume:/volume -v ~/backups:/backups alpine tar cvzf /backups/$volume-$(date +%Y-%m-%d).tgz -C /volume ./
done

In order to restore those backups, you would run something like:

backup=2021-01-26 # you should select the backup you want to restore here
for volume in akaunting-data akaunting-db; do
    docker run --rm -v $volume:/volume -v ~/backups:/backups alpine sh -c "rm -rf /volume/* /volume/..?* /volume/.[!.]* ; tar xvzf /backups/$volume-$backup.tgz -C /volume"
done

A note on upgrades

The upgrade between 2.0.26 and 2.1.0 broke some things in existing deployments due to a Laravel version migration in Akaunting. In order to fix this, you could have run something like the following:

docker exec -it akaunting bash

Then, inside the container, the following:

php artisan view:clear

Future version migrations might require something like:

php artisan migrate --force

Application upgrade/migration logic is not baked into this application image. An upgrade between versions that requires intervention would best be encapsulated in something like a Kubernetes Operator, rather than adding to the complexity of the application image.

If you use these images in production, it is recommended to have a testing environment that draws automatic updates and exists so that you can validate the steps required to migrate between versions. Your production deployment should use pinned version tags, which are tagged based on the Akaunting release. Migrating your production version would then require manual intervention and enable you to take the manual steps necessary to complete the migration.

Reverse proxying for TLS termination

No configuration has been provided for TLS termination. The "right" TLS termination strategy and load balancing setup is highly subjective and depends very much on the rest of your environment. The container image accepts connections from any proxy, and recognizes the host from HTTP requests via the APP_URL environment variable.

Googling "letsencrypt haproxy" returns with a number of articles with decent instructions on how to set up HAProxy and certbot to automatically renew certificates served. Some extra keywords, like wildcard, give enough extra information to layer that into your configuration. If nginx makes more sense for your environment, an nginx configuration that stitches together the elements of load balancing, reverse proxying, and Let'sEncrypt can meet the same need. So can Apache, or a number of other webservers. The world is your oyster.

A robust TLS termination and load-balancing setup should outperform, and be easier to maintain than, many little nginx containers running with their own certificate lifecycles, even if they're automated. Running Akaunting in a container makes the most sense if you're running lots of services on fewer hosts, and for that use case a load-balancing reverse proxy for TLS termination might make more sense. Or it might not. Now you get to choose.

Languages

Right now, the only built language is US English. If you would like more supported locales to be built into the container image, please open an issue.