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.
Start a pinned PocketBase backend with its API, authentication, realtime subscriptions, file storage, and administration UI protected by generated credentials.
Candidate release
PocketBase
SOURCE
Git
REGION
de
ROUTE
HTTPS
01Source received
02Build completed
03Runtime started
04Health check passed
Promoted route
production.adios.run
A production path for
The production path
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.
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.
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.
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
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.
Bring the existing repository, or inspect and deploy one of the exact starter variants linked below.
$adios loginKeep commands, runtime or service version, health behavior, and secret references in adios.yaml.
$git diff -- adios.yamlFollow build and runtime evidence, verify the candidate, and open the promoted route or service connection.
$adios uptype: 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: trueDeployable starting points
Inspect the complete PocketBase starter, clone its standalone repository, or deploy it directly with the public pocketbase key.
Web apps
PocketBase 0.39.10 with persistent SQLite data, generated superuser credentials, and built-in auth and realtime APIs.
git clone https://github.com/adiosdotdev/template-pocketbase.git
cd template-pocketbase
adios upBefore production
The safest first release starts with a reproducible build or service configuration and a preview that exercises the dependencies production will actually use.
Questions, answered
Review the runtime or service boundary, template path, failure behavior, and production checks before creating the first release.
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.
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.
Open /_/ on the generated HTTPS route. The starter provisions admin@pocketbase.local and stores its generated password as an Adios secret.
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.
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.
Verify authentication, application connectivity, write and read behavior, restart persistence, backup or recovery expectations, capacity, and the failure behavior of every dependent application.
Related deployment paths
Deploy the frontend, API, or worker that connects to Supabase. Adios runs the application release; your Supabase project remains the external database and backend service.
Deploy a persistent Node.js web process or worker from its existing package scripts, with release health, logs, secrets, routing, and Git history attached.
Choose a PostgreSQL version, keep database credentials out of Git, attach persistent storage, connect the application, and verify data after a restart.
Publish HTML, CSS, JavaScript, or a framework-generated static build from a small Nginx starter with routes, domains, TLS, and release state attached.
The first release
Start from the repository or a template, review the deployment contract, and inspect what becomes the promoted production version.