Architecture Overview

What is Qpoint?

Qpoint provides eBPF-based traffic visibility for observability, security, and compliance. At its core, Qpoint consists of:

  • Qtap (Data Plane): A lightweight eBPF agent that captures network traffic at the Linux kernel level

  • Optional Control Plane: Choose between cloud-managed (Qplane at app.qpoint.io) or self-managed (YAML) deployment

Guiding Principles

Qpoint is designed with two core principles in mind:

  1. Deep Visibility: To provide a complete, unencrypted view of your application traffic, including payloads, with full context (process, container, host, user, etc.).

  2. Data Sovereignty: To ensure that your sensitive data, the actual content of your traffic, never leaves your environment. You retain full control and ownership of your most critical data at all times.

Core Components

Qtap (The Data Plane)

Qtap is a lightweight, high-performance eBPF agent that you install on your infrastructure. It is the data plane that captures and processes traffic directly from the Linux kernel.

  • How it Works: By attaching to low-level TLS/SSL functions within the kernel, Qtap intercepts data before it's encrypted and after it's decrypted. This provides access to the original, plain-text data without needing to manage certificates, modify applications, or install invasive proxies.

  • Out-of-Band Operation: Qtap operates out-of-band, meaning it observes traffic without being in the critical path. This ensures it adds no latency and cannot disrupt application performance.

  • Rich Context: It enriches the captured data with a wealth of context, including the associated process, container, host, user, and protocol information.

  • Flexible Deployment: Can run standalone with YAML configuration or connect to Qplane for centralized management.

Qscan (Data Classification)

Qscan is an optional service, typically run as a Docker container, that is responsible for deep inspection and classification of your data payloads.

  • Function: Qtap can be configured to send data to Qscan, which then identifies specific types of sensitive information (PII, credentials, secrets, etc.) based on predefined or custom rules.

  • Deployment: Generally you host Qscan within your own environment. This ensures that the process of scanning and classifying your sensitive data happens securely under your control.

Object Storage (Your Data Warehouse)

You provide your own S3-compatible object store (e.g., AWS S3, MinIO, Google Cloud Storage) where sensitive payload data is stored.

  • Function: The Qtap agent sends Objects (request/response headers and bodies) directly to this storage bucket.

  • Security: This data flow is direct from the agent in your environment to the object store in your environment. This sensitive data never traverses any Qpoint-managed systems (when using your own object store).

Data Types: The Golden Rule

Qpoint distinguishes between two types of data to ensure security and privacy:

  • Events (Anonymized Metadata): High-level, non-sensitive information about a connection (e.g., source/destination IP, process name, status codes, timing). Where these go depends on your deployment mode.

  • Objects (Sensitive Payloads): The actual content of your traffic (e.g., API request/response bodies, headers). These always go to your S3-compatible object store (or optionally Qplane's managed store for preview/testing).

Choose Your Deployment Mode

Qpoint offers two deployment approaches with different tradeoffs:

Feature
Cloud-Managed (Qplane)
Self-Managed (YAML)

Event Storage

app.qpoint.io

stdout/logs only*

Object Storage

Your S3 or Qplane managed

Your S3 required

Dashboards

Yes

No

Alerting

Yes

No

Configuration

Web UI + API**

YAML files

Agent Updates

Manual

Manual

Best For

Teams, multi-environment

Air-gapped, IaC workflows

*Self-hosted Pulse/ClickHouse infrastructure support coming in future release.

** API coming soon

Cloud-Managed (with Qplane)

Connect Qtap agents (data plane) to Qplane (control plane at app.qpoint.io) for centralized management and analytics.

When to Use:

  • Multi-environment deployments

  • Teams needing shared visibility

  • Organizations wanting managed analytics infrastructure

Learn More: Cloud-Managed Architecture Details

Self-Managed (YAML Only)

Run Qtap standalone with local YAML configuration files.

When to Use:

  • Strict data residency requirements

  • Air-gapped or isolated environments

  • Infrastructure-as-code workflows

  • Single-server or simple deployments

Learn More: Self-Managed Architecture Details


Quick Start

Ready to get started? Choose your path:

Cloud-Managed:

Self-Managed:

  • How It Works - eBPF and TLS visibility technology

  • Use Cases - Real-world applications of this architecture

Last updated