> For the complete documentation index, see [llms.txt](https://docs.qpoint.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.qpoint.io/readme/architecture-overview.md).

# 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 sensor that captures network traffic
* **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 sensor that you install on your Linux 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 sensors (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](/readme/architecture-overview/architecture-qplane.md)

### 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](/readme/architecture-overview/architecture-qtap-yaml.md)

***

## Quick Start

Ready to get started? Choose your path:

**Cloud-Managed:**

* [POC Kick Off Guide](/guides/qplane-guides/poc-kick-off-guide.md) - Deploy with Qplane in 10 minutes

**Self-Managed:**

* [Complete Guide](/guides/qtap-guides/getting-started/getting-started-complete-guide.md) - Progressive YAML tutorial (4 levels, 50 minutes)

## Related Documentation

* [How It Works](/readme/how-it-works.md) - eBPF and TLS visibility technology
* [Use Cases](/readme/use-cases.md) - Real-world applications of this architecture