Skip to content
DocsFrontendDeploying a Frontend

Deploying a Frontend

PocketBase Cloud hosts single-page applications with HTTPS on an address the platform assigns — ideal for the frontend of the app whose data lives in your PocketBase instance. Build your SPA with React, Vue, Svelte, Vite, or another client-side tool that produces an index.html entry point and static assets.

All plans include frontend hosting (5 frontends on Free and Starter, unlimited on Pro).

There are two ways to ship one: upload a ZIP in the portal, or run pbc frontend deploy in the project directory. The CLI path runs your build, packages the output, and uploads it in one command.

Build-time configuration

Whichever path you take, your PocketBase URL is baked in at build time — frontends have no server-side environment store:

VITE_POCKETBASE_URL=https://<instance-id>.<compute>.pocketbasecloud.com npm run build

Copy the exact URL from the instance’s page in the portal, or from pbc pocketbase info --name my-db.

Step 1: Build your site

npm run build

This produces a folder containing your SPA entry point and static assets — typically dist/ for Vite projects or build/ for Create React App.

The CLI runs this step for you as part of deploy, so you only need it by hand for the portal path or to check the output before shipping.

Step 2: Deploy

Using the portal

  1. Open your project and go to the Frontends tab
  2. Click New Frontend — the name is auto-generated, edit it if you like
  3. Drag your project files, folders, or a ready-made ZIP into the upload area. Local junk (node_modules, .git, .env*, logs) is stripped before upload, and a single wrapper folder is unwrapped for you
  4. Review the file list and click Create — the first deploy ships with creation, so there is no separate upload step

Using the CLI

cd web
pbc frontend deploy --name web

That single command runs the build, zips the output directory, uploads it, creates the frontend if it doesn’t exist, and waits for it to come up.

pbc deploy --name web does exactly the same thing: it recognises a static site — by its vite/svelte/vue/angular config, a bundler dependency, or an index.html — and runs this command for you. See One deploy command for all three.

Flag What it does
--name <name> Which frontend to deploy. Asked for when omitted and nothing is linked.
--skip-build Package the output directory without rebuilding
--zip <file> Upload an archive you built yourself
--location <loc> Region for the deployment (Starter)
--compute <id> Compute to deploy onto. Asked for on Pro, and in an organization’s project, when there is more than one. List them with pbc compute ls. (Formerly --server, still accepted.)
--env <name> Which pbc.json environment to target

Step 3: Redeploy

Using the portal

Build and zip again, then open the frontend and click Deploy — the dialog shows what was dropped as junk and previews the files going up. Every deploy is recorded in the Deployments list on the detail page.

Using the CLI

The first deploy records the frontend in web/pbc.json, so afterwards:

pbc frontend deploy    # rebuild + redeploy the linked site

How the CLI build is configured

The build command and output directory are inferred from your project (Vite, SvelteKit, Angular, Next.js config, or the build script in package.json) and written into pbc.json on the first deploy. Review the guess before anything ships with:

pbc init frontend
// web/pbc.json
{
  "projectId": "dhs4xnprgplurvo",
  "kind": "frontends",
  "defaultEnvironment": "production",
  "environments": {
    "production": { "id": "…", "name": "web" }
  },
  "build": {
    "command": "npm run build",
    "outputDir": "dist"
  }
}

Edit that block whenever the guess is wrong — it is never overwritten. Add exclude globs to drop files from the ZIP. .git, pb_data, .DS_Store, .env, .env.*, *.log, and node_modules are always excluded.

Staging and production from one directory

pbc frontend deploy --name web-staging --env staging  # creates + links
pbc environments                                      # what this dir targets
pbc frontend deploy --env staging                     # from now on, no flags

Each environment is its own frontend in the same project — in the portal they appear as two separate frontends, which is exactly what they are. A pbc.json environment can override the build command:

{
  "environments": {
    "production": { "id": "…", "name": "web" },
    "staging": {
      "id": "…",
      "name": "web-staging",
      "build": { "command": "npm run build:staging" }
    }
  }
}

Your site is live

Provisioning takes under a minute. Your site is then live at an address the platform assigns from the frontend’s id and the compute it runs on:

https://<frontend-id>.<compute>.pocketbasecloud.com

You do not choose it and it never changes. To serve the site from an address people type, add a custom domain.

The exact URL is on the frontend’s page in the portal, and in the terminal:

pbc frontend ls
pbc frontend info --name web

Frontends are static files, so there are no container logs to stream — on either path, a failed page load is a build or routing problem, not a runtime one.

Custom domains

Using the portal

Add and verify a custom domain from the frontend’s detail page.

Using the CLI

pbc frontend domain add app.example.com --name web
pbc frontend domain verify app.example.com --name web
pbc frontend domain remove app.example.com --name web

Single-page app routing

Client-side routers such as React Router and Vue Router handle navigation in the browser. PocketBase Cloud falls back every application route to index.html, so deep links like /dashboard/settings load your SPA and let the client-side router render the correct screen.

Talking to PocketBase from the browser

Your frontend calls the PocketBase instance directly — see Connecting Your App. Both services are served over HTTPS on the same platform, so there are no mixed-content or certificate issues to deal with.

Remember that anything shipped to the browser is public: the instance URL is fine to expose, and per-user data protection belongs in your collection’s API rules, not in frontend code.

Full-stack in one project

A typical production setup on PocketBase Cloud is one project containing:

  • a PocketBase instance — database, auth, files
  • a frontend — your static UI
  • optionally a backend — server-side code for payments, webhooks, or server-rendered pages (Pro plan)

From the CLI it’s one directory per resource, each linked once:

cd db   && pbc pocketbase deploy --name my-app-db
cd ../api && pbc backend deploy --name my-app-api
cd ../web && pbc frontend deploy --name my-app-web

Next steps