Architecture
Praxis has two parts that work together but stay cleanly separated: the Praxis Cloud management plane where pipelines are designed and managed, and Praxis Collectors that run in the customer environment and actually move the data.
The single most important idea to take from this page: telemetry never transits through Praxis Cloud. The cloud tells collectors what to do; collectors send logs, metrics, and traces directly to the configured destinations. Control and data travel on separate paths.
- Solid line = Telemetry flows from collectors straight to the destinations.
- Dotted lines = control and operational metadata. These are the only things that touch the cloud.
For the vocabulary used throughout the docs (management plane, collector, pipeline), see Getting started. For the byte-level security detail behind the diagram above, see Collector connectivity security.
The two planes
Praxis Cloud (management plane)
Praxis Cloud is the control and design surface — not a telemetry store.
| Praxis Cloud does | Praxis Cloud does not do |
|---|---|
| Host the UI and APIs where pipelines are designed | Receive or store logs/metrics/traces |
| Validate graphs and publish versions to collectors | Sit in the data path between source and destination |
| Store integration records and credentials for destinations | Act as a pipeline destination for bulk telemetry |
| Show operational insights — throughput, health, version, rollout state | Require inbound access into the customer network |
| Push configuration and remote actions (reload, restart, upgrade) | — |
Because the cloud is not in the data path, its availability does not gate telemetry: a collector keeps running its last published pipeline and delivering data even if it briefly cannot reach the cloud.
The Praxis Collector (data plane)
A Praxis Collector is a single agent (praxis-collector) that runs close to
the data. Every collector — regardless of where or how it is deployed — does the
same three things:
- Ingests from the configured sources (files, syslog, cloud APIs, Kubernetes, webhooks, and more).
- Processes in-flight using the processors in the pipeline (parse, transform, filter, mask/redact, sample, batch, enrich).
- Exports to the attached destinations — directly, over each destination's own secure transport.
A collector connects outbound-only to Praxis Cloud on two channels, and opens inbound listeners only for the push-style sources that are explicitly configured:
| Channel | Protocol | Purpose |
|---|---|---|
| Control & configuration | OpAMP over secure WebSocket (wss://, 443) | Enrollment, receiving pipeline config, status, remote actions |
| Collector metrics | HTTPS (443) | Collector and Pipeline Observability Data |
| Data plane | Per destination (HTTPS, vendor transports) | Telemetry, sent directly to the configured destinations |
Enrollment uses OAuth 2.0 machine-to-machine credentials; on first start the collector moves them into an AES-256-GCM encrypted local store keyed to the host. Full detail: Collector connectivity security.
:::tip One build, many roles Everything below is the same collector. "Standard", "gateway", and "webhook" describe network placement and pipeline configuration — not different installers or SKUs. A collector's role changes by changing the pipeline assigned to it, not by installing different software. :::
What a pipeline is
A pipeline is the graph designed in Praxis Cloud and published to collectors:
A pipeline is authored visually, validated, and published as a version. Publishing rolls that configuration out to every collector assigned to the pipeline over the OpAMP control channel. Collectors report an applied/failed status back, and the cloud shows rollout state. See Create a Pipeline and Overview, Pipelines, and Collectors.
Deployment topologies
The same collector can be placed in a network in several ways. Most estates use more than one at once.
1. Standard (direct) collector
The baseline. A collector runs on a host, VM, or workload; it collects from local or nearby sources, processes, and exports directly to the destinations.
Use it when each node can reach the destinations on its own and per-node egress and credentials are acceptable. It is the simplest model and the default for a single host or a small fleet.
2. Gateway collector
A Praxis Gateway is a standard collector placed as a concentration and egress tier. Many collectors — and optionally non-Praxis syslog, TCP, or UDP senders — forward into it; the gateway applies shared org-wide policy once, then is the single hosts that egress to the destinations.
Use it to:
- Concentrate egress — few hosts reach the internet/SaaS instead of every node.
- Concentrate secrets — export credentials and mTLS material live on the gateway tier, not on every end node.
- Apply org-wide policy once — PII redaction, routing, and sampling run on the gateway after all ingress paths converge.
- Onboard appliances and legacy senders — devices that speak only syslog/TCP/UDP, or existing third-party forwarders, share the gateway without running a Praxis Collector each.
- Draw a DMZ / trust boundary — place the gateway at the edge between untrusted and trusted network segments.
Collectors can optionally forward to the gateway over a secure transport (TLS or mTLS on those hops).
Full guidance: Praxis Gateway collector overview, configuration, and TLS & certificates.
3. Public webhook collector
Some sources push events over HTTP rather than being polled. For those, a collector runs on a public VM and exposes an HTTPS endpoint that the sending service reaches over the internet.
Use it when a source (Auth0, Meraki, Jira, HubSpot, generic HTTP, …) delivers events by webhook. Provision a stable public address (DNS A record), open the required firewall ports, and terminate TLS with a trusted certificate. The webhook listener is the only inbound port involved — the control and metrics channels remain outbound-only.
- Setup: Public webhook collector; receivers: Webhook sources.
4. Kubernetes
In a cluster, install a collector supervisor (a single Deployment). It
enrolls with Praxis Cloud over OpAMP and creates and manages child collector
workloads that run the pipeline.
The supervisor maps the pipeline onto the right workload shapes automatically —
DaemonSet for per-node collection (logs, host and kubelet metrics), Deployment
or StatefulSet for cluster-scoped signals — and can collapse multiple node-level
signals into a single node agent to keep per-node overhead low.
- Prerequisites and steps: Kubernetes install.
5. Managed cloud runtime (no collector to install)
For Google SecOps data processing, Praxis orchestrates a pipeline that runs
inside the SecOps ingestion path via its logProcessingPipeline APIs. The
graph is designed in Praxis and bound to a SecOps tenant; there is no collector
to install for this pipeline type — Praxis calls SecOps directly.
Use it to shape SecOps-bound logs (filter, transform, redact) before or during ingestion, managed centrally from Praxis. This is distinct from the Google SecOps destination, which ships logs from collectors into SecOps. Details: Google SecOps data processing pipeline.
Choosing a topology
| For… | Use |
|---|---|
| One host or a small fleet that can reach destinations directly | Standard collector |
| Many collectors with one controlled egress + shared policy + concentrated secrets | Gateway collector |
| Ingesting appliances/syslog or keeping third-party forwarders | Gateway collector (collector + syslog/TCP/UDP ingress) |
| Push/webhook events from external services | Public webhook collector |
| Running in Kubernetes | Kubernetes Supervisor Deployment |
| Shaping SecOps-bound logs in Google SecOps with nothing to install | Google SecOps Data Processing Pipeline Integration |
These are not exclusive. A common estate runs standard collectors and node agents across hosts and clusters, funnels them through a gateway tier for egress, exposes a webhook collector for push sources, and manages SecOps processing from the cloud — all designed and operated from the same management plane.
Security at a glance
- Directional separation — control is outbound-only to Praxis Cloud; telemetry goes only to the configured destinations. No inbound access into the customer network is required for management.
- Encryption everywhere — control over
wss://(TLS 1.2+, TLS 1.3 where available); collector metrics over HTTPS (TLS 1.3 minimum); destination transport governed per destination, with optional mTLS on gateway hops. - Authenticated agents — OAuth 2.0 machine-to-machine enrollment; short-lived, signed (RS256) bearer tokens that auto-refresh.
- Protected credentials — bootstrap credentials are moved into an
AES-256-GCM store keyed to host identity; on Kubernetes, delivered via
Secret-backed environment variables. - Verified upgrades — self-upgrade packages are checked against a published SHA-256 checksum before applying.
Full reference: Collector connectivity security.
Next steps
- Getting started — adoption path and key terms.
- Overview, Pipelines, and Collectors — the day-to-day work surface.
- Installation overview — pick a platform and enroll a collector.
- Integrations — the sources, processors, and destinations available.
- Praxis API — automate pipelines and collectors over HTTP.