Self-hosted PDF editor

Self-host a PDF editor without a document server.

Slay PDF builds to static files, so teams can host the open-source editor on their own static hosting while PDF work still runs locally in each browser.

Static deployment

Build once and serve the generated files from GitHub Pages, Netlify, Cloudflare Pages, nginx, Caddy or any static file host.

No document backend

The hosted files load the browser app; everyday PDF imports, page edits, annotations and exports run on the user's device.

Open-source review

The AGPL source, Nix development shell and GitHub Pages workflow make the build and deployment path inspectable.

For teams that need control.

A self-hosted Slay PDF deployment is useful when a school, business, library or internal team wants a private PDF workflow without sending documents to a third-party conversion server.

The app still inherits the limits of the user's browser, device storage, extensions and local security posture. Self-hosting controls where the app files come from; it does not make the user's device invulnerable.

Static hosting workflow.

Clone the source repository, enter the Nix development shell, install dependencies, run the production build and serve the generated static bundle from the hosting platform you already trust.

The live Slay PDF site uses this model on GitHub Pages with no app-server PDF processing endpoint.

Self-hosted PDF editor FAQ

Can Slay PDF be self-hosted?

Yes. Slay PDF builds to static files, so it can be hosted anywhere that serves static HTML, CSS, JavaScript, WebAssembly and image assets.

Does self-hosting upload PDFs to my server?

No. The static host serves the app files. PDF imports and edits run in the user's browser for normal Slay PDF workflows.

Where are the deployment commands?

The README includes Nix-based development, build and deployment commands for reproducing the static bundle.

Open source PDF editor Client-side PDF editor Offline PDF editor Security model