Skip to content
Taavik
Open app
Architecture

Three pieces. One job each.

An on-premise agent scans the database and runs queries. A cloud control plane coordinates, holds the documentation, and dispatches scheduled exports. A browser workspace reads and authors. Credentials stay local; query results cross the boundary only when you explicitly run or schedule them.

Start documenting your database See the security model

01 · The split

Why three pieces, not one.

Cloud catalog tools are convenient but require shipping credentials and rows to a vendor. Self-hosted catalogs stay private but force you to operate yet another stack. Taavik splits the responsibility so each piece does one thing.

  • ·The agent is on premise because the database is on premise.
  • ·The cloud is small because the cloud only coordinates.
  • ·The workspace is read-only because the workspace is for humans.
01 · Agent on-prem

Runs where the database is.

  • ·Windows service, Linux systemd, or Docker container.
  • ·Holds the real connection string locally; opens it only to scan or run a query.
  • ·Outbound TLS to the control plane, no inbound ports.
  • ·Performs read-only metadata scans for documentation.
  • ·Executes ad hoc queries and scheduled exports under a read-only role.
02 · Control plane cloud

Coordinates. Documents. Delivers.

  • ·Owns agent inventory, sealed connection envelopes, and run state.
  • ·Stores the auto-generated Markdown documentation, manual notes, and change history.
  • ·Schedules exports and dispatches them to Slack and email.
  • ·Tracks query runs, status, and audit metadata.
  • ·Never sees a database password; handles explicit query and export results only when you ask it to.
03 · Workspace browser

Reads. Authors. Schedules.

  • ·Read the auto-generated documentation, add manual notes, browse change history.
  • ·Author and run saved queries with variables under team scope.
  • ·Configure schedules, pick CSV or Excel, route to Slack or email.
  • ·Inspect run history and audit log.

02 · The scan flow, end to end

From enrollment to documentation.

Each step is a step you can audit. The agent never receives arbitrary SQL from the cloud. The cloud never receives a password. The catalog feeds the documentation; the documentation is the surface humans read.

  1. Step 01

    Enroll the agent

    Generate an enrollment code in the workspace. Run the agent on a host that can reach the database. The agent registers, gets its keypair, opens an outbound TLS channel.

  2. Step 02

    Seal the credentials

    In the browser, you type the database connection details. The browser seals them with the agent public key (X25519 sealed-box) and posts the envelope. Only the agent can open it, locally.

  3. Step 03

    Scan

    The agent acquires a scan lease, opens a read-only connection, queries information schema, builds the snapshot, and uploads it.

  4. Step 04

    Generate documentation

    The cloud diffs the snapshot against the previous one, refreshes the Markdown documentation in place, preserves your manual notes, appends entries to the change history.

  5. Step 05

    Notify

    An in-app notification surfaces the documentation update. If you opted in to alerts, Slack or email receives a digest of the changes.

Scan flow diagram from enrollment to documentation update

03 · The query and schedule flow

From saved query to recurring delivery.

A saved query is a recipe. A schedule is the calendar that triggers the recipe. The agent does the cooking, with read-oriented guardrails and a timeout. The cloud routes the result link to Slack or email.

Query and scheduled export flow from browser through cloud to agent and out to Slack or email
  1. Step 01

    Render and validate

    The cloud renders {{variables}} with the values for this run, validates the statement, creates a run row in Queued state, enforces plan caps.

  2. Step 02

    Dispatch to the agent

    A lifecycle worker picks the agent, sends an Execute command. The agent registers the run against per-agent and per-connection concurrency caps.

  3. Step 03

    Run with guardrails

    The agent runs the validated statement with a timeout, streams the result in chunks back to the cloud, and the cloud validates hashes while progress updates.

  4. Step 04

    Format and deliver

    For ad hoc runs, the browser renders the result. For scheduled exports, the agent formats the file as CSV or Excel, uploads it, and the cloud delivers a secure download link to Slack or email.

  5. Step 05

    Audit

    The run row records the rendered SQL, the variable values, who triggered it, the connection, the row count, the duration, the truncation flag, the delivery outcome.

04 · What never leaves the network

An honest list.

Stays inside your network

  • ·Database passwords and full connection strings.
  • ·Row data when not part of an explicit query result you authored.
  • ·Read-only diagnostic queries before they execute.
  • ·The decryption private key paired with the sealed envelope.

Crosses to the cloud

  • ·The technical catalog: schemas, tables, columns, indexes, views, routines.
  • ·The Markdown documentation and your manual notes.
  • ·Heartbeats and run state.
  • ·Results of queries you explicitly chose to run, capped per plan, audited.
Set it up

Connect your first database server in under ten minutes.

Generate the enrollment code, run the agent, seal the credentials, get the first scan, open the documentation.

Start documenting your database See the security model