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: pb 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. Enter a name for your instance (e.g., api or main-db)
4. On Starter, pick a region; on Pro, pick your dedicated compute
5. 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:

pb cloud pb create my-app-db

Nothing is built, packaged, or uploaded. The instance is recorded in this directory’s pb.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
pb cloud pb 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 pb cloud pb deploy --name my-app-db.

create takes the same --location, --compute, --pb-version, --admin-email and --admin-password flags as the deploy below.

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 pb cloud pb create, reached from a directory.

cd db
pb cloud pb deploy --name my-app-db

pb cloud 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: you@example.com / 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:

pb cloud pb 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 go to Deployment, then upload a ZIP of your project. 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 pb cloud pb deploy.
• pb_data/ and the PocketBase binary are never writable from an upload.

Using the CLI

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

pb cloud pb deploy    # redeploys the linked instance

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/_/

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 pb.json:

// db/pb.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:

pb cloud pb ls                     # statuses at a glance
pb cloud pb info --name my-app-db  # URL, version, server, admin login
pb cloud logs pb --name my-app-db -f
pb cloud pb 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 pb cloud pb deploy or pb cloud pb 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