Deploying PocketBase

PocketBase Cloud gives you a fully managed PocketBase instance with automatic HTTPS, backups, and a dedicated admin panel. You can create one from the portal or from your terminal — both produce the same thing.

Prerequisites

• An active PocketBase Cloud account with a plan subscription
• A project (Creating a Project)
• For the CLI path: pbc installed and logged in (Installing the CLI)

Step 1: Create the instance

Using the portal

1. Open your project from the Projects page and click the PocketBase tab
2. Click New PocketBase
3. Keep the auto-generated name or type your own (e.g., api or main-db)
4. On Starter, pick a region (or leave Any region); on Pro, pick your dedicated compute. Free is placed automatically.
5. Under Advanced Configuration, optionally tune the runtime flags (dev mode, hooks pool size, query timeout)
6. Click Create

You’ll be taken to the provisioning page, where you can watch the progress.

Using the CLI: an empty instance

If you only want the database — from a script, from a CI step, or before there is anything to deploy — create provisions one and stops there:

pbc pocketbase create my-app-db

Nothing is built, packaged, or uploaded. The instance is recorded in this directory’s pbc.json, exactly as a deploy would record it, so shipping files to it later takes no flags:

# …add pb_hooks/, pb_migrations/, pb_public/ when you have them
pbc pocketbase deploy   # no --name: the binding is already there

--env <name> records it under another environment (default: production, or the file’s own default). A directory bound to frontends or backends is refused, and so is an environment that already names an instance — repointing it would leave the old one with nothing pointing at it.

A name already used by an instance in the project is refused rather than duplicated — redeploy that one with pbc pocketbase deploy --name my-app-db.

create takes the same --location, --compute, --pb-version, --admin-email and --admin-password flags as the deploy below, plus three runtime flags and a restore flag:

Restoring a backup at creation

A backup ZIP (from Settings → Backups in any instance’s admin panel, or from pbc admin settings backup download) can seed a new instance — schema, records, uploaded files, and superusers arrive as they were:

Using the portal

1. On the create form, switch Admin Credentials & Mode to Restore Backup
2. Upload the backup .zip (max 150 MB). The instance name is suggested from the file name — keep it or type your own
3. Click Create. The preserved superusers stay valid; the printed credentials step is skipped because PocketBase Cloud never sees them

Using the CLI

pbc pocketbase create restored-db --backup backup.zip

Admin login: preserved from backup; credentials are not available to PocketBase Cloud.

Log in with the same superuser email and password the backup was taken with.

Using the CLI: deploying a directory

Run deploy in the directory holding your PocketBase project — the one with pb_public, pb_hooks, and pb_migrations (see Local Development for how to scaffold one). None of the three directories is required: a directory holding none of them still deploys, sends no archive at all, and creates the instance empty — the same result as pbc pocketbase create, reached from a directory.

cd db
pbc pocketbase deploy --name my-app-db

pbc deploy --name my-app-db does the same: any of pb_hooks, pb_migrations, or pb_public identifies the directory as a PocketBase project, so the CLI runs this command for you. See One deploy command for all three.

The CLI packages the directory, creates the instance, waits for it to come up, and prints the URL plus a generated superuser login:

Creating my-app-db (environment: production)…
  status: creating
  status: running
Done: my-app-db is running.
  https://my-app-db.pocketbasecloud.com
Admin login: [email protected] / xxxxxxxxxxxx

Provisioning typically takes 30–60 seconds on either path.

Step 2: Grab the credentials

A new instance gets a superuser account: your account email, and a generated password.

Using the portal

The instance detail page shows the URL, admin email, and admin password.

Using the CLI

The password is printed once, when the deploy finishes. To read it later:

pbc pocketbase info --name my-app-db

Override either credential at creation with --admin-email / --admin-password.

Step 3: Redeploy

Deploying again replaces the running version.

Using the portal

Open the instance and click Deploy, then drop the project files or a ZIP holding them. The dialog previews what will go up and reports what was stripped as local junk. What it may contain mirrors what the CLI ships:

• pb_migrations/ is merged with the migrations already on the instance, so the ones its admin UI generated are kept. New ones apply on the restart that follows.
• pb_public/ is replaced wholesale, so files dropped from your build stop being served.
• pb_hooks/ is ignored by the upload — hooks are edited in place on the Hooks tab, or pushed with pbc pocketbase deploy.
• pb_data/ and the PocketBase binary are never writable from an upload.

Using the CLI

The first deploy records the instance in pbc.json in that directory, so from then on:

pbc pocketbase deploy    # redeploys the linked instance

Every deploy — portal or CLI — is recorded in the Deployments list on the instance detail page.

What the platform does for you

On either path, PocketBase Cloud automatically:

• Selects a server based on your plan and current capacity (Free and Starter), or uses your dedicated compute (Pro)
• Assigns a port and generates superuser credentials
• Provisions the instance and sets up DNS
• Issues an HTTPS certificate

Once complete, your instance is live at:

https://<instance-name>.pocketbasecloud.com

and its admin panel at:

https://<instance-name>.pocketbasecloud.com/_/

The detail page lists the platform URL plus the admin and API URLs, and a verified custom domain next to them when one is set.

A brand-new domain can take a few minutes to answer while its certificate is issued, even after the status reads running. An error right after a deploy usually means “wait a moment”, not “the deploy failed”.

What gets deployed

The CLI ships the directory’s pb_public, pb_hooks, and pb_migrations on every deploy, so your schema and hooks are in place from the first boot and stay in step afterwards. Their locations come from the build block in pbc.json:

// db/pbc.json
{
  "build": {
    "pbPublic": "pb_public",
    "pbHooks": "pb_hooks",
    "pbMigrations": "pb_migrations"
  }
}

On a redeploy the same directories go up, by two routes: pb_hooks/*.pb.js through the hooks route (so the portal’s hook editor stays in sync), and pb_migrations / pb_public in the archive, which the platform installs on the running instance. Migrations are merged — files already on the instance, including ones its admin panel generated, are kept — while pb_public is replaced, so files dropped from your build stop being served. Your database is never touched, and new migrations are applied by the restart that follows.

Managing your instance

From the portal’s instance detail page you can view connection details, edit hooks, stream logs, manage environment variables, and delete the instance. The CLI equivalents:

pbc pocketbase ls                     # statuses at a glance
pbc pocketbase info --name my-app-db  # URL, version, server, admin login
pbc logs pocketbase --name my-app-db -f
pbc pocketbase rm --name my-app-db

See Managing Your Instance for backups, exports, and instance settings.

Using PocketBase hooks

Hooks let you add custom server-side logic. In the portal, use the instance’s Hooks tab; from the CLI, keep them in pb_hooks/ and push with pbc pocketbase deploy or pbc pocketbase hooks push. Either way they can add API routes, react to record changes, schedule cron jobs, and send email — see Extending with Hooks.

Next steps

• Connect your app with the JavaScript SDK
• Add user authentication
• Set up collections and API rules