System requirements

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.

​

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. 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

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 and Backups and recovery.

​

Network and ports

Presenton needs stable outbound access to every configured text, image, search, database, and authentication provider. 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.

​

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: 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.