Self-Host SlowBooks Pro 2026 on Intel Mac with Docker

Understand the SlowBooks Pro deployment

SlowBooks Pro 2026 is a source-available accounting and bookkeeping application designed to keep company records on hardware controlled by the operator. Its documented feature set includes double-entry bookkeeping, invoicing, accounts receivable, accounts payable, inventory, bank feeds, reporting, payroll-related workflows, imports and exports, and a local REST API. The application is not described by its maintainers as conventional open-source software, so review its license before redistributing it, modifying it for distribution, or incorporating it into another product.

The project offers several installation shapes. There is a signed Windows installer, a signed and notarized macOS package for Apple Silicon, a Windows Server Edition, and an optional Docker deployment for Linux servers and Intel Macs. This article is specifically about the Docker path on an Intel Mac. It does not apply the Apple Silicon desktop package instructions to an Intel processor, and it does not assume that the Windows Server Edition uses the same port or local URL as the Docker deployment.

The Docker procedure uses the project repository and Docker Compose. After the stack starts successfully, the documented application address is http://localhost:3001. That loopback address is intentionally local. A browser on the same Mac can use it, but a remote user cannot normally reach it directly.

Remote access is a separate layer. With Localtonet, our client on the Mac establishes an outbound connection to a Localtonet relay server. An HTTP tunnel can then forward its public address to the application listening locally on port 3001. The tunnel remains available only while the selected device is connected and the tunnel is running.

Choose the correct installation path

Prepare the Intel Mac

Complete the prerequisites before cloning the repository. A container deployment is easier to diagnose when Docker, Compose, Git, local storage, and network access have each been checked independently.

Intel processor and supported macOS environment

Confirm that the Mac uses an Intel processor. In macOS, open the system information interface and inspect the processor or chip entry. If the computer reports an Apple chip such as an M-series processor, this Intel-specific tutorial is not the appropriate installation path. SlowBooks Pro provides a separate macOS DMG for Apple Silicon.

The project evidence does not define a minimum supported macOS version for the Docker path. Docker Desktop's own current compatibility rules determine whether it can run on the Mac. Resolve that prerequisite before working on the accounting application.

Docker Desktop and Docker Compose

Install a current Docker Desktop build that supports the Mac and its Intel architecture. Start Docker Desktop and wait until its engine reports that it is running. Modern Docker Desktop installations normally expose Compose through the docker compose command.

Open Terminal and verify both the Docker engine and Compose command:

docker version
docker compose version

The first command should show client and server information. If it shows only client information or says it cannot connect to the Docker daemon, Docker Desktop has not finished starting or the current terminal cannot reach its engine. The second command should return a Compose version rather than an unknown-command error.

Git and repository access

Git is required to clone the SlowBooks Pro repository. Verify that it is available:

git --version

If macOS offers to install command-line developer tools, complete that installation and run the version check again. You also need outbound HTTPS access to retrieve the repository and any container images or build dependencies referenced by the Compose project.

Storage, backups, and host availability

Accounting systems accumulate records, attachments, generated reports, and database data. Ensure the Mac has adequate free storage, but do not rely on an arbitrary capacity estimate because the project evidence does not publish one for this deployment. The required amount depends on the company data and retained files.

The host must remain awake, powered on, and connected whenever browser users need the service. Docker containers cannot answer requests while the Mac is shut down or sleeping. The same condition applies to remote access: a Localtonet tunnel works only while the selected client is connected and the tunnel is running.

Install SlowBooks Pro 2026 with Docker Compose

The installation begins with the official repository. The repository contains the application source, a Dockerfile, docker-compose.yml, a production Compose file, migration files, an example environment file, and supporting scripts. This tutorial uses the default Compose workflow documented for the Docker installation.

git clone https://github.com/VonHoltenCodes/SlowBooks-Pro-2026.git
cd SlowBooks-Pro-2026

git status
git log -1 --oneline
docker compose config

docker compose up -d

docker compose ps

Optionally select the verified release tag

The supplied release evidence identifies v2.23.3 as a published SlowBooks Pro release. If you need a reproducible review of that specific release instead of the repository's current branch, select the tag before starting Compose:

git fetch --tags
git checkout v2.23.3
docker compose config
docker compose up -d

A tag checkout places Git in a detached state, which is normal when running a fixed release. Do not combine changes from a moving development branch with production accounting data unless you have reviewed the changes and prepared a rollback plan.

Why the local check comes before Localtonet

A tunnel cannot repair an application that did not start. It only transports traffic to a target that must already be reachable from the machine running our client. Separating the checks gives you a clear fault boundary:

• If http://localhost:3001 fails, investigate Docker and SlowBooks Pro.
• If the local URL works but the public URL fails, investigate the Localtonet client, tunnel state, selected device, relay selection, and local target.
• If both URLs load but an accounting action fails, investigate the application, database, permissions, or request logs rather than the network path alone.

Verify the local service before exposing it

A successful docker compose up -d command means Docker accepted the request. It does not by itself prove that every container remained healthy, that migrations completed, or that the application is usable. Perform container, HTTP, browser, and persistence checks before adding remote access.

Inspect the Compose service state

docker compose ps
docker compose logs --tail=200

Look for services that are running rather than repeatedly restarting or exiting. In the logs, distinguish ordinary startup messages from persistent exceptions. Database initialization and application startup may take time on the first run, particularly if Docker must build images or download dependencies.

The exact service names and health-check behavior are controlled by the checked-out Compose file. Do not assume names such as app, web, or db. Use the names displayed by docker compose ps when narrowing a command to one service.

Test the documented HTTP endpoint

Open this address in a browser on the Docker host:

http://localhost:3001

You can also inspect the HTTP exchange from Terminal:

curl -i http://localhost:3001/

A browser is the more useful functional test because it loads the user interface and related assets. A command-line response confirms that a process answered on the port, but an unexpected status code or partial page still requires log inspection. Do not consider the deployment ready merely because a TCP connection can be opened.

Complete a cautious functional test

Follow the first-run interface presented by the installed release. The supplied evidence does not establish universal default credentials, a fixed administrator username, or a standard password, so this guide does not guess them. If the application asks you to create an initial user, use a unique password and store it in an appropriate password manager.

Before entering real records, use non-sensitive test data to confirm that the interface remains available across page navigation. If the installation presents user or role controls, establish least-privilege accounts for future users instead of sharing an administrator login. SlowBooks Pro's documented server capabilities include administrator, bookkeeper, and read-only roles, but verify how the Docker release exposes those controls before relying on them.

Check persistence without deleting anything

After the initial setup and a non-sensitive test record, restart the Compose services:

docker compose restart

Reload http://localhost:3001 and confirm that the expected state remains. This is a basic persistence check, not a restore test and not proof that backups work. A proper recovery test requires a separately retained backup and a documented restoration procedure.

Operate the Docker deployment safely

Run Compose commands from the cloned repository directory so Docker can locate the expected project definition. If you run them from an unrelated folder, Compose may report that it cannot find a configuration file or may act on a different project.

Start and stop behavior

To pause the application while preserving the existing containers, use:

docker compose stop

Resume it with:

docker compose start

When SlowBooks Pro is stopped, the local endpoint will be unavailable. A Localtonet HTTP tunnel may still appear configured, but it cannot serve a working application when its local target is down. For a planned maintenance window, stop the tunnel as well so remote users do not encounter an unexplained application failure.

Updating requires a controlled plan

Do not update a production accounting application simply by pulling arbitrary repository changes. First identify the installed revision, read the target release notes, back up persistent data, and determine whether the target includes migrations or configuration changes. The supplied evidence confirms that release v2.23.3 exists, but it does not define a universal upgrade and rollback procedure for every earlier release.

A safe operational policy should include a maintenance window, a known source revision, a verified backup, a restoration test, post-update log inspection, and functional checks at the local URL. Only restore remote access after the application has passed those checks.

Understand what must remain running

Four layers participate in the final remote workflow:

1. The Intel Mac must be powered on, awake, and connected.
2. Docker Desktop and the required SlowBooks Pro containers must be running.
3. The Localtonet client must be connected using the intended device token.
4. The selected HTTP tunnel must be started.

Failure at any layer interrupts remote access. Local browser access tests the first two layers. The public tunnel URL tests all four.

Expose SlowBooks Pro with a Localtonet HTTP tunnel

Configure Localtonet only after http://localhost:3001 works on the Intel Mac. Our HTTP tunnel points to the existing local service and provides a public HTTPS address according to the selected HTTP process type. The Localtonet client initiates the relay connection outbound, so this workflow does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address.

The device token identifies the client device that runs the tunnel. Treat it as a secret. Relay server or region values can vary and must be selected from the current dashboard rather than copied from an old guide or hardcoded into automation.

For the current dashboard workflow, consult our Localtonet documentation alongside the fields visible in your account. Product options can vary, so the dashboard is authoritative for available relay servers, process types, and account-specific choices.

Test from outside the Mac

Testing the public URL only from the host browser can miss session and network differences. Open it from a private browser window or another authorized device. Confirm that unauthenticated visitors do not gain access to accounting records and that an authorized user can sign in and complete the intended operation.

Keep the local and public tests distinct. If the public URL fails, immediately retest http://localhost:3001 on the Mac. This determines whether to inspect Docker or the tunnel layer first.

Secure accounting access and data

Accounting deployments contain information with operational, financial, and privacy consequences. Remote access should therefore be designed around explicit authorization rather than convenience alone. Localtonet removes the need to expose an inbound router port, but it does not replace application authentication, host maintenance, database backups, or user governance.

Apply least privilege

Give each person an individual account when the installed SlowBooks Pro mode supports it. Use read-only access for users who only need reports, bookkeeping access for users who enter transactions, and administrative privileges only for people who manage the system. Avoid a shared administrator password because it weakens accountability and makes offboarding difficult.

Protect the Mac

Enable appropriate macOS account security, protect the device with a strong login credential, install operating-system security updates, and restrict physical access. Docker Desktop, Git, the browser, and the Localtonet client should also be maintained. Do not run unrelated untrusted containers on a host that processes sensitive accounting data.

Protect secrets

Device tokens, application credentials, database credentials, AI-provider keys, payment credentials, and other integration secrets must not be committed to the repository. Keep secret-bearing files out of screenshots and support bundles. If a token or password is exposed, replace it rather than assuming deletion from a public location is sufficient.

SlowBooks Pro documents optional AI integrations and a local REST API. If those features are enabled, understand what data each configured provider receives. A cloud-backed model can receive figures supplied to it under that provider's terms. Only a locally operated model that has been checked for outbound behavior can be treated as keeping all processing local.

Build a real backup process

A backup policy should identify all persistent application and PostgreSQL data, define retention, store copies separately from the Mac, and include restoration testing. A copy that has never been restored is not yet a proven recovery mechanism. Protect backup files because they may contain the same sensitive records as the live system.

The exact supported SlowBooks Pro backup and restoration commands are not established by the supplied installation evidence, so we do not invent database dump commands, container paths, volume names, or application backup locations. Determine those details from the installed release and test them with non-production data before relying on them.

Stop access when it is not required

A Localtonet tunnel can be stopped without deleting its configuration. Stop it during maintenance, incident investigation, or extended periods when no remote user needs access. Delete obsolete tunnels and retire device tokens that are no longer associated with an approved host.

Troubleshoot the installation and tunnel

Docker commands cannot connect to the daemon

Start Docker Desktop and wait for its engine to become ready. Run docker version again. If the server portion is still unavailable, resolve Docker Desktop before retrying Compose. Re-cloning SlowBooks Pro will not repair an unavailable Docker engine.

Compose reports that no configuration file exists

Confirm that Terminal is in the cloned repository directory:

pwd
ls
git status

The listing should show the repository files, including docker-compose.yml. If git status says the directory is not a Git repository, navigate back to the cloned SlowBooks-Pro-2026 directory.

Compose reports an invalid or missing variable

Run:

docker compose config

Read the complete error and compare it with the checked-out release's .env.example and installation documentation. Do not solve the error with arbitrary credentials or values from an unrelated release. Keep any completed environment file out of version control.

A container exits or continuously restarts

Inspect status and recent logs:

docker compose ps
docker compose logs --tail=300

Look at the earliest meaningful error, not only the final restart message. Common categories include a failed dependency, database initialization problem, migration failure, unavailable storage, configuration error, or port conflict. The exact remedy depends on the emitted error and the service identified by Compose.

Port 3001 is already in use

Another host process or container may already be bound to the documented port. Identify the owner before changing anything:

lsof -nP -iTCP:3001 -sTCP:LISTEN

Stop the conflicting service only if you recognize it and understand its role. The supplied project evidence documents port 3001 for this Docker endpoint but does not establish a supported alternate-port procedure, so this guide does not invent a Compose override. If an alternate binding is required, follow the configuration supported by the exact SlowBooks Pro release.

The browser cannot open localhost:3001

First run docker compose ps. If the services are not running, inspect logs. If they are running, verify that the displayed port mapping includes the expected host port. Test with curl -i http://localhost:3001/. A refusal usually means no process is accepting the connection, while an HTTP response with an application error indicates that the port is reachable and the next investigation belongs in the application logs.

The local URL works but the Localtonet URL does not

Confirm that the Localtonet client is connected on the correct device, the intended HTTP tunnel is started, an available relay was selected, and the target is 127.0.0.1 on port 3001. Remember that saving or creating the tunnel is not the same as starting it.

If the Localtonet client is running on another machine, 127.0.0.1 points to that other machine, not to the Intel Mac. For the workflow documented here, run our client directly on the Docker host.

The public page loads but application actions fail

Reproduce the same action through http://localhost:3001. If it fails locally too, inspect SlowBooks Pro and Compose logs. If it fails only through the public address, record the browser error, HTTP status, time, and exact operation, then examine the tunnel state and application logs without exposing sensitive request data.

The service disappears when the Mac is unattended

Check whether the Mac entered sleep, Docker Desktop stopped, the containers exited, the Localtonet client disconnected, or the tunnel was stopped. Remote availability requires every layer to remain active. Choose host sleep and maintenance settings that match your security policy, energy requirements, and expected access schedule.

Frequently asked questions