How to Self-Host Papermark in 2026

Papermark has quietly become the default open source answer to DocSend. It hit 8.1K+ stars on GitHub, ships under AGPL-3.0, and is still actively pushed to main as of today. If you send pitch decks, investor updates, or sales collateral and want control over links, analytics, and retention, self-hosting Papermark is the most defensible path.

This guide walks through a realistic production setup, plus the gotchas you hit once real recipients start opening your documents.

Why Papermark is worth self-hosting

Papermark handles the core DocSend workflow: upload a PDF or deck, generate a secure link, require email capture, watermark downloads, and track page-by-page viewing. Running it yourself gives you:

• Full ownership of who viewed what, without a SaaS vendor holding the analytics.
• Custom domains for every link (useful for deal rooms and due diligence).
• Predictable cost: one small server plus object storage, regardless of view volume.
• Compliance-friendly deployment inside your VPC if that matters to legal.

The trade-off is the usual AGPL reality: if you wrap Papermark inside a hosted product you resell, read the license carefully.

Who should and should not self-host it

Self-hosting fits well if you have:

• A VC, legal, sales, or finance team that sends confidential documents weekly.
• An internal ops person who is comfortable with Docker and Postgres basics.
• A reason to keep analytics out of a third-party SaaS.

Skip it if you only send a handful of decks a year, or if your team has no one who can handle a failed migration at 9pm. Papermark's hosted plan is reasonable for light users.

Architecture and required services

Papermark is a Next.js app backed by:

• PostgreSQL via Prisma for metadata, views, and links.
• Object storage (S3-compatible) for documents and rendered previews.
• A background worker for PDF processing and thumbnail generation.
• Optional Redis if you enable queued jobs or rate limiting at scale.

A single small VPS (2 vCPU, 4GB RAM) is enough for most teams. For storage, use S3, Cloudflare R2, Backblaze B2, or self-hosted MinIO.

Docker Compose example

A minimal production-shaped Compose stack looks like this:

services:
  papermark:
    image: ghcr.io/mfts/papermark:latest
    env_file: .env.papermark
    ports:
      - "3000:3000"
    depends_on:
      - postgres
    restart: unless-stopped

  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: papermark
      POSTGRES_PASSWORD: changeme
      POSTGRES_DB: papermark
    volumes:
      - pg-data:/var/lib/postgresql/data
    restart: unless-stopped

volumes:
  pg-data:

Put this behind a reverse proxy (Caddy or Traefik) and terminate TLS there.

Environment variables and storage options

The variables that matter most in production:

• DATABASE_URL pointing at your Postgres instance.
• NEXTAUTH_SECRET and NEXTAUTH_URL for auth.
• NEXT_PUBLIC_BASE_URL matching your public domain.
• STORAGE_* or the S3-compatible keys (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_S3_BUCKET, custom endpoint for R2/MinIO).
• Email provider keys (Resend, Postmark, or SMTP) for link notifications and magic-link login.

Rule of thumb: never use local disk for documents in production. Switch to S3/R2 from day one so your container is stateless and rebuilds are safe.

Reverse proxy and custom domain setup

Put Papermark behind Caddy or Traefik so you get automatic TLS. Two domains are typical:

• app.yourcompany.com for the Papermark dashboard.
• docs.yourcompany.com (or a client-facing domain) for the viewer links.

Make sure NEXT_PUBLIC_BASE_URL matches the viewer domain, otherwise tracking pixels and webhooks can end up pointed at the wrong host.

Operations: backups, analytics, upgrades

A few rules that save pain later:

• Backups: snapshot Postgres daily (pg_dump to S3) and version your object storage bucket. Analytics lives in Postgres, documents live in storage; you need both.
• Analytics caveats: view tracking depends on recipients loading tracking pixels and JavaScript. Hardened email clients and corporate proxies can suppress events, so treat the numbers as directional, not forensic.
• Upgrades: pin image tags, read release notes for Prisma migrations, and always back up before docker compose pull.
• Secrets: rotate NEXTAUTH_SECRET only when you're ready to invalidate sessions.

For the broader operational baseline, pair this with the self-hosting security checklist and the self-hosting backup guide.

Common issues and final recommendation

The problems that show up most often:

• PDFs upload but previews fail: usually a storage permissions or CORS issue on the bucket.
• Magic link emails never arrive: SPF/DKIM not configured on your sending domain.
• View events look inflated: preview bots and link scanners hit the viewer before the recipient. Filter by unique viewer or confirmed email when reporting.
• Slow deck loads: enable a CDN in front of the storage bucket.

Pre-launch decision checklist

Before the first investor or buyer clicks one of your links, verify each item:

• Storage is S3/R2/MinIO, never local disk. Containers get rebuilt, hosts get replaced, and decks must survive both. Move to object storage on day one.
• Bucket CORS lets the viewer domain fetch documents. This is the #1 reason "previews fail but uploads succeeded" — fix it before sending the first link, not after.
• NEXT_PUBLIC_BASE_URL matches the public viewer domain. Mismatched values make tracking pixels resolve to the wrong host and silently break analytics.
• Magic-link email is deliverable. Send a test login to a Gmail and a corporate inbox. If either lands in spam, your SPF/DKIM/DMARC for the sending domain isn't right.
• Postgres backups are off-box and restore-tested. Document metadata, view events, and link configs all live in Postgres; losing it loses your audit trail.
• Object storage versioning is on. Versioned buckets let you recover from accidental overwrite and ransomware events; the cost is trivial for deck-sized files.
• A throwaway test link has been opened from an outside browser. Verify the viewer renders, page-by-page tracking fires, and the watermark shows the expected email.

Common mistakes to avoid

• Treating analytics as forensic evidence. View counts are inflated by link scanners (Microsoft Defender, Slack unfurl bots, Gmail preview). Always filter by confirmed email and unique viewer when reporting numbers to a deal team.
• Sending decks without email gating during sensitive deals. Link sharing happens. Require email capture and watermarks for anything you wouldn't want forwarded.
• Pointing a CDN at the dashboard subdomain. The dashboard is dynamic and authenticated; caching it breaks logins. Put the CDN in front of the viewer/storage path, not the app.
• Skipping a staging container before Prisma upgrades. Migrations are usually clean, but the cost of a failed migration on the database that holds your deal analytics is much higher than the cost of a staging soak.
• Reusing NEXTAUTH_SECRET across environments. A leaked staging secret is a production session forgery primitive. Generate per-environment.

If you send confidential documents regularly and can commit to basic Postgres hygiene, Papermark is the cleanest open source DocSend replacement you can run today. Start with a small VPS, S3-compatible storage, and one custom domain, then harden from there. For alternatives if Papermark doesn't fit, see our open source DocSend alternatives roundup.

Production Checklist

Before treating Papermark as a DocSend replacement, verify the boring pieces that make shared documents trustworthy. Put uploads on durable object storage, back Postgres up on a schedule, and test link expiration, password protection, and analytics retention with a real sales or fundraising deck. If you send documents externally, configure the public hostname, email domain, and TLS certificates before inviting teammates.

Papermark is strongest when you want control over data and branding. It is less attractive if your team depends on enterprise controls, polished CRM workflows, or managed support. Start with one non-critical document workflow, compare viewer analytics against your current tool, then migrate the high-stakes rooms only after the operational path is proven.

Search Intent Refresh: Papermark Production Hardening

Self-hosting Papermark is attractive when document privacy, cost control, or data ownership matters more than buying a hosted sales-document platform. The production risk is not the first Docker boot; it is storage, email delivery, analytics accuracy, access controls, and backups after real users rely on document links.

Hardening checklist:

• Use managed Postgres or a backup-tested Postgres deployment.
• Store uploaded documents in durable object storage rather than local disk.
• Configure transactional email and test link-sharing flows end to end.
• Put the app behind HTTPS with secure cookies and strict environment separation.
• Test document access revocation, password protection, and link analytics before launch.
• Schedule restore drills so document metadata and uploaded files can be recovered together.