Architecture internals

This section documents Portlane internals for licensed customers running on-prem. It is not published on the public docs site.

Two deployment tracks

Everything running on a Portlane server ships as a container image, pulled from a private registry — never pushed to the server:

• Platform track — the six core engines, released together and pinned by digest per version.
• Flow track — your portlane-pipelines repository, built into a dedicated worker image on every push, deployed independently of the platform release.

A self-hosted CI runner on each server pulls new images and applies routing changes locally; the server never accepts inbound connections from CI.

Reliability

• Every processing step reads from and writes to durable Postgres queues — no message is ever only in memory.
• Failed messages land in a dead-letter state after max retries and can be replayed by an operator from the console.
• Engines are stateless and horizontally scalable; a crash mid-message is safe because the message stays claimed in Postgres until acknowledged.

Security model

• Transform code is baked into a versioned image at build time — never loaded dynamically at runtime.
• Target secrets (URLs, tokens) are resolved at publish time from files that live only on the instance, never in git or CI.
• Inter-engine communication stays inside the server's private Docker network; only ingress and the console expose a port.

Deployment topologies

Common patterns:

• Single instance — one server running platform and flow engines together (dev/lab).
• Dev and prod split — two independently deployable instances, same flow cards, different target secrets.
• Air-gapped — install from an offline image bundle, no outbound registry access required.

For diagrams specific to your install, use the Control Tower documentation after installation.