Docs
How Riptide is organized
Riptide separates configuration, ad serving, and agent access into three planes. The control plane compiles configuration into a versioned ServingPlan. Regional serving cells load that plan to run auctions, while the agent gateway provides permissioned access to administrative tools.
Control plane
Stores configuration and account records. It includes the admin API (console), Postgres, the Plan Compiler (planc), billing (meter), authentication, and audit.
Data plane
Handles auctions (serve), request enrichment (enrich), and tracking events (beacon). Services run in regional cells with local Redis and ScyllaDB stores.
Agent plane
Provides MCP tools for administrative work. Agent identities, permissions, action limits, approval tasks, and audit records control what each agent can do.
How a plan reaches serving nodes
The Plan Compiler creates a versioned ServingPlan for each cell in object storage. The Plan Distributor sends the snapshot and subsequent updates to serving nodes. Nodes apply updates to an in-memory copy, then switch to the new version atomically. Auctions read this local plan without querying the configuration database. You can roll configuration back by selecting an earlier snapshot.
Cells
Each cell serves a set of tenants in a specific region. Separate cells limit the impact of failures and allow regional rollouts. Place tenants in the appropriate cells to meet their data-residency requirements.
For ad serving, use the OpenRTB, VAST tag and Decision API guides. For configuration and reporting, use the SDKs.
Discuss your deployment architecture
Share your expected traffic, ad formats, and the systems you need to connect. We can help you choose a plan and identify the setup work.