Organizer Sizing
The minimum recommended sizing of Output organizer services are as follows:
| Purpose | Replicas | Resource requests | Resource limits | |
|---|---|---|---|---|
| organizer | Back- and frontend to handle collections | 1 | memory: 1Gi, cpu: 500m , ephemeral-storage: 1Gi | memory: 2Gi, cpu: 1000m, ephemeral-storage: 1Gi |
| viewer | Document viewer | 1 | memory: 2Gi, cpu: 600m | memory: 4Gi, cpu: 2000m |
| controller | Execution engine for export jobs | 1 | memory: 1Gi, cpu: 500m | memory: 2Gi, cpu: 1000m |
| worker-topdf | Export functionality | 1 | memory: 2Gi, cpu: 600m | memory: 4Gi, cpu: 4000m |
Sizing recommendations for production
These recommendations refer to approximately 500 users. A ramp-up accompanied by thorough monitoring is strongly recommended to tune the settings according to your specific needs.
| Purpose | Replicas | Resource requests | Resource limits | |
|---|---|---|---|---|
| organizer | Back- and frontend to handle collections | max(n/4, 2) | memory: 2Gi, cpu: 1000m, ephemeral-storage: 10Gi | memory: 2Gi, cpu: 1000m, ephemeral-storage: 10Gi |
| viewer | Document viewer | max(n, 2) | memory: 4Gi, cpu: 2000m, ephemeral-storage: 1Gi | memory: 4Gi, cpu: 2000m, ephemeral-storage: 1Gi |
| controller | Execution engine for export jobs | 1 | memory: 2Gi, cpu: 1000m, ephemeral-storage: 1Gi | memory: 2Gi, cpu: 1000m, ephemeral-storage: 1Gi |
| worker-topdf | Export functionality | max(n/4, 2) | memory: 2Gi, cpu: 2000m, ephemeral-storage: 1Gi | memory: 4Gi, cpu: 4000m, ephemeral-storage: 1Gi |
n is a scaling factor, which means in this context you need approximately one instance of organizer for four instances of jwt. All instances should have at least a scaling of two, to be resistant to unexpected failures.
Database Sizing
For general information about resource management in container environments please see: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ Please also consult the documentation of your chosen database for more accurate recommendations.
Document Storage
Output Organizer stores imported and uploaded documents either in S3-compatible object storage or chosen volume (see Scaling and Deployment for configuration details). The space required is difficult to predict in advance and depends primarily on:
- Volume and size of imported documents — every document imported into a collection occupies storage for as long as the collection exists.
- Retention policy / automated deletion — if the automated deletion job is enabled, collections marked for deletion (and the user-uploaded documents belonging to them) are removed after the configured grace period, which significantly limits long-term growth. Without any deletion, storage grows continuously.
- S3 lifecycle management — use your storage vendor's lifecycle management features to handle these.
- Preprocessing (ℹ️ Output Organizer ADVANCED only) — when a preprocessing intent is used, Output Organizer stores a processed copy of each imported document alongside the original.
- Export artifacts — temporary files generated during export accumulate until cleaned up by the jadice flow cleanup mechanism (see Document Cleanup).
Database Storage
The database stores collections, annotations, page order, and similar structured data. Its size depends on:
- Number of collections — each collection and its elements contribute to the database size.
- History depth — every change to a collection is persisted as a version; environments with frequent edits and no cleanup accumulate history quickly.
- Cleanup frequency — regularly deleting old or closed collections via the automated deletion job keeps the database size manageable.
Monitor the database regularly and adjust storage allocation as the number of collections and history entries grows.