PrivateBin capacity planning is less about finding one universal maximum and more about measuring the limits of your specific deployment. This guide shows how to estimate paste volume, storage growth, request concurrency, cleanup workload, and user-facing limits, then turn those measurements into a recurring review process for reliable and secure operation.
Overview
A PrivateBin instance can be suitable for anything from occasional incident-log sharing to a busy internal service used by developers, support teams, or automated workflows. The practical capacity of the service depends on the complete request path: browser, reverse proxy, web server, application configuration, storage backend, database or filesystem performance, and the process that removes expired pastes.
There is therefore no single answer to “How much traffic can PrivateBin handle?” A small deployment may have ample CPU capacity but fail because its proxy rejects larger requests. Another may accept large pastes but experience slow cleanup or storage exhaustion. Capacity should be defined as the point at which the service still meets your requirements for response time, availability, retention, and safe operation.
Before changing limits, document the assumptions behind your deployment. Record the PrivateBin release and configuration, hosting resources, storage type, reverse-proxy settings, retention periods, expected user population, and whether uploads or other optional features are enabled. Configuration behavior can change between releases, so verify important settings against the version you operate rather than copying values from an unrelated installation.
For a security-focused baseline, pair performance work with the PrivateBin Security Hardening Checklist. A larger capacity limit is not automatically a better limit if it increases abuse potential, storage risk, or the impact of an accidentally shared sensitive file.
What to track
Use a simple capacity register or dashboard that records the following variables. The goal is to identify trends before users experience failures.
| Variable | What to measure | Why it matters |
|---|---|---|
| Paste size | Typical size, largest accepted request, and rejected requests | Large requests consume bandwidth, memory, proxy capacity, and storage. |
| Paste volume | New pastes per hour and per day, separated by normal and peak periods | Volume determines write load and helps forecast storage growth. |
| Storage use | Total used space, free space, inode use where relevant, and growth rate | Storage exhaustion can prevent new pastes and interfere with cleanup. |
| Retention and cleanup | Configured expiration, expired items awaiting removal, and cleanup duration | Short-lived content still creates temporary storage and deletion work. |
| Request performance | Response-time percentiles, error rate, and timeout count | Average latency can hide slow requests during peaks. |
| Concurrency | Simultaneous reads, writes, active connections, and queue depth where available | Spikes can exhaust worker, connection, or database limits before CPU is full. |
| Resource pressure | CPU, memory, disk latency, database load, and network throughput | These signals help identify the constrained layer. |
Track limits at every layer. A PrivateBin paste size limit set in application configuration may not be effective if the reverse proxy has a smaller request-body limit or a shorter timeout. Browser behavior also matters: very large pastes can be slow to encrypt, upload, render, or retrieve, especially on constrained devices. Treat the smallest reliable limit across the path as the practical user-facing limit.
Estimate storage with a workload model instead of a single guess:
Approximate daily storage growth = new pastes per day × average stored paste size + operational overhead.
Use observed values when possible, and model a peak case separately. Include the effect of retention: a service receiving 1 GB of new content each day does not necessarily need only 1 GB of storage. If content remains available for several days, the active dataset can be several times larger, with additional space needed for backups, temporary files, logs, and safe maintenance.
For a more complete content-handling review, see the PrivateBin File Upload Security Checklist. If the service is part of a regulated workflow, document the resulting limits and retention assumptions alongside your data retention policy.
Cadence and checkpoints
A monthly review is appropriate for a stable, low-volume deployment. Review more frequently during a launch, migration, policy change, or period of rapid adoption. A quarterly capacity review can be sufficient once usage patterns are well understood, provided automated alerts continue to run between reviews.
Monthly review
- Compare new-paste volume and peak concurrency with the previous period.
- Check storage growth against the forecast and confirm that expiration cleanup is keeping pace.
- Review rejected requests, gateway errors, timeouts, and unusually slow reads or writes.
- Confirm that backups, logs, and monitoring have not consumed an unexpected share of disk space.
- Record configuration changes, software upgrades, and infrastructure changes.
Quarterly capacity checkpoint
- Recalculate capacity using recent average and peak workload data.
- Run a controlled load test in a test or isolated environment.
- Test the largest permitted paste and representative concurrent reads and writes.
- Verify reverse-proxy, web-server, application, database, and storage limits as one request path.
- Review whether retention, paste-size, or access controls still match the service’s purpose.
Keep load tests realistic and safe. Use synthetic content, do not use production secrets, and avoid testing a public endpoint in a way that could resemble abuse. Measure successful completion as well as failure: a test is not useful if it proves that requests can be accepted but does not verify retrieval, expiration, cleanup, monitoring, and recovery afterward.
How to interpret changes
Capacity signals are most useful when interpreted together. Rising disk use with stable paste volume may indicate longer retention, larger average pastes, failed cleanup, backup accumulation, or a change in storage behavior. Rising latency with low CPU may point to storage latency, database locks, worker limits, or a proxy timeout rather than insufficient compute.
A growing error rate during traffic spikes usually calls for identifying the first saturated layer. Check connection counts and worker availability, then compare application logs with proxy and storage metrics. Do not simply raise every limit: increasing request size or concurrency can transfer pressure to memory, disk, or downstream services and can make denial-of-service conditions more costly.
Watch for distribution changes, not only averages. A stable average paste size can hide a small number of very large requests. Likewise, a comfortable daily volume can conceal a short peak that exhausts connections. Track maximums or high-percentile values, establish an alert before the service reaches a hard limit, and leave operational headroom for maintenance and unexpected demand.
Performance is also a security concern. Restricting paste size, applying sensible expiration, limiting access where appropriate, and monitoring unusual volume can reduce resource abuse. When a link or paste is exposed, capacity concerns may overlap with incident handling; use the PrivateBin Incident Response Runbook rather than treating the event as an ordinary performance issue.
When to revisit
Revisit this capacity plan at least monthly for trend review and formally refresh it each quarter. Update it immediately after a PrivateBin release, configuration change, storage migration, reverse-proxy change, retention-policy change, or material increase in users or paste volume. Also review it before a high-volume launch, an incident-response exercise, or a new integration that creates pastes automatically.
At each review, answer five practical questions:
- What is the current largest accepted paste, and do all request layers support it?
- How quickly is active storage growing under normal and peak workloads?
- Does expiration cleanup complete before storage or operational thresholds are reached?
- Which resource becomes constrained first during a controlled test?
- What limit or alert should be changed, and what security trade-off does that change introduce?
Save the answers with the configuration version, test date, workload assumptions, and observed results. That record becomes useful evidence for operational reviews and security questionnaires; the PrivateBin Security Questionnaire Guide and audit evidence checklist provide related documentation prompts.
Finally, keep a conservative fallback plan. Define who receives storage and error alerts, how new paste creation can be restricted during an incident, how expired data is verified and removed, and how service capacity can be restored without weakening privacy controls. Capacity planning works best as a recurring cloud security practice: measure, test, document, and revisit whenever the workload or deployment changes.
