A single Go executable that ships its own auth layer — here's what that means for your attack surface.
You spin up a new side project on a Friday night. By Saturday morning you have a working backend, OAuth logins, and a real-time API — and you have added zero third-party auth services to your threat model. That is not a fantasy; it is what happens when you drop a single PocketBase binary into a VPS and run it.
Setting
PocketBase was built by Gani Georgiev and released as an open-source project written entirely in Go. The premise is almost aggressively simple: one self-contained executable that embeds a SQLite database, a REST and real-time API, an admin dashboard, and a full authentication system. No Docker Compose with five services. No managed auth vendor holding your user table on their infrastructure. Stars have climbed past 57,000 on GitHub, and the last commit landed in April 2026, so this is an actively maintained codebase, not an abandoned experiment.
The security angle here is less about what PocketBase defends against and more about what it removes from the equation entirely.
The Story
Let us be concrete. A typical early-stage backend leans on a hosted auth provider — think Auth0, Clerk, or Firebase Auth. That decision outsources password hashing and token issuance, which sounds safe, but it also means your user identities, email addresses, and session tokens are sitting on infrastructure you do not control, governed by a privacy policy you probably have not read past page two. When that vendor has a breach (and they do), you find out in a press release.
PocketBase keeps the user table local. Passwords are hashed with bcrypt (a deliberately slow hashing algorithm designed to make brute-force attacks expensive — each hash takes measurable CPU time even on modern hardware). JWT tokens (JSON Web Tokens — signed strings that encode session identity without server-side storage) are issued and verified by the same process that owns the database. There is no network hop to an external identity service at login time, which means there is no external service to phish, rate-limit bypass, or misconfigure.
The built-in auth system covers email/password flows, OAuth2 social logins (Google, GitHub, GitLab, and others are pre-wired), and one-time-use email verification links. Collections — PocketBase's name for database tables — carry per-field access rules written in a small expression language. A rule like @request.auth.id = id means a row is readable only by the user it belongs to. You write that once in the admin UI or in code; PocketBase enforces it at the query layer before data ever leaves the database.
Here is a scenario that illustrates the security trade-off clearly. Suppose you are building a small B2B tool where each tenant should see only their own records. With PocketBase you define a company_id field on your collection and set the list rule to @request.auth.company_id = company_id. From that point, even if a client sends a malformed request trying to enumerate other companies' records, PocketBase's rule engine rejects it at the data layer — not in your application code, where it is easy to forget a check. The rule travels with the schema, not with the developer's memory.
For file uploads, PocketBase stores assets locally by default and can be configured to use S3-compatible object storage. Files attached to a private collection inherit that collection's access rules, so a direct URL guess does not bypass row-level visibility.
Admin authentication deserves a mention here. The admin panel is protected separately from the user-facing API. Admin tokens have shorter expiry windows and the panel itself can be restricted to a specific IP range via a reverse proxy in front of PocketBase — a standard hardening step the documentation recommends explicitly.
What PocketBase does not do is worth naming too. There is no built-in secrets manager, no automatic TLS (you are expected to put Caddy or nginx in front of it), no audit log out of the box, and no SOC 2 compliance certification. For a regulated industry — healthcare, fintech — those gaps matter and you would need to layer additional controls. For a startup, a small SaaS, or an internal tool, those gaps are often irrelevant.
The Insight
The real security insight PocketBase offers is not a feature — it is an architecture decision. Every external dependency in a system is a trust boundary. Managed auth services are convenient, but they are also third-party processors of your users' credentials. PocketBase makes the bet that a self-hosted, auditable, single-binary system with a smaller footprint is easier to reason about and harden than a distributed system with multiple vendors. For a senior engineer or a security-minded DevOps team, that is a legitimate trade-off, not a naive one. You own the binary, you own the data, you own the logs. The attack surface is a VPS and a reverse proxy — both of which you already know how to lock down.
If you are evaluating PocketBase for a production system, the practical checklist is short: put it behind a TLS-terminating reverse proxy, restrict the admin path by IP, back up the SQLite file on a schedule, and set your collection rules before you ship. That is a Friday afternoon of work, not a sprint.
PocketBase will not replace Keycloak for an enterprise with 50,000 SSO-federated employees. But for the vast majority of projects where the auth requirement is "users log in, see their stuff, nobody else's" — it handles that correctly, locally, and transparently. That is worth knowing about.
More tools worth a close look are curated at teum.io/stories — security angle included.
한국어 요약
PocketBase는 Go로 작성된 단일 실행 파일 백엔드로, bcrypt 패스워드 해싱과 JWT 기반 인증을 외부 서비스 없이 로컬에서 처리합니다. 컬렉션 단위의 접근 규칙을 데이터 레이어에서 강제하기 때문에 애플리케이션 코드에서 권한 검사를 빠뜨릴 위험이 줄어듭니다. TLS나 감사 로그는 직접 구성해야 하지만, 서드파티 인증 벤더에 사용자 데이터를 위탁하지 않는다는 점에서 공격 표면(attack surface)이 명확히 줄어드는 구조입니다. 규제 산업보다는 스타트업·내부 툴·소규모 SaaS에 실용적인 선택지입니다.
Every external dependency is a trust boundary. PocketBase bets that a single self-hosted binary is easier to harden than a distributed system with multiple vendors.