> ## Documentation Index
> Fetch the complete documentation index at: https://docs.presenton.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# System requirements
> Choose practical CPU, memory, storage, network, and optional GPU capacity for self-hosted Presenton.
Presenton runs the web application, API, document parser, OCR, and presentation export service in one container. Text and image generation can run on hosted providers or on separate local model services such as Ollama and ComfyUI.
The estimates below cover the Presenton application and assume that text and image models run on hosted providers. Add the [local model capacity](#local-model-and-gpu-capacity) when Ollama, LM Studio, ComfyUI, or another inference service runs on the same host.
## Recommended server sizes
Use these tiers as initial capacity, not as hard limits. An **active job** means a presentation being generated, a document being parsed, or a presentation being exported—not simply a user with the page open.
| Deployment | CPU | Memory | Free SSD space | Practical starting workload |
| -------------------------- | ---------: | ------------: | -------------: | --------------------------------------------------------------------------- |
| Evaluation or personal use | **2 vCPU** | **4 GB RAM** | **10 GB** | One active job at a time, small or normal documents, hosted AI providers |
| Small team (recommended) | **4 vCPU** | **8 GB RAM** | **20–50 GB** | About 2 simultaneous active jobs, regular uploads and exports |
| Document-heavy or API use | **8 vCPU** | **16 GB RAM** | **50–100+ GB** | About 4 simultaneous active jobs, large PDFs, OCR, or sustained API traffic |
Do not plan a production deployment with less than 2 vCPU or 4 GB RAM. The interface may start on a smaller host, but document parsing, Chromium-based export, and overlapping jobs can run out of memory or become unresponsive.
For production, prefer sustained CPU capacity over a heavily throttled or burst-only instance. Capacity is shared with the operating system, Docker, a reverse proxy, and any database or local provider on the host; do not count memory reserved for those services as available to Presenton.
## How to adjust the estimate
Start with the tier closest to the expected workload, then increase it when any of the following apply:
* Add approximately **1–2 vCPU and 2 GB RAM for each additional simultaneous document-processing or export job**. This is a planning allowance; measure the actual files and templates used by your team.
* Use at least **8 GB RAM** when users regularly upload long, scanned, image-heavy, or high-resolution PDFs.
* Increase CPU before raising `LITEPARSE_NUM_WORKERS`. As a starting rule, keep at least one CPU core available for the application and do not configure more parser workers than the remaining vCPUs.
* Leave memory headroom for short peaks. Avoid setting the container memory limit equal to its normal observed usage.
* Provider latency and rate limits can remain the bottleneck even after the server is enlarged.
## Host and container requirements
| Component | Requirement |
| ----------------- | ------------------------------------------------------------------------ |
| Architecture | 64-bit `amd64` (x86-64) or `arm64` |
| Production host | A currently supported 64-bit Linux distribution |
| Container runtime | A current Docker Engine release or compatible container platform |
| Source deployment | Git and Docker Compose v2 in addition to Docker Engine |
| Application port | A host port routed to container port `80`; examples use host port `5001` |
| Persistent data | A durable volume mounted at `/app_data` |
| Browser | A current version of Chrome, Edge, Firefox, or Safari |
The published container includes the application runtime, Chromium, OCR, fonts, and export dependencies. A server running the published image does **not** need a separate Node.js, Python, Chromium, or Tesseract installation. Building from source is more demanding; allow at least **4 vCPU, 8 GB RAM, and 20 GB of free disk** during the build.
Docker Desktop on macOS or Windows is suitable for evaluation and local use. A Linux host is the recommended production target.
## Storage planning
Mount `/app_data` on persistent, low-latency SSD or block storage. It can contain the database, uploaded source files, generated images, presentations, templates, local memory, and exported PPTX or PDF files.
Reserve storage for all of the following:
* **5–10 GB for container images and upgrades.** An upgrade can temporarily keep both the old and new image on disk.
* **Uploads at their original size.** Retained source documents are not represented by the presentation count alone.
* **Approximately 50–250 MB per retained, image-rich 10-slide presentation** as an initial estimate for generated assets and exports. Image resolution, source files, templates, and multiple export copies can raise this substantially.
* **At least 20% free space** so exports, uploads, database writes, and upgrades have working room.
* **Backup capacity outside the application volume.** A full backup needs space comparable to the used size of `/app_data`; keep additional generations according to the retention policy.
For example, a team retaining 100 image-rich presentations should start with roughly **25–50 GB** for Presenton data and operating headroom, then adjust from measured growth. The 10 GB minimum is intended only for evaluation with limited retained content.
An external PostgreSQL or MySQL database does not replace `/app_data`; files and generated assets still require persistent storage. See [Storage and processing](/archive/v0.9.6-beta/self-hosted/configuration/storage-and-processing) and [Backups and recovery](/archive/v0.9.6-beta/hosting/backups-and-recovery).
## Network and ports
Presenton needs stable outbound access to every configured text, image, search, database, and authentication provider.
| Direction | Port or protocol | Purpose |
| --------------------------- | ---------------------------------- | ------------------------------------------------------------------------- |
| Inbound | Host port mapped to container `80` | Web interface, REST API, and MCP |
| Inbound, optional | TCP `1455` | ChatGPT/Codex OAuth callback only |
| Outbound | DNS and HTTPS (`443`) | Container registry, hosted AI, image, search, and authentication services |
| Outbound or private network | Provider-specific | Ollama, LM Studio, ComfyUI, SearXNG, and external databases |
There is no fixed bandwidth requirement. For planning, use a stable **10 Mbps connection as an evaluation floor** and **50 Mbps or more for a team** that frequently uploads documents or generates images. Latency to hosted providers usually affects generation time more than raw bandwidth.
Publish port `1455` only when the ChatGPT/Codex authentication callback is required. Put remote deployments behind HTTPS, enable authentication, and restrict provider and database ports to trusted networks. See [Security and access](/archive/v0.9.6-beta/hosting/security-and-access).
## Local model and GPU capacity
A GPU is **not required** when Presenton uses hosted text and image providers. Attaching a GPU to the Presenton container does not accelerate a hosted provider.
When a local model server shares the host, its model weights, context cache, and inference runtime are additional to the Presenton requirements. The following are rough allowances for common 4-bit-quantized text models:
| Local text model size | Additional system RAM or GPU VRAM | Suggested total host memory |
| --------------------- | --------------------------------: | --------------------------: |
| 3B–4B parameters | 4–6 GB | 16 GB RAM |
| 7B–8B parameters | 6–10 GB | 16–24 GB RAM |
| 13B–14B parameters | 10–16 GB | 32 GB RAM |
| 30B–32B parameters | 24–32 GB | 48–64 GB RAM |
Long context windows, higher-precision weights, multiple loaded models, and concurrent inference require more memory. CPU-only inference works but can be much slower; plan **8 or more modern CPU cores** for a small local model when generation speed matters.
For local image generation through ComfyUI, **8 GB VRAM is a practical floor** for smaller or optimized workflows, while **12–16+ GB VRAM** is a better starting point for higher-resolution or more complex workflows. Exact requirements are determined by the selected checkpoint and workflow.
NVIDIA GPU passthrough requires a compatible NVIDIA driver, the NVIDIA Container Toolkit, and a container started with GPU access. A local provider running on another machine needs no GPU on the Presenton host.
## Validate before production
1. Deploy the recommended tier for the expected workload.
2. Generate a representative presentation from the largest typical source document.
3. Export it to every format the team uses.
4. Repeat with the expected number of simultaneous active jobs.
5. Record peak CPU, memory, temporary disk use, `/app_data` growth, provider latency, and job duration.
6. Keep at least **25% memory headroom** and **20% disk headroom** after the test; move up a tier if either margin is not available.
Run the published image or build Presenton from source.
Measure bottlenecks and tune the deployment after launch.