Connect with the admin panel
Every instance serves the admin panel at /_/, so if your instance is at https://your-instance.example.com then the panel is at https://your-instance.example.com/_/.
It is PocketBase's own admin panel, unmodified. Sign in with a superuser account and it is where you design collections and their fields, write the API rules that decide who may read and write what, browse and edit records, configure mail and OAuth2 providers, read logs and take backups.
A superuser can do anything to the instance, including deleting all of it. Give the account a real password, keep it to the people who need it, and set up the API rules so your application never needs one.
Beside it
/api/docs is the instance's own API reference: an OpenAPI document generated from the collections you have, scoped to the token it is opened with (nothing signed in, the public API; a user, that user's; a superuser, everything), read through Scalar. The document itself is /api/openapi.json, and /api/mcp serves the same scoping to an agent as a stateless MCP server, with the token as the Authorization header. A superuser can also read /api/plugins: what this instance loaded, where each plugin came from, and where its mail, payments and translations go.
Collections you did not make
Some of the plugins voidbase ships own a collection, and it appears in the panel like any other, with rules you may edit. Which ones you see depends on what the instance has turned on:
| Collection | Who writes it |
|---|---|
translations | The translations plugin, once VOIDBASE_TRANSLATABLE and VOIDBASE_LOCALES are set: one row per collection, record, field and locale, and the records API answers in the locale a request asks for. |
customers, subscriptions, payments | The payments plugin whose key is set (Stripe, Polar or Lemon Squeezy), from its webhooks; created on the first request that carries a provider's key, and scoped by rule to the signed-in user. |
ai_conversations, ai_messages | The ai plugin, for a signed-in user's chats over the instance, so a conversation survives the tab. |
Backups
Settings > Backups is PocketBase's screen over voidbase's archives. An archive taken there is a full one: every table, every file, the settings with their secrets left out, and the schema, with a manifest that names each entry's hash; it is read back and verified after it is written, and a restore replaces everything and restarts the instance. Two other kinds exist through the API and the cloud page: data, the rows and files of the non-system collections for moving content between instances, which a restore lands on the collections the instance has; and schema, the definitions alone. The scheduled backup writes whichever kind VOIDBASE_BACKUP_KIND names, keeps VOIDBASE_BACKUP_KEEP of them, and copies each one to the bucket VOIDBASE_BACKUP_S3_* names, outside the account. A restore refuses an archive written by a newer voidbase, and a PocketBase backup cannot be restored here.
No account yet?
Whoever runs the instance creates it. If that is you, every page under Where to start makes one as part of the setup, and it is a single command either way.
Where to read on
PocketBase's documentation covers the panel screen by screen, and all of it applies here:
- Collections fields, indexes and the three kinds of collection
- API rules and filters the panel's most important screen, and the one to read before going live
- Authentication how users sign in, and how to configure each way
- Going to production what to check before opening an instance to the world
On Cloudflare, mail goes out on port 465 or 587, since 25 is blocked on Workers, or through Cloudflare from your own domain when VOIDBASE_MAIL_DOMAIN is set. The rest of what differs from PocketBase is one short page.
Fix it yourself. The link below opens this file in GitHub's editor and forks the repository for you if you need one, and your change becomes a pull request without leaving the browser.