# 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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.qpoint.io/readme/architecture-overview.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.