Signed site configs
Ed25519-signed configs for every registered site, locked to their allowlisted domains. Extending the allowlist — staging, subdomains, alternate domains — is a one-command change we hand over.
Deployment
Five steps,
together.
There is no self-serve install to figure out. Observer is deployed in one guided session — our engineers alongside your DevOps team, on your hardware. Source access follows NDA and licensing; the deployment itself is deliberately short.
The onboarding session
One shared terminal, your hardware.
Every step below is executed jointly: we drive, your DevOps team approves, watches and learns the runbooks as they are written.
1
Provision
ClickHouse 24.8, the collector, and the API/dashboard go onto your VPS — or onto yours plus a staging box of ours. Docker Compose for the turnkey path, or bare Node 22 processes under systemd. We size the box with your DevOps and start the services together.
2
Keys & first site
We generate the Ed25519-signed site configs and register your first site — domain-locked to its allowlisted domains. The admin user is created, and TOTP two-factor is switched on together, live in the call.
3
Schema & data
The ClickHouse schema is applied with TTLs enforced at the storage level: raw events 24 hours, rollups 25 months, recordings 30 days. Then 14 days of golden demo data are seeded, so every screen is alive before your first real visitor arrives.
4
DNS & TLS
Your side adds one A record pointing at the server. TLS is set up with your DevOps, and the snippet is domain-locked to your allowlisted domains — the same code pasted on any other site is refused at the collector with a 403.
5
Verify
Your first page view flips the add-website wizard green with a running view count. Then the 6-spec browser privacy suite runs against YOUR deployment — no cookies, zero storage, PII scrubbed end-to-end — and the report is delivered to your DevOps.
Steps 1–3 are usually one session; DNS propagation (step 4) is the only part with waiting built in. The demo data in step 3 is clearly labeled and removable the moment your real traffic starts.
What reaches you in writing
Two lines. That is the whole surface.
Before onboarding, the only Observer code that ever touches your systems is generic: the datastore container your DevOps may pre-provision, and the one-line snippet your sites carry. Everything beyond these two lines — keys, configs, runbooks — is issued during the session, after NDA.
# step 1 · the datastore — sized and run together with your DevOps docker run -d --name observer-ch -p 127.0.0.1:8124:8123 \ -e CLICKHOUSE_USER=observer \ -e CLICKHOUSE_PASSWORD=******** \ clickhouse/clickhouse-server:24.8 # step 4 · the only line your websites get — domain-locked, async, cookie-less <script async src="https://sa.yourdomain.com/v.js" data-site="obs_XXXX"></script>
Credentials are chosen with your DevOps during the session and never appear in documentation. ClickHouse binds to localhost by default; the collector (:8090) and API/dashboard (:8081) are the only listeners your sites and team need to reach.
After the session
The access package, after NDA.
Keys, roles, runbooks
Site tokens, API keys with scopes, RBAC roles for owner · admin · analyst · viewer — plus the operations runbooks written during the session. All stored on your hardware.
The joint operation line
A direct channel to the engineers who ran your deploy: monitoring shared, upgrades scheduled as config swaps, the privacy suite re-run at every upgrade.
Five steps.
Zero homework.
Bring a VPS and a DevOps engineer. We bring the stack, the keys, the schema and the verification — and the whole thing is alive in one session.