PrivateBin Reverse Proxy Setup Guide: Nginx, Caddy, and Traefik Security Basics

Overview

A reverse proxy sits in front of PrivateBin and handles the public-facing web concerns that you usually do not want your application container or PHP runtime to manage directly. In practice, that means TLS termination, request routing, security headers, request size limits, logging controls, and sometimes rate limiting or access restrictions.

For a small self-hosted deployment, the proxy choice often comes down to operating style:

• Nginx is a good fit when you want explicit control and are comfortable editing server blocks by hand.
• Caddy is a good fit when you want simpler HTTPS automation and a smaller config surface for common cases.
• Traefik is a good fit when you are already using Docker labels, dynamic service discovery, or a container-heavy environment.

Whichever proxy you choose, the security goals stay mostly the same:

• Serve PrivateBin only over HTTPS.
• Expose only the hostname and paths you intend to publish.
• Pass the correct forwarded headers so the app sees the original scheme and client context.
• Set sensible request limits to reduce abuse and accidental oversized pastes.
• Avoid caching sensitive content in the wrong place.
• Add baseline security headers without breaking PrivateBin’s front-end behavior.
• Keep logs, error pages, and upstream configuration from leaking more than necessary.

If you are still planning the base deployment, pair this guide with PrivateBin Docker Deployment Guide: Secure Configuration, Persistence, and Updates and How to Self-Host PrivateBin Securely: Hardening Checklist for Admins. If your use case includes temporary sharing of sensitive snippets, it is also worth reviewing PrivateBin Data Retention Settings Explained: Expiration, Burn After Reading, and Risk Tradeoffs.

Before you touch proxy configuration, confirm these assumptions:

• You already have a working PrivateBin instance reachable on an internal port or internal container network.
• You have a dedicated hostname such as paste.example.com.
• You know whether TLS is terminated at the proxy, at a load balancer upstream, or both.
• You have decided whether the service is public, internal-only, or protected behind an identity layer.

Checklist by scenario

Use the checklist that matches your environment. The point is not to copy a giant config blindly, but to verify the same control points in each stack.

Nginx checklist for PrivateBin

Use this if you want a traditional, explicit reverse proxy layout.

1. Create a dedicated server block for the PrivateBin hostname.
   Avoid combining unrelated apps in one broad default config if you can help it. A dedicated host makes headers, limits, and logs easier to reason about.
2. Redirect HTTP to HTTPS.
   Keep the plain HTTP listener only for redirect or certificate challenge handling. Do not leave the app accessible over both schemes.
3. Proxy only to the intended upstream.
   Point proxy_pass to the internal PrivateBin service name or loopback address, not a wide subnet target. Keep the upstream private.
4. Pass forwarded headers correctly.
   At minimum, preserve host and scheme so the application generates the right URLs and treats requests as secure. Typical headers include Host, X-Forwarded-Proto, X-Forwarded-For, and optionally X-Real-IP.
5. Set a request body size that matches your use case.
   PrivateBin handles text, but users may still paste large payloads. Set client_max_body_size intentionally. Too low causes confusing failures; too high increases abuse potential.
6. Disable or limit proxy buffering if it causes issues.
   In many cases the default is fine, but if you see odd behavior with request handling or large payloads, review buffering rather than assuming the app is at fault.
7. Send security headers from the proxy.
   Common candidates include X-Content-Type-Options, Referrer-Policy, and a conservative Permissions-Policy. For Content-Security-Policy, test carefully because overly strict rules can break front-end behavior.
8. Think carefully about HSTS.
   If the hostname should always be HTTPS and you are confident in the domain setup, HSTS can reduce downgrade risk. If you are still testing subdomains or certificate workflows, roll it out deliberately rather than by habit.
9. Review cache behavior.
   Do not let a shared proxy cache store sensitive responses unintentionally. If you use additional caching layers, verify that paste content is not cached where it should not be.
10. Limit noisy logs where appropriate.
    Access logs can be useful for abuse analysis, but they also create additional metadata. Decide how much to log, how long to retain it, and whether query strings or full paths need special treatment.
11. Test upload, create, read, and delete paths.
    Do not stop at a homepage check. Create a paste, open it in a fresh session, verify burn-after-reading if used, and confirm no mixed-content or redirect problems appear.

Caddy checklist for PrivateBin

Use this if you want simpler configuration and built-in HTTPS automation for common deployments.

1. Define a dedicated site block for the PrivateBin hostname.
   Keep the config narrow and readable. With Caddy, a small config is often easier to audit later.
2. Confirm automatic HTTPS assumptions.
   Caddy makes certificate handling easier, but you still need working DNS, correct ports, and a clear decision about whether another proxy or CDN sits in front.
3. Reverse proxy only to the internal PrivateBin service.
   Use the internal container name or local address and keep the app off the public network path where possible.
4. Preserve the original host and scheme context.
   Caddy generally handles common forwarded headers well, but verify the behavior in your environment, especially if another proxy sits upstream.
5. Add response headers intentionally.
   Use Caddy’s header directives to set a baseline security posture. As with any stack, be careful with CSP and test every interactive function after changes.
6. Set request limits if needed.
   If your deployment is public, think about body size controls and simple abuse resistance rather than accepting platform defaults without review.
7. Decide how much logging you really need.
   Caddy can log usefully, but a privacy-minded paste service should avoid collecting more metadata than necessary.
8. Check compression and encoding behavior.
   Compression is usually fine for static assets, but review whether your broader environment applies transformations in places you do not expect.
9. Verify path handling stays simple.
   PrivateBin is easiest to operate on its own hostname. Running it under a subpath can work in some environments, but it adds avoidable complexity around asset paths, redirects, and headers.

Traefik checklist for PrivateBin

Use this if you are publishing PrivateBin from Docker or another orchestrated environment with label-based routing.

1. Attach PrivateBin to the correct internal network.
   Do not publish the app container port directly if Traefik is meant to be the public entrypoint. Let Traefik be the only public listener.
2. Create a router for the exact hostname.
   Avoid catch-all rules that may route unintended traffic to the service. Match the domain explicitly.
3. Bind the router to a TLS-enabled entrypoint.
   Make the HTTPS path the default public route and keep plain HTTP limited to redirects or challenge handling.
4. Use the correct service port label.
   A common Traefik mistake is routing to the wrong internal port or assuming the container exposes the expected one automatically.
5. Add middleware deliberately.
   Traefik makes it easy to stack redirects, headers, basic rate controls, and IP filtering. That is useful, but keep the middleware set comprehensible so future admins can audit it.
6. Review forwarded headers in multi-proxy setups.
   If Traefik sits behind a cloud load balancer or CDN, be clear about which proxy is trusted to provide client IP information.
7. Check certificate resolver behavior.
   If you use automatic certificate management, confirm storage permissions, renewal paths, and whether a restart or redeploy affects persistence.
8. Make dashboard exposure a separate decision.
   If Traefik’s admin dashboard is enabled, do not leave it broadly accessible just because the app route works.
9. Test labels after every compose change.
   Dynamic config is convenient, but small label errors can silently disable TLS, headers, or routing protections.

Checklist for PrivateBin behind an identity or internal access layer

Some teams do not want a fully public paste service. In that case:

• Decide whether users should authenticate before reaching PrivateBin at all.
• Verify that auth middleware does not break share links or expected paste retrieval workflows.
• Document whether external recipients can access links, because this is often where operational confusion begins.
• If you restrict by IP or VPN, test from both expected and unexpected networks before you call the deployment complete.

For teams evaluating whether a paste tool is the right fit at all, see PrivateBin vs Send, Wormhole, and File-Sharing Tools: When a Paste Service Is the Better Choice and PrivateBin vs Pastebin vs GitHub Gist: Which Is Safer for Sharing Sensitive Snippets?.

What to double-check

These are the settings most likely to look correct at first glance and still cause trouble later.

• Scheme awareness: If PrivateBin thinks traffic is HTTP while users connect over HTTPS, you may see wrong redirects, incorrect generated URLs, or cookies and headers behaving differently than expected.
• Hostname fidelity: Preserve the original host header unless you have a specific reason not to. This matters for canonical routing and predictable behavior.
• Request body size: A proxy-level limit that is lower than the application’s practical use case creates hard-to-diagnose user complaints.
• Timeouts: Review read and connect timeouts if you see intermittent failures, especially in layered environments with load balancers in front of the proxy.
• Security headers: Add them one by one, then test creation, viewing, deletion, and any optional UI behavior. Header mistakes often show up as broken JavaScript, blocked assets, or odd clipboard interactions.
• Cache controls: Check not just your reverse proxy, but any CDN, ingress controller, or upstream gateway. Sensitive data should not be retained casually because of an inherited default.
• Logging scope: Access logs, error logs, and upstream logs may all retain metadata. Decide whether you need full request visibility or just enough for debugging and abuse response.
• Client IP trust chain: If more than one proxy is involved, do not trust every forwarded IP header blindly. Be explicit about which upstreams are trusted.
• Subpath hosting: If you are trying to serve PrivateBin under /paste/ instead of its own hostname, double-check every asset, redirect, and header behavior. A dedicated subdomain is usually simpler.
• Container network exposure: Make sure the app is not also published directly on a host port, bypassing the reverse proxy controls you carefully set up.

If you use PrivateBin in a regulated environment or as part of customer-facing security workflows, connect these checks to your control documentation. Articles like SOC 2 Considerations for Secure Paste Sharing Tools and Temporary Data Exchange can help frame why proxy configuration belongs in a broader cloud compliance story, even for a small utility service.

Common mistakes

The most common PrivateBin reverse proxy problems are usually not dramatic exploits. They are configuration shortcuts that weaken the deployment or make it hard to operate cleanly.

• Leaving the origin service directly reachable.
  If the app is exposed on a public port as well as through the proxy, your headers, rate limits, and TLS assumptions can be bypassed.
• Using broad, copied security headers without testing.
  A hardline CSP copied from another app can break the interface. PrivateBin is simple, but that does not mean every generic policy is safe.
• Trusting default logs too much.
  Defaults are often chosen for operability, not for privacy minimization. Review them with the same care you apply to app settings.
• Publishing on a shared catch-all virtual host.
  This makes mistakes easier to miss and can increase the blast radius of unrelated config changes.
• Forgetting that automatic TLS still needs monitoring.
  Certificate automation reduces work, but it does not remove the need to watch renewal, storage permissions, and DNS correctness.
• Not testing real user flows.
  A green status page is not enough. Test creating a paste, opening it from another device or browser profile, and using any expiration or burn-after-reading features you plan to rely on.
• Ignoring upstream trust boundaries.
  If a cloud proxy, CDN, or ingress controller sits in front of your reverse proxy, document who terminates TLS, who adds forwarded headers, and who is trusted to define the client IP.
• Overcomplicating the first deployment.
  A dedicated hostname, a straightforward proxy route, minimal headers, and deliberate logging are usually easier to secure than a heavily customized setup from day one.

When to revisit

This is not a set-and-forget configuration. Revisit your PrivateBin reverse proxy setup whenever one of these changes happens:

• Before seasonal planning cycles: use the review to catch certificate workflow drift, container image changes, and logging or retention settings that no longer match your current privacy posture.
• When workflows or tools change: especially if you move from direct hosting to Docker, from Nginx to Caddy, or from a single host to Traefik with dynamic routing.
• When you add a CDN, load balancer, or WAF: this changes trust boundaries, headers, caching, and TLS termination paths.
• When you enable new PrivateBin features or change retention defaults: proxy settings may need to be reviewed alongside application behavior.
• When a customer or internal security review asks new questions: document how the reverse proxy enforces HTTPS, logging scope, and access restrictions.
• After major distro, container, or proxy upgrades: defaults can shift over time, especially around TLS, HTTP versions, header behavior, and deprecations.

A practical review routine looks like this:

1. Open your current proxy config or labels.
2. Confirm the hostname, upstream target, and TLS path are still correct.
3. Verify PrivateBin is not directly exposed on any unintended port.
4. Test paste creation, retrieval, expiration, and deletion behavior.
5. Review security headers and remove any you no longer understand or need.
6. Review logs and retention settings for unnecessary metadata.
7. Document any environment-specific assumptions so the next admin does not have to rediscover them.

If you want one simple rule to keep this deployment maintainable, it is this: keep the reverse proxy layer boring, explicit, and easy to audit. PrivateBin works best when the public edge is predictable. A dedicated hostname, HTTPS-only access, careful forwarded headers, moderate request limits, and deliberate logging will take you further than a complex pile of copied snippets.