The server
@cloudpdf/server is the backend that powers CloudPDF. It runs native PDFium on
your own infrastructure and exposes it as a clean, document-scoped HTTP API:
open a document, render pages, extract text, read and write annotations, inspect
metadata, and enforce access — all behind short-lived JWTs.
It is the same engine that runs locally in the browser with EmbedPDF, lifted
onto the server. Your frontend keeps talking to one Engine
interface; the server does the heavy PDF work, holds your
documents, and never hands storage credentials to the client.
In a hurry? The Quick start
gets a server answering requests in about a minute with a single
docker run.
Why run your own server#
- Your data stays yours. Documents live in your database and object store — SQLite and the local disk to start, Postgres and S3/GCS/Azure when you grow.
- Real PDF rendering. Native PDFium renders pages to PNG/WebP and extracts text and geometry — the same fidelity as the desktop, on the server.
- Secure by construction. Every document route requires a short-lived, document-scoped JWT minted by your backend. The browser never sees your tenant secret or storage keys.
- Runs anywhere. A single Node process, a Docker container, or a Kubernetes deployment that scales from a side project to enterprise traffic.
Three ways to run it#
The server is a single, self-contained application. Pick the packaging that fits your team — they all run the exact same binary and read the exact same configuration.
Don’t want to host anything? CloudPDF Cloud runs this same server for you as a managed SaaS. The API is identical, so you can start on the cloud and move to self-hosted later — or the other way around — without changing a line of frontend code. See plans and start a free trial.