Self-Host SlowBooks Pro 2026 on Intel Mac with Docker

Understand the current compatibility status

SlowBooks Pro 2026 is a source-available accounting and bookkeeping application. Its published capabilities include double-entry accounting, invoicing, accounts receivable, accounts payable, payroll-related workflows, inventory, bank feeds, analytics, imports and exports, and a local REST API. The project describes company records as living in PostgreSQL on hardware controlled by the operator.

The current repository describes the signed installer as containing the multi-user Server Edition and says that Docker remains an optional path for Linux servers. That wording replaces the earlier claim that Docker was the documented path for both Linux servers and Intel Macs. The available evidence also describes a signed and notarized macOS package, but it does not identify that package as Apple Silicon-only. We therefore cannot responsibly divide the installation choices by Mac processor architecture.

Docker Desktop itself is also version-sensitive. A Docker Desktop release must support both the specific macOS version and the Intel architecture of the host. Docker changes its supported macOS range over time, so an old Intel Mac can be incompatible with current Docker Desktop even when its processor is technically capable of virtualization. The supplied evidence does not establish a minimum macOS version, Docker Desktop version, memory allocation, or disk capacity for this SlowBooks Pro deployment.

Check the current Docker Desktop system requirements for the exact Mac before downloading it. Do not infer compatibility from an older tutorial, and do not install an obsolete Docker build merely to keep an unsupported operating system online with sensitive accounting data.

Choose a deployment path based on current evidence

Prepare the host and define a production gate

Before touching the repository, decide whether this is an evaluation or a production accounting system. An evaluation can stop when compatibility or documentation is unclear. A production deployment must not proceed until the release-specific configuration, initialization, persistence, backup, and restoration procedures are known and tested.

Verify Docker Desktop compatibility

Confirm the Mac model, processor architecture, and installed macOS version through the macOS system information interface. Then compare them with the current Docker Desktop requirements. Use an Intel-compatible Docker Desktop package only if Docker still supports the host operating system.

After installation, start Docker Desktop and verify that both the client and engine respond:

docker version
docker compose version

The first command should include server information. If it reports only client details or cannot connect to the Docker daemon, the engine is not ready. The second command must recognize the modern docker compose subcommand.

Verify Git and outbound access

git --version

Git is required to retrieve and pin the release. The host also needs outbound HTTPS access for the repository and any images or dependencies referenced by the Compose project.

Plan host availability

A laptop-style host is unavailable when it sleeps, shuts down, loses power, or disconnects from the network. Docker Desktop and the SlowBooks Pro containers must remain running for local access. For remote access, the Localtonet client and selected tunnel must remain running as well.

Review storage capacity without relying on an invented minimum. Required space depends on database growth, attachments, generated files, local images, logs, retained backups, and Docker's own virtual disk. Monitor both macOS free space and Docker Desktop storage consumption.

Pin and review the SlowBooks Pro release

The reviewed release is v2.23.3. Its release page identifies gated commit 3f98d08 and states that release testing covered Windows, macOS, and Linux with PostgreSQL. That gate does not by itself establish that the Docker Compose deployment is officially supported on an Intel Mac.

Clone the repository, fetch tags, and check out the fixed release before running Compose:

git clone https://github.com/VonHoltenCodes/SlowBooks-Pro-2026.git
cd SlowBooks-Pro-2026
git fetch --tags
git checkout v2.23.3
git rev-parse --short HEAD
git status

The revision should correspond to 3f98d08. A detached HEAD is expected when checking out a release tag. If the revision differs, stop and determine whether the tag changed, the checkout failed, or the local repository is not at the reviewed release.

Inspect the files that control deployment

The repository contains INSTALL.md, .env.example, docker-compose.yml, docker-compose.prod.yml, Dockerfile, docker-entrypoint.sh, migration files, and supporting scripts. These files are part of the pinned release and must be reviewed together.

git show --no-patch --decorate HEAD
sed -n '1,240p' INSTALL.md
sed -n '1,240p' .env.example
docker compose config --services
docker compose config

The rendered configuration is especially important because Compose applies variable interpolation and merges defaults before starting services. Review it for:

• Every required environment variable and whether it has a safe value.
• Database credentials and whether defaults are appropriate for production.
• Published host ports and the interface to which each port is bound.
• Named volumes and bind mounts used for PostgreSQL or application files.
• Image tags, build contexts, health checks, restart policies, and dependencies.
• The entrypoint or command responsible for database initialization and migrations.

Evaluate the pinned Compose deployment

Continue only after the release inspection identifies every required environment value and explains how secrets should be supplied. Do not copy credentials from examples into a production deployment. Keep completed secret files out of Git, screenshots, terminal transcripts, and support archives.

git describe --tags --exact-match
git rev-parse --short HEAD
git status

docker compose config --services
docker compose config

docker compose up -d

docker compose ps
docker compose logs --tail=300

If the project documentation for v2.23.3 confirms port 3001, test it with:

curl -i http://127.0.0.1:3001/

Otherwise, replace the port with the host port actually shown by Compose. Do not point Localtonet at port 3001 merely because an older article used it.

Verify application behavior locally

Check every service

docker compose ps
docker compose logs --tail=300

A service that repeatedly restarts, exits, or reports a failed health check is not ready. Use the service names shown by docker compose config --services and docker compose ps. Do not assume generic names such as app, web, or db.

Confirm migrations and initialization

Search the startup output for explicit success or failure messages associated with database connectivity, schema creation, migrations, and application startup. A listening HTTP port does not prove that the database schema is current. If the release requires a separate migration operation, run only the command documented for that release and retain the output with the deployment record.

Test with a browser and an HTTP client

Open the actual local URL in a browser on the host. Confirm that scripts, styles, navigation, and sign-in behavior load correctly. Then inspect the HTTP response from Terminal using the verified port:

curl -i http://127.0.0.1:VERIFIED_PORT/

Replace VERIFIED_PORT with the published host port. A command-line response proves that an HTTP process answered, but only a browser and cautious functional test show whether the application interface works.

Test authentication and roles

The SlowBooks Pro project describes administrator, bookkeeper, and read-only roles for Server Edition. Do not assume that every Docker mode exposes the same workflow. Verify the user-management interface in the pinned release. Give each authorized person an individual account where supported, reserve administrative access for system management, and confirm that an unauthenticated session cannot read company records.

Perform a non-destructive restart test

After creating only non-sensitive test data, restart the project:

docker compose restart
docker compose ps
docker compose logs --tail=200

Reload the local application and confirm that the test state remains. This checks basic persistence across a container restart. It is not a backup test and does not prove recovery after volume loss, database corruption, or host failure.

Establish persistence, backup, and restoration

For an accounting application, the persistence layout is part of the installation, not an optional operations topic. The effective Compose configuration must reveal whether PostgreSQL uses a named Docker volume, a bind-mounted host directory, or another storage arrangement. It must also reveal whether application-managed attachments, exports, configuration, keys, or audit files live outside the database.

Inventory mounts without changing them

docker compose config
docker compose ps
docker volume ls

Match the volumes and bind mounts in the rendered configuration to the services that consume them. Record the Compose project name, source volume or host path, destination path inside the container, ownership expectations, and purpose. Do not infer that backing up the PostgreSQL volume captures every application file.

Do not guess a PostgreSQL backup procedure

A reliable PostgreSQL backup can depend on database names, users, server versions, extension requirements, encryption, application consistency, and migration state. Copying a live database directory at the filesystem level is not automatically a valid backup. Likewise, an SQL dump alone may omit application files stored elsewhere.

The supplied project evidence does not publish an authoritative SlowBooks Pro backup command, backup artifact format, volume map, or restoration sequence for v2.23.3. It also does not establish whether the application interface includes a supported backup and restore operation. Until those details are obtained from the pinned release or its maintainers, this deployment should not be represented as production-ready.

Define a recovery acceptance test

A complete test should use an isolated environment and answer all of the following:

• Can a backup be created while the application is in a documented consistent state?
• Does the backup include the database, application files, configuration, and necessary encryption material?
• Can it be restored without relying on the original Docker volume?
• Does the restored application start on the same pinned release?
• Do test transactions, users, permissions, attachments, and audit history appear correctly?
• Can the recovery process be repeated by someone other than the original installer?

Routine container operations

Upgrade deliberately

Do not update by pulling a moving branch over a production deployment. Identify the installed tag and commit, read the target release notes, review configuration differences, determine migration and rollback behavior, create a tested backup, and schedule a maintenance window.

After an upgrade, inspect logs and verify the application locally before restarting remote access. A source rollback may not reverse a database migration. A real rollback plan therefore depends on the target release's migration policy and a verified pre-upgrade backup.

Add a Localtonet HTTP tunnel after local verification

Localtonet can expose a local HTTP service without inbound router port forwarding, firewall changes, VPN setup, or a public IP address. Our client runs on the device that can reach SlowBooks Pro and establishes an outbound connection to a Localtonet relay server.

For an Intel Mac, the current Localtonet download list provides a MacOS 64-Bit client. Apple Silicon users should choose the separate MacOS ARM-64 download. Install the client that matches the host architecture and use the device-specific authentication token assigned through your Localtonet account.

See the Localtonet HTTP tunnel documentation for the current HTTP dashboard workflow. The general Localtonet documentation provides the current operating-system downloads, including MacOS 64-Bit and MacOS ARM-64.

Keep the local and public tests separate. If the public URL fails, retest the local endpoint on the Mac. If the local endpoint fails too, investigate Docker, initialization, migrations, storage, and SlowBooks Pro. If the local endpoint works, investigate the Localtonet device connection, tunnel state, selected relay, and target address.

Apply a production security checklist

Protect application identities

Use individual user accounts where the installed mode supports them. Apply read-only access for users who only need reports, bookkeeping access for users who enter transactions, and administrative access only for system management. Avoid shared administrator credentials because they weaken accountability and make offboarding difficult.

Protect the host

Use a strong macOS login credential, enable appropriate device security, apply supported operating-system updates, and restrict physical access. Keep Docker Desktop, the Localtonet client, Git, and browsers maintained. Do not run unrelated untrusted containers on a host that handles sensitive accounting records.

Protect secrets

Localtonet device tokens, application credentials, database passwords, payment credentials, and AI-provider keys must not be committed to Git. Exclude secret-bearing files from screenshots and support bundles. Rotate any secret that is exposed.

SlowBooks Pro offers optional AI integrations. Information sent to a cloud-backed model is processed under that provider's terms. Only a locally operated model that has been checked for outbound behavior can be treated as keeping its processing local.

Limit exposure time

Stop the Localtonet tunnel during maintenance, incident investigation, backup restoration, or periods when remote access is unnecessary. Delete obsolete tunnel configurations and retire device tokens associated with decommissioned hosts.

Record operational ownership

Document who maintains the host, who can administer SlowBooks Pro, who can start or stop the tunnel, where recovery material is held, and how access is revoked. A self-hosted system transfers operational responsibility to the operator.

Troubleshoot by layer

Docker cannot connect to the engine

Start Docker Desktop and wait for it to become ready. Run docker version again. If the server section remains unavailable, resolve Docker Desktop compatibility or startup before investigating SlowBooks Pro.

The Intel Mac cannot install current Docker Desktop

Check whether the installed macOS release and Intel architecture remain supported by the current Docker Desktop package. Do not silently downgrade to an unsupported Docker release for a production accounting host. Move the Docker deployment to a supported Linux server or evaluate another officially supported SlowBooks Pro installation path.

Compose cannot find its configuration

pwd
ls
git status

Run Compose from the pinned repository directory. Confirm that the expected Compose files are present and that Git reports the v2.23.3 checkout.

Compose reports a missing variable

docker compose config

Compare the error with INSTALL.md and .env.example from the same tag. Do not copy a value from another release or invent credentials. If the release does not document the requirement, stop the production rollout.

A service exits or restarts continuously

docker compose ps
docker compose logs --tail=300

Find the earliest meaningful error. Possible categories include image architecture incompatibility, a missing environment value, database initialization failure, migration failure, unavailable storage, file-permission errors, or a port conflict. The emitted error and actual service name determine the remedy.

The expected port is not published

Inspect docker compose ps and docker compose config. Use the port defined by the pinned release. Do not add an arbitrary port override without understanding whether the application generates absolute URLs, applies origin checks, or expects a particular binding.

A port is already in use

Replace VERIFIED_PORT with the port shown by Compose:

lsof -nP -iTCP:VERIFIED_PORT -sTCP:LISTEN

Stop the conflicting process only if you recognize it and understand its role. Follow the release's supported configuration if the host binding must change.

The local page opens but database operations fail

Inspect application and database logs. Confirm that initialization and migrations completed for the pinned release. An HTTP response proves only that a process is listening. It does not prove that PostgreSQL is reachable or that the schema is current.

The local URL works but the Localtonet URL fails

Confirm that the MacOS 64-Bit client is connected as the intended device, the HTTP tunnel is started, an available relay is selected, and the target matches the verified local address and port. When our client runs on the Docker host, 127.0.0.1 addresses that host. On another device, it addresses the other device instead.

The public page loads without requiring authentication

Stop the tunnel immediately. Review SlowBooks Pro's first-run state, authentication settings, user configuration, and intended deployment mode. Localtonet forwards requests to the application, so the application must enforce access to accounting records.

The service disappears while unattended

Check host sleep, power, Docker Desktop state, container state, Localtonet client connectivity, and tunnel status. Configure availability intentionally, balancing remote-access needs with host security and maintenance requirements.

Frequently asked questions