How to Self-Host Actual Budget in 2026: Sync, HTTPS and Financial Data Backups

A failed Actual Budget deployment does not always crash. It may serve a login page while the sync directory is ephemeral or a proxy strips large sync requests. Start with an end-to-end check instead: create or import a budget, add transactions, sync a second browser and produce an application-level export.

That check matches the cataloged purpose of Actual Budget: envelope budgeting with data kept on your disk. It also exposes missing dependencies, wrong proxy assumptions and ephemeral data earlier than an uptime probe can.

Separate Actual Budget from its dependencies

Start with the Actual Budget network namespace: its web listener is port 5006, not a host port copied from a laptop tutorial. The local runtime requirement is one durable data volume and a supported browser for initial setup. Keep its lifecycle explicit so moving Actual Budget between hosts does not silently change behavior.

After the requirement is satisfied, run the complete scenario — create or import a budget, add transactions, sync a second browser and produce an application-level export. Record logs and measurements for budget file size, sync traffic and server storage rather than heavy server-side calculation. That evidence becomes the first known-good architecture and makes later moves between Dockup compute and an attached server testable.

Run the first production-shaped instance

A minimal command is useful when it reveals what the platform will later manage.

docker run -d \
  --name actual-budget \
  --restart unless-stopped \
  -p 127.0.0.1:5006:5006 \
  -v actual-budget-data:/data \
  -e ACTUAL_PORT=5006 \
  actualbudget/actual-server:latest

Here port 5006 remains host-private and every required path is explicit. Confirm the local requirement before exposure: one durable data volume and a supported browser for initial setup. Verify startup with both logs and the application-specific proof: create or import a budget, add transactions, sync a second browser and produce an application-level export. Once verified, lock the image version so a routine replacement does not silently change behavior.

Make the public origin unambiguous

Choose the final Actual Budget hostname before users save callbacks or client settings, then use a stable HTTPS URL so sync clients trust the server. The platform route should terminate TLS once and target private port 5006.

Run the acceptance transaction externally. If the client never reaches Actual Budget, use the SSL validation checklist for DNS and certificate checks. If the request reaches Actual Budget but the sync directory is ephemeral or a proxy strips large sync requests, stop changing proxy redirects and inspect the application-specific boundary instead.

Make Actual Budget recovery measurable

Make a recovery manifest for Actual Budget: server files plus periodic application-level budget exports. Mount /data before bootstrap, write harmless sample data and replace the container to prove that path is actually persistent. Check ownership and free space now, because a mounted but unwritable path behaves like no persistence at all.

Back up to a failure domain separate from the running server. Recreate Actual Budget from its pinned image and verify that the restored server syncs the same accounts and balances and the independent export can also be imported. The persistent-volume guide helps translate that exercise into snapshot and retention policy.

Lock down Actual Budget after bootstrap

Bootstrap credentials are temporary; the trust model is permanent. With Actual Budget, watch for publishing a finance server before configuring its password, and set the server password before exposure and use HTTPS because the instance contains complete financial history.

ACTUAL_PORT controls behavior rather than confidentiality; validate its type and value, and store genuine Actual Budget credentials separately. Run the image without unnecessary Linux capabilities and expose only the public application route. Keep administrator activity visible without recording secret values.

Operate Actual Budget around its real bottleneck

Build dashboards around budget file size, sync traffic and server storage rather than heavy server-side calculation. A CPU graph without that workload context cannot explain why Actual Budget is slow. Add a synthetic or scheduled check that tries to create or import a budget, add transactions, sync a second browser and produce an application-level export using harmless test data.

Before upgrading, account for this application-specific hazard: Actual's data migrations should be tested with both server files and an exported budget available for rollback. Restore a recent backup into an isolated deployment, run migrations there and compare behavior. If the sync directory is ephemeral or a proxy strips large sync requests, inspect the boundary involved — public origin, storage or dependency — before touching unrelated settings.

Evidence to collect before Actual Budget goes live

Create a small, disposable Actual Budget fixture and keep it for every release. The fixture should exercise the real workflow: create or import a budget, add transactions, sync a second browser and produce an application-level export. Record the image digest, external hostname, dependency address and the expected result so a later operator can repeat the test without interpreting this guide.

Run the fixture three times. First, use the fresh deployment. Second, replace the container without touching durable state. Third, restore the backup into an empty environment. The third run passes only when the restored server syncs the same accounts and balances and the independent export can also be imported. During each run, capture latency and resource use around budget file size, sync traffic and server storage rather than heavy server-side calculation; this becomes the baseline for alerts rather than an arbitrary CPU percentage.

Finally, test the negative path deliberately: submit harmless input near the resource or format limit associated with this boundary: the sync directory is ephemeral or a proxy strips large sync requests. Confirm that Actual Budget fails visibly without corrupting state, restore the correct condition and repeat the successful transaction. A release record containing those four outcomes is stronger evidence than screenshots of a dashboard or a one-time curl response.

Move the repeatable infrastructure work to Dockup

Dockup can own the replaceable platform pieces: route traffic to port 5006, issue the domain and certificate, inject secrets, attach persistent storage and connect Actual Budget to managed or privately attached services. It can do this on Dockup infrastructure or on a server you attach.

The Actual Budget acceptance work remains explicit. After the one-click deployment, use a stable HTTPS URL so sync clients trust the server, confirm the local requirement — one durable data volume and a supported browser for initial setup and run this scenario: create or import a budget, add transactions, sync a second browser and produce an application-level export. That division is intentional: Dockup removes repetitive infrastructure setup without pretending that application roles, provider credentials or restore policy choose themselves.

Frequently asked questions

What does Actual Budget need for a production deployment?

Route the Actual Budget container on port 5006 through one HTTPS origin. The local runtime requirement is one durable data volume and a supported browser for initial setup. Do not call Actual Budget ready until you can create or import a budget, add transactions, sync a second browser and produce an application-level export.

Which Actual Budget data belongs in a backup?

Persist /data and include server files plus periodic application-level budget exports in the same recovery manifest. A clean Actual Budget restore passes only when the restored server syncs the same accounts and balances and the independent export can also be imported.

Does Actual Budget require HTTPS behind a reverse proxy?

Use HTTPS for the public Actual Budget origin and keep port 5006 on the internal route. Apply the Actual Budget setting correctly: use a stable HTTPS URL so sync clients trust the server. For Actual Budget, HTTPS protects credentials or user content in transit and keeps origin-sensitive client behavior consistent.

How should an Actual Budget upgrade be tested?

Restore current Actual Budget state into an isolated deployment, apply the candidate version and repeat its acceptance transaction. Pay particular attention because Actual's data migrations should be tested with both server files and an exported budget available for rollback. Keep the previous Actual Budget image until its data-migration and rollback boundary are understood.