Surevisible
Self-hosting

Your warehouse, on your own machine

Surevisible runs as a local-first install: SQLite for the control plane, DuckDB for the warehouse, and your credentials never leaving the box.

The problem

Some data cannot leave the building, and for some teams the analytics vendor is the compliance problem rather than the solution.

What we mean

The whole product runs against a local data directory. The control plane is SQLite, the warehouse is DuckDB, and the encryption key is a file with 0600 on it. The syncs are driven by an in-process worker rather than an external cron, so closing the laptop for a week and reopening it backfills the week.

0

database servers to install or operate

How it works

Start to answer

  1. 01

    Install

    One Node process. No database server to run alongside it.

  2. 02

    Point it at a directory

    SUREVISIBLE_DATA_DIR holds the control plane, the warehouse and the master key.

  3. 03

    Authorise Google

    Your own OAuth client, so the consent screen names you rather than us.

  4. 04

    It keeps itself current

    The worker drains the queue whenever the process is running.

Before and after

What actually changes

Data that cannot leave

Before

The analytics project stalls in a security review.

After

It runs on your machine. There is nothing to review.

The laptop that was closed for a week

Before

A local tool with no scheduler comes back with a week-shaped hole.

After

On launch it diffs the watermarks, queues the gaps, and fills them.

No database to run

Two embedded engines, no server processes.

  • SQLite for the control plane
  • DuckDB for the analytical warehouse
  • Everything under one data directory

Your own OAuth client

The Google consent screen names your project.

  • You hold the client id and secret
  • Tokens encrypted with a local key
  • Nothing round-trips through us

Same product

Not a cut-down edition.

  • The full metric schema
  • Chat, charts, dashboards and export
  • The MCP server included

Why an in-process worker

A desktop install has no cron. So on every launch the scheduler compares each dataset's watermark against what should exist by now, queues the difference, and the worker drains it. That is the local-first answer to 'who runs the syncs': the app itself, whenever it happens to be running.

In short

The product works the same way whether the warehouse is ours or yours.

See the whole brand

Search, analytics, ads, revenue, CRM and support, pulled into one view per brand and kept current. Connect the first source in a few minutes.