How to contribute

voidbase is in public beta and is built in the open. The API is PocketBase's and is not moving; everything around it is 0.x and is. If you know backends, or Cloudflare, or just found a page here that is wrong, there is something useful you can do in the next ten minutes. If you would rather talk to someone first, we are on Discord.

The smallest thing first

Every page in these docs has an Improve this page card at the bottom. It opens that page's source file in GitHub's editor, forks the repository for you if you do not have one, and turns your change into a pull request without you leaving the browser. Typos, a command that does not work, a paragraph that assumes something you did not have: all of that is welcome and none of it needs a discussion first.

What would help most

Benchmarks, honestly run

The comparison pages carry performance numbers that we label as guesses, because that is what they are. We are not qualified to benchmark a database engine and we would rather say so than publish a number we cannot defend. If you have done this work before, a methodology is worth more to us than a result, and a single honestly-run figure against one competitor is worth more than either. Start a discussion before you spend a weekend on it, so we can agree what is being measured.

Cloudflare, from production

D1's limits, Durable Object placement, how Workers CPU time is actually accounted, R2 lifecycle behaviour. Several of our design decisions rest on assumptions we have not been able to test at the scale where they would break. If you have run this in anger and we are wrong somewhere, that is the most valuable thing you can tell us.

Where we do not match PocketBase

Compatibility is the whole premise, so a case where we diverge and have not written it down is a real bug. The differences page is what we know about. A failing test that proves something is missing from it is a good report, and a better pull request.

Something on the roadmap

Every item has a design and a rough size against it. Say which one you are taking in an issue before you start, because some of them are larger than they look and a few depend on each other.

Working on voidbase

git clone https://github.com/voidbase-cloud/voidbase.git
cd voidbase
bun install          # also installs the git hooks
bun run check        # codegen and three typecheck passes
bun test             # the unit tests, about a second

bun run dev starts the dev server, and bun run ci runs the suite the way CI does, working out which parts your change affects rather than running all of it. Commits follow Conventional Commits, which the git hooks and CI both enforce, because every commit message is a release note in waiting. The full guide is CONTRIBUTING.md.

Working on this site

git clone https://github.com/voidbase-cloud/voidbase-site.git
cd voidbase-site
bun install
bun run dev          # the site at http://127.0.0.1:5173

The site and these documentation pages are a separate repository, voidbase-cloud/voidbase-site. Every page is one file under pages/, so the URL tells you where it lives: /docs/run/npm is pages/docs/run/npm.tsx. Its contributing guide covers the rest, including how the pages are written.

Where to talk

• Discord if you want an answer the same day, or you are part way through something and stuck. It is the fastest of these and the least formal.
• Discussions for questions, ideas, and anything you are not sure is a bug yet. Slower than Discord and easier for the next person to find, which is why proposals belong here rather than in a chat scroll.
• Issues for bugs, with the version from voidbase version, how you are running it, and the smallest thing that reproduces it.
• Security problems go through GitHub's private vulnerability reporting on the repository, never a public issue.

One last thing worth saying plainly: this is a beta and we would rather hear that something is wrong than find out later that people worked around it quietly.