Quickstart

Install Busabase on your own server with one command, check it actually worked, and activate your licence — including on a network with no internet access.

This is the same guide published at busabase.com/self-hosted/install. It is repeated here because the docs ship inside the image: on a network that cannot reach busabase.com, this page still opens.

What the host needs

CPU

2 vCPU

Memory

2 GB

Disk

10 GB

Open port

3000 + 8333/tcp

Measured on a cold start with an empty volume: 24s to a healthy server, 548 MiB idle, 50 MB in /data after first boot. Two ports: the app, and object storage — the browser fetches attachments straight from storage, so it has to be reachable. Postgres stays inside the container.

docker run -d --name busabase \
  -p 3000:3000 \
  -p 8333:8333 \
  -v busabase-data:/data \
  --restart unless-stopped \
  busabase/busabase-premium-allinone:trial

Check it worked

Do not guess from the container being up. Ask the server itself; it answers before anyone signs in.

curl -s http://localhost:3000/api/health

A healthy server replies with:

{"status":"ok","service":"busabase","version":"0.10.0", ...}

Activate your licence

Open the server, sign in as the administrator, and go to System Admin → Licence. Paste the activation code there; it is verified on the machine itself and needs no internet access. Codes are issued from your Busabase Cloud account under Settings → Self-hosted licence.

Installing on a network with no internet access

Move the image as a file. The tarball is about 489 MB; check the hash on arrival, because a truncated transfer surfaces much later as a confusing runtime error.

# On a machine with internet access
docker pull busabase/busabase-premium-allinone:latest
docker save busabase/busabase-premium-allinone:latest -o busabase-premium-allinone.tar
sha256sum busabase-premium-allinone.tar > busabase-premium-allinone.tar.sha256

# Move both files to the target host, then
sha256sum -c busabase-premium-allinone.tar.sha256
docker load -i busabase-premium-allinone.tar

It will not start

Collect a diagnostic bundle and send it to support@busabase.com. It contains logs, health output and image metadata — no credentials: the generated secrets are written to /data/.credentials and never logged.

docker logs --tail 500 busabase > sb-logs.txt 2>&1
curl -s http://localhost:3000/api/health > sb-health.json
docker inspect busabase --format '{{.Config.Image}} {{.State.Status}}' > sb-meta.txt
tar czf busabase-support.tar.gz sb-logs.txt sb-health.json sb-meta.txt

What happens on first boot

The container generates its own credentials — the Postgres password, the object-storage keys, the session secret — writes them to /data/.credentials with mode 600, and reuses them on every later start. Nothing is baked into the image, so two people who pull the same image do not end up sharing secrets.

It then runs the database migrations and starts the app. On an empty volume this takes about 24 seconds end to end, most of it Postgres initialising itself for the first time. Later restarts skip both and are much faster.

Back up /data/.credentials along with your data. It is the only copy of those secrets — regenerating them would leave you with a database you cannot open.

Setting up for real use → Production with Compose
Activating or renewing → Licensing
Something went wrong → Troubleshooting