Papermark: a self-hosted DocSend alternative for document sharing and data rooms

What Papermark replaces, and for whom

Papermark describes itself as "the open-source document-sharing alternative to DocSend, featuring built-in analytics and custom domains." The problem it targets is narrow and real: you have a PDF or a set of documents you need to send to someone outside your organisation, you want to know whether they opened it and how far they got, and you want the link to carry your own domain rather than a third party's. DocSend does that as a hosted service. Papermark does it as a Next.js application you deploy yourself.

The audience follows from that. It suits teams that already run their own infrastructure and treat document links as something worth owning, for example a fund sharing a data room with limited partners, or an agency that sends proposals under a client-facing domain. It does not suit someone who wants a link in five minutes with no accounts to create. The README's prerequisites list PostgreSQL, blob storage (AWS S3 or Vercel Blob), and Resend for email before the app will start, and the environment file adds Tinybird, Upstash QStash, Hanko and Vercel custom-domain credentials on top. That is the real entry price, and it is worth knowing before cloning anything.

How Papermark is put together: Next.js, Prisma and an analytics pipeline

The repository is a single Next.js application in TypeScript, with Prisma as the ORM over PostgreSQL and NextAuth.js for authentication. Tailwind and shadcn/ui cover the interface. The README's tech stack section names each of these, and the top-level layout matches: app/ and pages/ for routes, components/ for UI, prisma/ for the schema and migrations, lib/ for shared code, and ee/ for what appears to be an enterprise-licensed area.

Analytics do not live in PostgreSQL. The stack lists Tinybird as the analytics store, and the README gives a separate set of instructions for preparing it: data sources are pushed with tb push datasources/*, and query endpoints with tb push endpoints/get_*. Events flow out of the app into Tinybird, and the app reads them back through those endpoints. The zod-bird dependency in package.json is the typed client for that arrangement, which means the endpoint definitions and the TypeScript types are meant to stay in sync rather than being hand-written.

Background work is split off as well. The environment file marks Upstash QStash as "required for queues and background jobs," and package.json carries trigger:v4:dev and trigger:v4:deploy scripts for Trigger.dev v4. Stripe handles payments, with a stripe:webhook script that forwards to localhost:3000/api/stripe/webhook. File delivery goes through either Vercel Blob or S3, selected by NEXT_PUBLIC_UPLOAD_TRANSPORT, with a separate distribution host setting for CloudFront, S3 or the blob host. The practical consequence is that a Papermark deployment is a small constellation of services, and the analytics and queue paths are the parts most likely to fail quietly if a token is missing.

Installing Papermark locally and sharing a first document

The README gives a six-step local setup. Node.js 18.17.0 or newer is listed as a prerequisite there, but package.json sets engines.node to >=24, so treat 24 as the real floor when you build. Start by cloning and installing:

git clone https://github.com/mfts/papermark.git
cd papermark
npm install

The install runs a postinstall step that generates the Prisma client, so it expects the Prisma schema to be present and valid. Next, copy the environment template and fill it in. The values below are the ones the app needs before it will boot; the file itself ships empty placeholders for most of them.

cp .env.example .env

At minimum you need NEXTAUTH_SECRET and NEXTAUTH_URL, the PostgreSQL URLs (POSTGRES_PRISMA_URL and POSTGRES_PRISMA_URL_NON_POOLING), a blob credential (BLOB_READ_WRITE_TOKEN for Vercel Blob, or the S3 settings), GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET for sign-in, and RESEND_API_KEY for email. QSTASH_TOKEN, QSTASH_CURRENT_SIGNING_KEY and QSTASH_NEXT_SIGNING_KEY are marked required for queues and background jobs. TINYBIRD_TOKEN is needed for event data.

Then initialise the database and start the dev server:

npm run dev:prisma
npm run dev

The first command runs prisma generate followed by prisma migrate deploy, which applies the migrations in prisma/ to your database. The second starts Next.js. Open http://localhost:3000 and you should get the application, with sign-in through the Google client you configured. Upload a document, create a share link, and open that link in a private window to see the viewer. If the upload succeeds but analytics stay empty, the Tinybird token or the pushed endpoints are the first thing to check, because the app writes events to Tinybird rather than to PostgreSQL.

The managed services Papermark does not replace

The most common misreading of an open-source DocSend alternative is that self-hosting means independence. Papermark's self-hosting story is real, but it is independence at the application layer, not the infrastructure layer. The README's prerequisites name blob storage and Resend as things you must bring. The environment file adds Tinybird for analytics, Upstash QStash for queues, Hanko for passkey signup, and Vercel project and team IDs plus an auth bearer token for custom domains.

Custom domains are the sharpest example. The feature is advertised in the README's feature list, and the variables that make it work are PROJECT_ID_VERCEL, TEAM_ID_VERCEL and AUTH_BEARER_TOKEN, described as coming from Vercel. If you are not on Vercel, the custom domain path is not obviously available to you, and the README does not describe an alternative. That is a genuine constraint rather than a footnote, because custom branding is one of the two things the project leads with.

The second limitation is analytics depth. The README lists "Analytics: Gain insights through document tracking and soon page-by-page analytics." Document-level tracking exists; page-by-page is described as coming. If your evaluation of DocSend rested on knowing which page a reader stopped at, Papermark's README does not currently promise that. There is also no documented rollback or downgrade procedure in the README, and no documented migration path between releases beyond the prisma migrate deploy step that runs on every build.

Papermark compared with DocSend and with a plain signed URL

The comparison the project invites is with DocSend, and the difference is where the data and the logic live. DocSend is a hosted product: you upload, you get a link, you pay per seat or per plan, and the vendor operates the analytics pipeline. Papermark inverts that. You operate PostgreSQL, blob storage, the event pipeline and the queue, and in exchange you can read and modify the code, run it on your own domain, and keep documents in storage you control. The cost moves from a subscription to operational work, and the work is not trivial: the Tinybird setup alone involves installing a CLI, authenticating it, and pushing data sources and endpoints from lib/tinybird.

Against a plain signed URL from S3 or CloudFront, the difference is what you get back. A presigned URL tells you nothing about whether the document was read. Papermark adds the viewer, the link management and the event tracking on top of storage, which is the part worth paying for in either model. If you only need to hand someone a file and you do not care about engagement data, a signed URL is less machinery for the same outcome, and Papermark is the wrong tool.

There is also a licensing dimension that separates Papermark from permissively licensed alternatives. The README's badge and the repository both point to AGPLv3, while the repository metadata reports the licence as NOASSERTION, which usually means GitHub could not map the LICENSE file to a known identifier. The two do not contradict each other so much as leave the exact terms to the file itself, and the repository also carries a CLA.md and an ee/ directory, which suggests some parts sit outside the main open-source grant. Read LICENSE and ee/ before you plan a commercial deployment.

Maintenance, releases and what an upgrade actually involves

The last push to the default branch was on 2026-08-28, and the repository is not archived. Releases are infrequent and chunky rather than continuous: v0.20.0 on 2025-04-30, v0.21.0 on 2025-08-20, and v0.22.0 on 2025-12-06. If you track main, you are tracking a branch that moves more often than the tags do, and the project's own vercel-build script runs prisma migrate deploy before next build, which tells you migrations are expected to be applied forward on every deploy.

That forward-only migration model is the upgrade cost to plan for. There is no documented down migration in the README, and no documented rollback. The practical approach is to snapshot the PostgreSQL database before applying a release, because the schema changes arrive as part of the deploy rather than as a separate, reversible step. The Tinybird side has its own update path, documented as a pipenv update tinybird-cli inside lib/tinybird, and the data sources and endpoints are pushed manually, so an upgrade can require re-running tb push as well as redeploying the app.

On the licence side, nothing here is legal advice, but the shape of the obligation matters. If the LICENSE file is AGPLv3 as the README badge indicates, running a modified Papermark as a network service carries source-availability obligations that a permissive licence would not impose. The presence of ee/ and CLA.md means the boundary between the open-source core and the enterprise portion is worth confirming with whoever owns the decision, before the deployment is public rather than after.

Editorial conclusion

Adopt Papermark if you want document sharing and data room features on infrastructure you control, and you are willing to run PostgreSQL, S3 or Vercel Blob, Resend, Tinybird and QStash alongside it. Do not adopt it if you expect a single container with no external accounts, or if page-by-page analytics are already a hard requirement: the README lists that as coming soon. Verify your licence obligations against the LICENSE file in the repository before you deploy, and confirm that Node.js 24 or newer is available on your build host, since package.json sets that as the engine floor.

Frequently asked questions

Official sources

1. Issues
2. papermark/papermark on GitHub
3. Project website
4. README
5. Releases