Adios
Apps and platforms · plans from $10/month

Deploy PocketBase.Keep the compact backend durable.

Start a pinned PocketBase backend with its API, authentication, realtime subscriptions, file storage, and administration UI protected by generated credentials.

Keep the repositoryInspect build and logsCustom domains and TLS
Adios deploy

Candidate release

PocketBase

Healthy

SOURCE

Git

REGION

de

ROUTE

HTTPS

01Source received

02Build completed

03Runtime started

04Health check passed

Promoted route

production.adios.run

A production path for

PocketBase 0.39.10SQLiteAuthenticationRealtimePersistent files

The production path

A working PocketBase project still needs a safe release.

The application or service is only one part of production. Build evidence, runtime state, health, secrets, logs, routes, and the promoted version should remain inspectable together.

Start PocketBase from a versioned template

The official template downloads PocketBase 0.39.10 for amd64 or arm64, verifies its pinned checksum, generates an encryption key and superuser password, and provisions the first administrator idempotently.

Make persistence an explicit decision

The SQLite database, uploaded files, settings, and local backups share one persistent /app/pb_data volume. The starter intentionally runs one replica to keep that state coherent.

Keep service state visible to operators

Use /api/health for readiness, open /_/ for administration, and back up the data volume together with the stable encryption and superuser secrets.

From source to release

Three steps keep the deployment path reviewable.

Use the source and production behavior the project already has. The manifest records what the platform should build or provision and how the result becomes ready.

  1. 01

    Start with source or a template

    Bring the existing repository, or inspect and deploy one of the exact starter variants linked below.

    $adios login
  2. 02

    Review the deployment contract

    Keep commands, runtime or service version, health behavior, and secret references in adios.yaml.

    $git diff -- adios.yaml
  3. 03

    Deploy and inspect the result

    Follow build and runtime evidence, verify the candidate, and open the promoted route or service connection.

    $adios up
adios.yaml
Your project
type: api
replicas: 1
secrets:
  PB_ENCRYPTION_KEY: secret://generate:32
  PB_SUPERUSER_PASSWORD: secret://generate:32
build_cmd: sh /app/install-pocketbase.sh
start_cmd: sh /app/start-pocketbase.sh
port: 8090

runtime:
  health_path: /api/health
  volumes:
    - name: pocketbase-data
      target: /app/pb_data
      persistent: true
The complete starter pins architecture-specific release checksums and sets the initial superuser email to admin@pocketbase.local.

Deployable starting points

Start PocketBase from a template when the repository is not ready.

Inspect the complete PocketBase starter, clone its standalone repository, or deploy it directly with the public pocketbase key.

Web apps

PocketBase 0.39.10

PocketBase 0.39.10 with persistent SQLite data, generated superuser credentials, and built-in auth and realtime APIs.

Go / SQLiteUpstream release
Template key
pocketbase
Runtime
pinned binary
Repository
template-pocketbase
Source path
.
git clone https://github.com/adiosdotdev/template-pocketbase.git
cd template-pocketbase
adios up

Before production

Verify the workload.Then promote it.

The safest first release starts with a reproducible build or service configuration and a preview that exercises the dependencies production will actually use.

Ready when…

  • The generated superuser password is retrieved securely.
  • The administration UI is available only on the intended route.
  • Database records and uploaded files survive a new release.
  • Data and encryption-secret recovery are tested together.

Preview when…

  • A migration or hook changes the data model.
  • Large uploads change disk and backup requirements.
  • The workload is expected to run more than one replica.

Questions, answered

What to know before deploying PocketBase.

Review the runtime or service boundary, template path, failure behavior, and production checks before creating the first release.

Can I deploy PocketBase from an official template?

Yes. Choose the PocketBase template that matches the version or configuration you need, store credentials as Adios secrets, and deploy it from the console or with adios up.

Does the PocketBase template use persistent storage?

The SQLite database, uploaded files, settings, and local backups share one persistent /app/pb_data volume. The starter intentionally runs one replica to keep that state coherent.

Where is the PocketBase administration UI?

Open /_/ on the generated HTTPS route. The starter provisions admin@pocketbase.local and stores its generated password as an Adios secret.

Can this PocketBase template run multiple replicas?

Not safely with its local SQLite and file-storage baseline. It deliberately runs one replica; choose a different architecture if the application requires horizontally replicated backend state.

Where should database and broker passwords be stored?

Store sensitive values in Adios secrets and reference them with secret://NAME. Do not place production credentials directly in adios.yaml or commit them to Git.

What should I verify before production traffic?

Verify authentication, application connectivity, write and read behavior, restart persistence, backup or recovery expectations, capacity, and the failure behavior of every dependent application.

The first release

Deploy PocketBase with the source and evidence attached.

Start from the repository or a template, review the deployment contract, and inspect what becomes the promoted production version.