Concepts
Architecture
How Portlane splits flow authoring (git) from flow execution (on-prem engines)
Portlane runs as a small set of stateless engines on infrastructure you control, coordinated through a central Postgres database that acts as both message bus and system of record.
Engines and Postgres
| Role | Engines | What they do |
|---|---|---|
| Ingress | listener, pooling | Receive webhooks or poll external systems, persist the raw event |
| Routing | broker | Normalize each event and route it to the right processing queue |
| Transformation | worker | Apply your business logic to each message |
| Egress | distribute | Deliver transformed messages to target systems |
| Control plane | supervision (Control Tower) | Health, events, and the operator console |
Each engine reads its input from a Postgres queue and writes its output back to Postgres. There is no in-memory work in flight between steps — every engine can restart, scale, or fail independently without losing a message.
Why this shape matters
Classic iPaaS often routes all data through a vendor cloud. Portlane inverts that: the platform runs entirely on infrastructure you already operate. There is no external runtime to trust with your payloads.