One Binary, One File, One Backend — How PocketBase Handles Auth

A security-first look at what 57,000+ stars quietly got right about authentication infrastructure You spin up a side project on a Friday night. By Saturday morning, you've already written user registration, password hashing, JWT issuance, and an admin panel from scratch — and you haven't touched your actual idea yet. This is the tax every backend developer pays, and it compounds fast when security is non-negotiable. Setting PocketBase started as a single-developer experiment: ship an entire backend as one self-contained binary, written in Go, that you can drop onto a server and run immediately. No Postgres to provision, no Redis sidecar, no reverse-proxy maze. The project has grown to nearly 58,000 GitHub stars without a corporate sponsor, which says something about how many developers are exhausted by the ceremony of standing up a secure backend from scratch. The homepage is at github.com/pocketbase/pocketbase, and the single executable bundles SQLite, a REST and realtime API, file storage, and — critically for this column — a full authentication system. The Go language choice matters here. Go's standard library has strong primitives for cryptography, and the compiled single-binary model means there is no dynamic dependency chain that an attacker can tamper with at deploy time. What ships is what runs. The Story Here is a concrete scenario. You are building an internal tool for a 20-person startup: engineers need accounts, OAuth login via Google, and role-based access so that only admins can delete records. With PocketBase, this is the entire backend setup: ./pocketbase serve That command starts a process that listens on port 8090, exposes a REST API, opens a WebSocket endpoint for realtime subscriptions, and renders an admin dashboard at /_/. Inside that dashboard you enable Google OAuth in two form fields, define a "users" collection with an "admin" boolean field, and write one rule — @request.auth.admin = true — on the delete endpoint. No additional code. No separate auth service. Under the hood, PocketBase handles password storage using bcrypt (an adaptive hashing algorithm that deliberately slows brute-force attacks by increasing computational cost over time). JWT tokens (JSON Web Tokens — signed strings that carry identity claims without a server-side session) are issued on login and validated on every subsequent request. The admin dashboard itself is served over a separate port path and requires its own superuser credential, giving you a basic separation between the user-facing API surface and the management plane. For OAuth2 flows — where a third-party provider like Google or GitHub asserts identity — PocketBase handles the PKCE exchange (Proof Key for Code Exchange, a security extension that prevents authorization code interception) automatically. You configure a client ID and secret in the admin UI; the library manages the state parameter, the token exchange, and the identity mapping into your local users collection. File uploads, which are a classic source of path traversal and content-type injection vulnerabilities, are handled through a storage abstraction. Files are stored with randomized names rather than user-supplied filenames, which eliminates a common class of server-side injection. Access rules on collections propagate to file endpoints, so a private record's attachments inherit the same visibility logic. There is one meaningful limitation worth naming directly: PocketBase uses SQLite as its database. SQLite is battle-tested for read-heavy workloads, but it is a single-writer engine. Under high concurrent write load it will serialize writes and you will see latency. For a team tool, a staging environment, or a startup product under a few thousand daily active users, this is not a bottleneck. For a write-heavy SaaS at scale, it is a genuine architectural constraint you should evaluate before committing. The Insight The security argument for PocketBase is not that it is hardened beyond scrutiny — no single project can claim that. The argument is that it collapses the attack surface that comes from stitching together five separate services. Every integration boundary is a potential misconfiguration: the wrong CORS header on your auth service, a JWT library with a none-algorithm vulnerability, an S3 bucket with public-read accidentally enabled. PocketBase reduces those boundaries to one process you can audit, update, and replace with a single binary swap. For a security engineer reviewing a small team's infrastructure, "one thing to patch" is a meaningful property. Who should use it: solo developers and small teams building internal tools, prototypes, or early-stage products where moving fast and staying secure are the same goal. Enterprise teams with compliance requirements (SOC 2, HIPAA) that mandate specific database backends or audit logging at the infrastructure layer should evaluate whether SQLite's constraints and PocketBase's current audit trail features meet their controls before adopting it in production. PocketBase will not replace a hardened enterprise identity provider. But for the enormous middle ground of projects that do not need one yet, it is a credible, auditable starting point — and that is a more honest pitch than most backend frameworks offer. If you want to go deeper on the codebase, the Go source is readable and well-structured. The authentication package is a good first read for understanding how the JWT lifecycle and bcrypt rounds are implemented. Spend a weekend with it and you will come away with a clearer mental model of what "secure by default" actually looks like in practice — not as a marketing phrase, but as a set of concrete implementation choices. More security tool deep-dives like this one are on teum.io/stories. 한국어 요약 PocketBase는 Go로 작성된 단일 실행 파일 형태의 오픈소스 백엔드입니다. bcrypt 기반 비밀번호 해싱, JWT 인증, OAuth2/PKCE 처리, 파일 업로드 보안을 별도 서비스 없이 한 바이너리 안에서 처리합니다. 작은 팀이나 초기 스타트업이 인증 인프라를 빠르고 안전하게 구축하는 데 실용적인 선택지입니다. 다만 SQLite 단일 라이터 제약은 고트래픽 환경에서 병목이 될 수 있으니, 사전 평가가 필요합니다. For a security engineer reviewing a small team's infrastructure, 'one thing to patch' is a meaningful property.