From zero to a compiled document.

nautris is self-hosted: it runs entirely in your infrastructure as a Docker image. This page takes you from an empty machine to parsing your first document.

Deploy with Docker

Pull the engine image straight from our registry, no account or login required, then deploy with a compose file. The image is public; the engine still needs a valid license to run (it refuses to start without one), so the license, not the registry, is the gate.

docker pull registry.nautris.com/nautris:latest

# docker-compose.yml - one image, two roles: API + N workers on a shared volume
services:
  api:
    image: registry.nautris.com/nautris:latest
    restart: unless-stopped
    ports: ["8000:8000"]
    environment:
      NAUTRIS_LICENSE: ${NAUTRIS_LICENSE:?required}
      NAUTRIS_WORKERS: "0"      # the API enqueues...
      NAUTRIS_BACKGROUND: "1"   # ...the worker containers process
      NAUTRIS_RAG_DB: /data/lancedb
    volumes:
      - engine-data:/data

  worker:
    image: registry.nautris.com/nautris:latest
    command: ["python", "-m", "nautris.worker"]
    restart: unless-stopped
    environment:
      NAUTRIS_RAG_DB: /data/lancedb
    volumes:
      - engine-data:/data
    mem_limit: 8g     # isolates a heavy doc to one worker; large OCR PDFs peak past 4g

volumes:
  engine-data:

The published image (registry.nautris.com/nautris:latest) is ~6-7 GB: it carries the CUDA torch build so the one image runs on both CPU and GPU hosts. No GPU is required; it falls back to CPU. (Building from source with the default CPU wheels yields a slim ~2.7 GB image if you know you will never use a GPU.) Extraction models are fetched once on first run into the shared volume. Scale extraction with docker compose up --scale worker=4.

System requirements

No GPU is required: the core path is fully CPU-deterministic, and a GPU only accelerates the same OCR when one is present. What actually matters:

Measured throughput: born-digital documents extract at roughly 280-300 pages/min on a single GPU worker (a 150-page report finishes in about 32 s); full GPU OCR on image-heavy scans runs around 20 pages/min. On the published benchmark corpus the engine scores 100% on tables, reading order, and headings.

When resources run short, failures stay contained and visible, never silent corruption:

• Disk full: image pulls fail loudly; a mid-job failure retries, then lands in the dead-letters view in /ui with its error. Free space, hit Requeue.
• Out of memory: under Docker Compose each worker is fenced by mem_limit (8 GB in the example above; raise it for large OCR-heavy PDFs, which can peak past 4 GB), so a heavy document kills only that worker (exit 137) and the job dead-letters while the API and UI stay up. Bare pip installs have no fence, so prefer Compose on small machines.
• Slow CPU: never fatal. POST /v1/parse degrades to 202 + job ID after ~55 s and the queue keeps working; poll GET /v1/jobs/{id}.
• x86 CPU without AVX2/FMA: no longer fatal (as of engine 0.9.2). Born-digital documents still extract via the model-free fast path. Documents that need the ML pipeline (scanned / OCR / complex layouts) fail cleanly with a clear ml-unavailable error instead of crash-looping the worker (older versions aborted with SIGILL / exit 132). To process those, run the engine on a newer x86 host (AVX2), an NVIDIA GPU, or ARM/Apple Silicon (which run the ML path without AVX2). Check x86 support with grep -qw avx2 /proc/cpuinfo && echo ok || echo "no AVX2: born-digital only".
• Oversized inputs: uploads stream against a hard cap (413 past 50 MB by default) instead of buffering into memory; workers run with pids/memory caps and a read-only rootfs.

Quickstart

A valid license is required: the server refuses to start without one (personal licenses are free and instant at get.nautris.com). There are no API keys to invent: the engine mints a default token on first boot, prints it in the startup logs, and shows it in /ui.

export NAUTRIS_LICENSE="nl1...."   # free personal license
docker compose up -d
docker compose logs api | grep "Default API token"
#   Default API token: dek_...

Parse a document and search it (send the token as X-API-Key):

# parse one file, get the canonical tree back in a single call
curl -X POST localhost:8000/v1/parse -H "X-API-Key: dek_..." -F "file=@mydoc.pdf" | jq .tree

# semantic search across everything indexed
curl -G localhost:8000/v1/search -H "X-API-Key: dek_..." --data-urlencode "q=your question" | jq '.[0]'

Then open the review dashboard at http://localhost:8000/ui. It signs itself in with the default token automatically; view, copy, or rotate the token on its API token page.