Architecture

Origamy is built as two planes with one pipeline between them. The control plane is where you configure things; the data plane is where your events live and move. They are separate systems by design: the data plane can run in Origamy Cloud or entirely inside your own network, and the architecture is identical either way.

The two planes

The control plane is hosted by Origamy and serves the dashboard and admin API at app.origamy.io. It is the source of truth for configuration — sources, destinations, transformations, segments, journeys, message templates, workspace membership. It holds configuration and workspace metadata only; your customer event data is never stored in the control plane.

The data plane is the event pipeline: it ingests, transforms, resolves identity, stores, and routes customer data, and executes messaging workflows. It runs either in Origamy Cloud or in your own infrastructure — same services, same behavior.

The two connect in one direction only. The data plane opens outbound TLS connections to a single Origamy endpoint on TCP 443 and keeps them alive:

Configuration flows down. A sync service in the data plane pulls its configuration from the control plane and distributes it to the pipeline services. Change a transformation in the dashboard and the pipeline picks it up without a redeploy.
Queries flow back up the same connection. When the dashboard shows live events, a profile, or an analytics chart, the control plane forwards that query through the established tunnel to the data plane, which answers from its local stores. Queries travel to the data; the data does not travel to Origamy. A self-hosted data plane needs no inbound ports at all.

Origamy’s two planes: your team works in the Origamy-hosted control plane (dashboard, admin API, configuration); your customers’ events flow into the data plane (ingest, transform, identify, store, deliver), which runs in Origamy Cloud or your infrastructure. One outbound TLS tunnel carries config down and queries up.

The event pipeline

Every event takes the same path, whether it came from the Web SDK, a server SDK, or the HTTP API.

Ingest. Events arrive over HTTPS at the ingestion gateway (events.origamy.io in Origamy Cloud; your own hostname when self-hosted). The gateway authenticates the write key, validates the payload, and persists the event to a durable stream before acknowledging — an accepted event is an event that cannot be lost to a crash.
Transform. The transformer engine runs your JavaScript transformations in a sandboxed runtime — filter, redact, enrich, or reshape events in flight.
Resolve identity. The identity resolver stitches anonymous devices and known users into a single profile, so a visitor who signs up on their phone and buys on their laptop is one customer, not three.
Fan out. The resolved event goes, in parallel, to the analytics store (ClickHouse), to your connected downstream destinations, and to real-time segment evaluation.
Act. Segment entries and events trigger the workflow engine, which runs your journeys and delivers messages through the providers you have connected.

A customer’s tap becomes an event that travels through the ingestion gateway, your JavaScript transformations, and identity resolution over durable acknowledged streams, then fans out to the ClickHouse analytics store, your destinations, and real-time segments — which feed workflows and messaging, and the customer receives a message.

Between every stage sits a durable, acknowledged stream (NATS JetStream). A service crashing mid-event means the event is redelivered, not lost. Events that repeatedly fail processing are parked in a dead-letter queue where you can inspect them — they are never silently dropped, and never replayed behind your back.

Deployment topologies

Both topologies run the same data plane. The only difference is who operates it and where your data sits.

	Origamy Cloud	Self-hosted
Control plane	Origamy-hosted	Origamy-hosted
Data plane	Origamy-hosted	Your VPC / cluster
Event data lives	Origamy Cloud, workspace-isolated	Your network — it never leaves
Network requirements	None	Outbound TCP 443 only
Install	Nothing to install	One CLI command (Docker or Kubernetes)

Origamy Cloud runs both planes inside Origamy’s boundary. Self-hosted keeps the control plane with Origamy while the data plane lives inside your network — your events never leave, with outbound port 443 as the only connection.

Tenancy and isolation

Every object in Origamy — sources, events, profiles, segments, journeys, API calls — is scoped to a workspace. Write keys identify a single source in a single workspace; admin API access is workspace-bound. Self-hosting adds a second, physical boundary: the datastores holding your events run in infrastructure you control, under your keys.

What it’s built on

Boring, proven infrastructure, chosen so a self-hosted data plane is something a platform team can actually operate:

Component	Role
Go services	Every pipeline service is a small, single-purpose Go binary
NATS JetStream	Durable event bus between pipeline stages
ClickHouse	Columnar store for events and analytics
PostgreSQL	Operational store (configuration, form responses, delivery state)
Redis	Caching and short-lived pipeline state
Sandboxed JS runtime	Runs your transformations in isolation — no arbitrary host access

No part of the pipeline requires a proprietary datastore, and the self-hosted bundle ships all of the above preconfigured — see Self-hosting for the operational details.