How to Deploy PocketBase on a VPS

#Install PocketBase

Grab the current release directly from GitHub rather than hardcoding a version number that will go stale — this resolves whatever the latest tagged release is at the time you run it:

copysudo apt-get update && sudo apt-get install -y unzip curl

PB_VERSION=$(curl -fsSL https://api.github.com/repos/pocketbase/pocketbase/releases/latest \
  | grep '"tag_name"' | cut -d '"' -f4)
echo "Installing PocketBase ${PB_VERSION}"

sudo mkdir -p /opt/pocketbase
curl -LO "https://github.com/pocketbase/pocketbase/releases/download/${PB_VERSION}/pocketbase_${PB_VERSION#v}_linux_amd64.zip"
sudo unzip -o "pocketbase_${PB_VERSION#v}_linux_amd64.zip" -d /opt/pocketbase
rm "pocketbase_${PB_VERSION#v}_linux_amd64.zip"
sudo chown -R deploy:deploy /opt/pocketbase

That unpacks a single pocketbase executable into /opt/pocketbase. Running it directly confirms the binary works before you wire it into systemd:

copy/opt/pocketbase/pocketbase --version

Run it as a systemd service, not a terminal session that dies on disconnect. Bind to loopback only — --http=127.0.0.1:8090 — because Caddy is about to become the only thing the internet can reach:

copysudo tee /etc/systemd/system/pocketbase.service > /dev/null <<'EOF'
[Unit]
Description=PocketBase
After=network.target

[Service]
Type=simple
User=deploy
Group=deploy
WorkingDirectory=/opt/pocketbase
ExecStart=/opt/pocketbase/pocketbase serve --http=127.0.0.1:8090
Restart=always
RestartSec=5
LimitNOFILE=4096

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now pocketbase
sudo systemctl status pocketbase

WorkingDirectory=/opt/pocketbase is what determines where the pb_data directory (database, uploads, logs) gets created — pass --dir explicitly instead if you want it somewhere else.

#HTTPS + domain

Create an A record for your subdomain (e.g. pb.example.com) pointing at the server's public IP, and confirm it resolves before requesting a certificate:

copydig +short pb.example.com

Then put Automatic HTTPS with Caddy in front of the loopback address PocketBase is already listening on — the whole config is one block:

copypb.example.com {
    reverse_proxy 127.0.0.1:8090
}

Because PocketBase sits behind a proxy, it sees every request coming from 127.0.0.1 unless you tell it otherwise. Set the trusted proxy headers under Dashboard → Settings → Application (or the equivalent pocketbase.io docs section on reverse proxies) so rate limiting, logs, and auth rules see the real client IP from X-Forwarded-For rather than the proxy's own address.

#First superuser and hardening

Create the first admin account from the command line rather than exposing an open signup page to the internet — PocketBase has no public registration for superusers by default, but setting it explicitly up front avoids ever depending on the dashboard's first-run flow being reachable before anything else is:

copysudo -u deploy /opt/pocketbase/pocketbase superuser create you@example.com 'a-long-random-password'

Then, before opening the app up to real users:

1. Load https://pb.example.com/_/ and confirm you can sign in as that superuser — this is the admin dashboard, separate from your app's own collections and API.
2. Set collection-level API rules deliberately. PocketBase collections are locked down by default (empty rule = admin-only); every collection you expose to your app's users needs its own list/view/create/update/delete rules reviewed, not left on whatever the scaffold generated.
3. Turn on the encrypted-settings env var (--encryptionEnv=SOME_VAR, set as an Environment= line in the systemd unit) if you store OAuth secrets or SMTP credentials in PocketBase's own settings, so they aren't sitting in pb_data/data.db in plaintext.
4. Keep /opt/pocketbase and pb_data owned by the deploy user only — the systemd unit already runs as that user, not root; don't widen the permissions to fix an unrelated problem.

#Backups

Everything PocketBase owns lives under one pb_data directory, which makes backup strategy simple: back that directory up, and you have the database, uploaded files, and migrations in one piece.

Built-in backups (simplest). From Dashboard → Settings → Backups, PocketBase can produce a ZIP snapshot of pb_data on demand or on a schedule, and ship it to local disk or an S3-compatible bucket. For a personal or small-team instance this is enough on its own — point it at object storage so the backup survives the VPS itself dying.

Manual backup (scriptable, cron-friendly). Stop the service first so the SQLite file isn't mid-write when you copy it:

copysudo systemctl stop pocketbase
tar -czf "pocketbase-backup-$(date +%F).tar.gz" -C /opt/pocketbase pb_data
sudo systemctl start pocketbase

Move the archive off the box — object storage, another machine, your laptop — and restore it once into a throwaway instance so you find out now, not during an outage, that the archive is actually complete: unzip it into a fresh pb_data, point a test binary at it with --dir, and confirm your data is there.

#Upgrades

PocketBase upgrades are a binary swap, not a package manager operation:

copysudo systemctl stop pocketbase
PB_VERSION=$(curl -fsSL https://api.github.com/repos/pocketbase/pocketbase/releases/latest \
  | grep '"tag_name"' | cut -d '"' -f4)
curl -LO "https://github.com/pocketbase/pocketbase/releases/download/${PB_VERSION}/pocketbase_${PB_VERSION#v}_linux_amd64.zip"
sudo unzip -o "pocketbase_${PB_VERSION#v}_linux_amd64.zip" -d /opt/pocketbase
rm "pocketbase_${PB_VERSION#v}_linux_amd64.zip"
sudo chown -R deploy:deploy /opt/pocketbase
sudo systemctl start pocketbase

Take a pb_data backup first (previous section) — PocketBase applies database migrations automatically on startup, and those are one-way. Skim the release notes before jumping a minor version; a single-maintainer project moves fast and occasionally changes a default.

#Troubleshooting

systemctl status pocketbase shows the service repeatedly restarting. Run the ExecStart command by hand as the deploy user (/opt/pocketbase/pocketbase serve --http=127.0.0.1:8090) to see the actual error instead of systemd's exit code — a bad --dir permission or a port already in use are the usual causes.

The dashboard loads over HTTP but Caddy never gets a certificate. Confirm dig +short pb.example.com actually resolves to the server, and that your cloud provider's network-level firewall (not just ufw on the box) allows inbound 80 and 443 — a provider firewall blocking port 80 silently breaks the ACME challenge with nothing in Caddy's own logs to explain why.

Rate limiting or audit logs show the proxy's IP instead of real clients. The trusted-proxy header setting from the HTTPS section above wasn't applied — every request is arriving from 127.0.0.1 as far as PocketBase can tell until you configure it to trust X-Forwarded-For from the proxy.

A restore comes back with the app running but files or auth broken. The restore only copied part of pb_data. Database, uploads, and migrations all live in that one directory — a partial copy (say, database only) is not a complete restore.

#Verification + next steps

You're done when you can: load https://pb.example.com/_/ with a valid certificate, sign in as the superuser you created from the CLI, confirm systemctl is-enabled pocketbase reports enabled (it survives a reboot), create a collection with API rules you set deliberately rather than left on defaults, and restore a backup archive you've actually tested.

From there, the natural next steps are wiring up the JS or Dart SDK from your frontend, configuring OAuth2 providers under Settings → Auth providers if you need social login, and turning on the built-in email service (or your own SMTP) so account verification and password-reset mail actually sends. For the ranked VPS picks for this workload, see Best VPS for PocketBase.