When is PocketBase a fit for your app?
Suppose you’re building a lending app for a small club. Members need accounts, a list of the gear they’ve borrowed and a place to attach a photo. PocketBase gives you those backend pieces in a program you can try on your computer. For the club to use it, someone has to keep that program running and look after the data.
Your app provides the member screens. PocketBase gives the administrator a separate dashboard to see and manage records. It uses SQLite to keep records in its database. PocketBase groups related records in collections, such as one collection for loans.
Who will keep the club’s app running?
PocketBase does not offer its own hosting. To let members use the app when your laptop is shut, you need a server, a computer that can keep the shared service online. Decide who will manage that server and answer if the app goes down.
The project is maintained by volunteers and makes no promise of future support. PocketBase also cautions against relying on it for critical production apps before version 1.0 unless you can follow release notes and handle occasional manual updates to the app or its data. Ask who would rehearse one of those changes and do the recovery work if it goes wrong.
How do you make the first loan show up?
Start on your computer with an invented loan. Set up the first save as a regular club member so it tests the same permissions your members will use.
- Download the program for your computer and follow its instructions for starting it. You’ll use a terminal, the app where you type commands.
- Open the dashboard and create the administrator, called a superuser. Add a collection for loans with fields such as the gear, the borrower and the return date.
- Create an ordinary member account. Set rules that allow it to create a loan with itself as the borrower and open its own records. Keep the superuser’s credentials out of anything the browser receives.
- Connect one screen through PocketBase’s API, the interface for requesting or saving records. Sign in as the member, save a loan and check that you can open it after a refresh.
Can another member open a private loan or photo?
Set the rules for each action, such as reading a loan or changing its return date. In PocketBase an empty rule allows anyone to perform the action. A locked rule allows only a superuser, whose requests bypass the ordinary rules.
Uploads need their own check. PocketBase files are public to anyone with the full address by default. Mark a sensitive file field protected and set the collection’s View rule to check the signed-in member. To request the protected photo under that rule, your app needs a short-lived file token for the signed-in account.
| Try this in the app | What to expect |
|---|---|
| A member opens their own test loan | The loan appears. |
| Another member requests or edits the same loan | They cannot read it or change the saved return date. |
| The second member requests that protected photo through the app using their own sign-in | They cannot open the image. |
Would a backup bring back the loan and its photo?
PocketBase’s built-in backup copies its data folder, including uploads saved on the same computer. If you keep the images in a separate file service, arrange a recovery copy there too.
If you copy the data folder by hand, stop PocketBase first as the deployment guide directs. Protect the backups. The database can include private settings and service credentials.
Try a recovery with invented loans. Start a separate test installation and confirm the right member can open both the recovered loan and the original photo before you rely on that backup.
What does it cost to keep PocketBase online?
Price the computer you will run it on and the work of maintaining it. PocketBase is open-source software. Your host, backups and email delivery have their own costs.
| Item | What to ask for |
|---|---|
| Computer and storage | What it costs to leave the server running, keep data through a restart and send files to members. |
| Recovery copies | What it costs to retain backups separately from the running app, including any external uploads. |
| Email and upkeep | How account messages will reach members, and who will spend time checking and applying updates. |
What should you take with you if you move the server?
The records and local files live in the data folder. Bring the app’s settings, custom code and any externally stored photos too. On the replacement server, sign in as an ordinary member and check that an existing loan and its image still open.
PocketBase keeps scripts that change the collection structure in a separate folder, called pb_migrations. Keep those scripts with your project when you use them. They describe changes such as adding a return-date field. For a software update, read the version’s release notes and try it with a copy of the data first.
When would the club need extra code?
The ordinary record features cover saving a loan or marking it returned. A rule that checks whether a piece of gear is already out before accepting another request may need additional app behavior.
PocketBase lets you extend the program with Go or JavaScript. If you choose that route, someone needs to write, test and maintain the extra code as part of the installation.