API requests
Templates, payloads, and auth hit the control plane first.
Platform architecture
Clean boundaries between authoring, orchestration, and execution
DocumentFlux keeps authoring, orchestration, background execution, and conversion in distinct runtime roles so the platform is easier to scale and troubleshoot.
- Cleaner ownership boundaries
- Safer performance profile
- Deployment choices without rewrites
Requests in
Queued jobs
Work becomes durable before it reaches a worker.
Render path
Runtime boundaries
Separate API, queue, workers, and converters before scale turns them into one knot.
- 01Persist jobs
- 02Execute safely
- 03Store and deliver
Execution out
Worker execution
Background tasks render, retry, and package files.
Converters and storage
Files move through runtimes and land in a managed output surface.
The line between orchestration and execution stays visible, so failures and ownership stay easier to reason about.
Why this matters: The architecture review is simpler when experience, orchestration, workers, and conversion services are separated early.
Topology
Containerized by role, not by convenience
Django and DRF own state, auth, and orchestration.
Celery workers handle expensive execution and failure-prone side effects.
Redis brokers background work.
PostgreSQL stores templates, versions, jobs, users, and settings.
Gotenberg and UnoServer keep conversion responsibilities isolated.
Traefik fronts production routing while the frontend remains a separate application surface.
01
Experience Layer
Teams manage templates, previews, approvals, and delivery from one browser workspace.
02
Control Plane
The application layer keeps versions, permissions, jobs, and configuration consistent.
03
Execution Plane
Background workers process generation, retries, packaging, and delivery away from the UI.
04
Conversion Runtimes
Dedicated runtimes handle browser-style and office-style outputs for broader compatibility.
05
Persistence And Retention
Storage, queueing, and retention keep the workflow auditable and production-ready.
Deployment paths
Adopt the platform in the environment your team can actually operate
Different organizations need different deployment boundaries. The product is already structured to support that conversation.
Private Cloud
Run the product inside controlled infrastructure without changing the user workflow.
Self-Hosted
Deploy with clear service boundaries for the app, workers, storage, queue, and converters.
Embedded Platform
Embed generation into your product without assembling the full document stack yourself.
Render path
From request to file delivery without hiding the hard parts
The rendering path is explicit so operators can reason about failures, retries, and delivery guarantees.
Request
The API receives a render request tied to a template and payload.
Persist
A render job becomes the durable handoff between the request path and background execution.
Execute
Workers claim jobs, assemble context, and render the selected template version.
Convert
The runtime chooses Chromium or LibreOffice-compatible conversion when PDF output is required.
Deliver
The system stores the result, updates job state, and exposes download or webhook completion.
Next Step
Review the deployment shape before you inherit another brittle rendering service
Bring your current conversion stack, latency targets, and tenancy model. We will walk the architecture with the people who will have to run it.
In the session