Platform Architecture

You don't need to understand CloudPeek's internals to use it, but a mental model helps, especially when deciding how to deploy it or how the API fits in. This page gives the high-level picture without the deep engineering detail.

The big picture

CloudPeek has four moving parts that work together:

1. The web app: what you click on in the browser.
2. The API: the service the web app (and your own scripts) talk to.
3. The background workers: the always-on automation that triages alerts and runs follow-ups.
4. The AI engine: the reasoning layer that powers triage, investigations and the Wiki.

Around those sit the connected tools (your security products) and a set of data stores that hold incidents, knowledge, files and search indexes.

The web app (frontend)

The browser application is where analysts work: the dashboard, investigations, incidents, the Wiki, settings. It's a single-page web app that talks to the API for everything. Every screen you'll read about in the Using CloudPeek section is part of this app.

The API

The API is the front door to everything CloudPeek can do. The web app uses it under the hood, and you can call it directly from your own scripts or automation. It handles authentication (who you are), authorisation (what you're allowed to do), and tenant isolation (making sure you only ever see your own organisation's data). The full developer reference is the API Reference section.

The background workers

Workers are separate, always-on processes that do the heavy lifting nobody should have to wait for: polling your tools for new alerts, running each alert through triage, executing follow-up actions, hunting for patterns across incidents, and updating the Wiki. They run on a schedule and pull work from queues. See Background Workers for the details.

The AI engine

CloudPeek's intelligence comes from large language models (LLMs). You choose which provider and model to use in Settings → Model Providers, and each tenant can pick its own. The AI engine is used in three main places: triage (analysing alerts), investigations (the chat agent that gathers evidence), and the Wiki "Ask CloudPeek" panel.

Crucially, the AI can be pointed at a model running inside your own environment, which is what makes air-gapped operation possible, there's no requirement to call an external cloud service.

Connected tools

Tools are how CloudPeek reaches your security stack. Each connection stores encrypted credentials and exposes a set of actions the AI can use (search logs, look up an IP, list findings). The AI never has hidden access, it can only use the tools you've connected and, under HITL, only with the autonomy you've granted.

Data stores (at a glance)

CloudPeek keeps different kinds of data in stores suited to each:

• A primary database for incidents, investigations, tools, users and audit records.
• A search/vector store so artifacts and knowledge can be found by meaning, not just keywords.
• A knowledge graph of entities and how they relate (used by the Wiki).
• A queue that coordinates the background workers.

You don't interact with these directly, they're mentioned so the rest of the docs make sense.

Tenant isolation & auditability

Two architectural properties matter for high-consequence environments:

• Tenant isolation: every record belongs to exactly one tenant and is filtered at the database level, so one organisation's data can never leak into another's. This is enforced per request, not just in application code.
• Auditability: every meaningful action, by a person or an AI agent, is recorded with a timestamp and an attributed actor, and is reviewable in Audit Logs.

Where to go next

• Deployment Options: how all this runs in cloud, on-prem or air-gapped setups.
• Background Workers: the automation layer in depth.
• API Overview: talk to the API yourself.