Architecture

System diagram

Frontend
    │
    │  POST /ordo/jobs
    │  GET  /ordo/jobs/:id
    ▼
Ordo (orchestration layer)
    │  validates recipe + inputs
    │  stores job state in PostgreSQL
    │
    │  n8n workers poll for pending steps
    ▼
n8n Workers
    │  claim step from job_step table
    │  download artifact from MinIO
    │  run executor (PDAL / Entwine / PotreeConverter / etc.)
    │  upload result artifact to MinIO
    │  report step completion back to Ordo
    ▼
MinIO (object storage)
    │  input datasets
    │  intermediate artifacts
    │  final output files

How it fits together

Ordo is the control plane. It does not execute steps — it validates, stores, and tracks them. When a job is submitted, Ordo validates the recipe, creates a row in job, creates rows in job_step for each step, and returns the job ID. That's all.

n8n workers are the execution layer. Each worker polls PostgreSQL for pending steps, claims one, downloads the required input artifact from MinIO, runs the appropriate tool (PDAL, Entwine, PotreeConverter, etc.), uploads the output artifact to MinIO, and reports success or failure back to Ordo.

MinIO is the artifact store. Input datasets and all intermediate and final artifacts live there. Ordo stores artifact URIs; it does not move or inspect the data itself.

The frontend submits jobs to Ordo and polls for status. It never talks to n8n directly.

Key design decisions

• Ordo owns job state. n8n workers are stateless and interchangeable.
• Artifact names flow unchanged through the DAG — there is no aliasing or renaming.
• on_exit hooks (e.g. CALL_WEBHOOK) run after the main recipe completes, regardless of success or failure.
• All artifact uploads and finalizations are performed by n8n, not Ordo.