Coming soon · building in public

Your service estate, mapped by itself.

Cartogra discovers every service you run from GitHub, Azure DevOps and Kubernetes, keeps ownership current, and turns the dependency graph into answers: what breaks if this goes down, who to call, and whether this API change is safe to ship.

Follow the build → See what works today

No waitlist yet. The catalog, discovery and ownership layers are running; the graph is being built now.

3Discovery sources
0Wiki pages to maintain
4Services shipped
6Phases to launch

A1 · What it does today

A catalog nobody has to maintain

Every screen below is the real application. Where a surface is still waiting on its backing service, it says so — this is a product under construction, not a mock-up pretending otherwise.

Services find their own way in

Connect a source once. Cartogra scans repositories, detects the tech stack, reads CODEOWNERS to resolve the owning team, and watches Kubernetes namespaces for workloads nobody registered.

  • Health, criticality tier and deploy recency on every card
  • Unowned services flagged rather than quietly listed
  • Server-side full-text search with team, health and stack filters
/catalog
Service catalog showing twenty discovered services with health, tier and tech stack

Plate 01 Service catalog Working

One page an on-call engineer can act from

Owner, tier, SLA target, repository provenance, last commit, last deploy and a rolling health history built from scheduled probes — plus the dependencies and contracts that make a change risky.

  • Risk score summarising health, ownership and criticality
  • Probe history so "it broke this morning" has evidence
  • Edit in place, with team membership checked on every write
/catalog/payments-api
Service detail page for payments-api with risk score, tech stack and health history

Plate 02 Service profile Working

Ownership that survives a reorg

Teams own services; membership is checked live on every mutating request instead of being baked into a token, so removing someone takes effect on their next click. Automatic CODEOWNERS resolution proposes the owner — a human override always wins.

/teams
Teams page listing five teams with their owned services and members

Plate 03 Teams and ownership Working

Integrations that do the harvesting

GitHub and Azure DevOps sync on a schedule and on webhook push, with provider signature verification. A Kubernetes watcher tracks labelled namespaces and derives health from endpoint readiness. OpenTelemetry ingestion is next — it is what turns the declared map into an observed one.

/settings/connections
Connections settings showing GitHub, Azure DevOps and Kubernetes connected

Plate 04 Source connections Working

Risk, surfaced before the incident

Circular dependencies, single points of failure, stale services and unowned systems, ranked by severity with the affected services named. The interface is built; the topology service that computes these findings is the phase in progress right now.

/risks
Risks page listing critical and warning architectural findings

Plate 05 Risk triage Interface ready · engine in build

Fast enough to use mid-incident

⌘K spans pages, services and teams. Light and dark ship from one token set, keyboard navigation covers the core flows, and every error carries the trace ID that finds the exact request in Tempo.

⌘K
Command palette open over the dashboard

Plate 06 Command palette Working

B1 · How it works

Three steps, then it runs itself

The order matters: each step feeds the next, and none of them asks a human to keep a list up to date.

Step 01

Connect a source

A GitHub org, an Azure DevOps project, or a Kubernetes cluster. One credential, stored encrypted, scoped to your tenant.

Step 02

Let it harvest

Repositories are scanned, stacks detected, CODEOWNERS parsed, health endpoints probed. Every finding becomes an event, and the catalog updates itself idempotently.

Step 03

Ask the hard questions

What does this depend on, what breaks if it dies, who owns the blast radius, and is this API change safe. This is the layer being built now.

C1 · Under the hood

Built like something you would run in production

Not a demo stack. Multi-tenant isolation in three layers, event choreography instead of distributed transactions, and a trace ID on every response.

Tenant isolation in depth

tenant_id on every table, every query filtered, PostgreSQL row-level security as a database-level net, and a gateway filter that strips client-supplied tenant headers and re-injects from the validated token.

One response contract

Every endpoint answers with data or a typed error plus the 32-hex OpenTelemetry trace ID, mirrored in the response header and in every log line. A support ticket becomes a trace lookup.

Failure kept local

Circuit breakers per gateway route return a typed 503 instead of a raw proxy error, and breaker state is a health detail that deliberately never fails readiness during a downstream incident.

Java 25Spring Boot 4Spring Data JDBC PostgreSQL + RLSApache KafkaValkey OpenTelemetryVirtual threadsFlyway TanStack Startshadcn/uiTailwind TestcontainersTrivy-gated CI

D1 · Where we are

Honest status

Six phases stand between here and launch. Each one ends in something you could actually use, and the plan is public.

/graph
The dependency graph screen, currently showing its coming-soon placeholder

Plate 07 Dependency graph Next phase

Phase 00

Catalog, discovery, ownership Shipped

Authentication with OAuth and per-tenant OIDC, service and team management, SCM and Kubernetes discovery, health probing, audit-ready history.

Phase 01

See the map In progress

Declared dependencies, a force-directed graph, and nodes projected from registry events so the graph never has to ask another service what exists.

Phase 02

Answer impact questions

Blast radius through recursive queries, cycle detection, single-point-of-failure scoring, and a ranked risk list.

Phase 03

A map that maintains itself

Observed dependencies derived from OpenTelemetry spans, and drift between what teams declared and what actually calls what.

Phase 04

Public demo

A guest-readable demo tenant with a full audit trail, so anyone can try it before talking to anyone.

Phase 05

Change safety

OpenAPI and AsyncAPI contracts, structured diffs, a breaking-change engine, and a CI check that blocks the merge instead of filing a ticket.

Phase 06

Intelligence

Deterministic anti-pattern detection with a narrative layer over the evidence — the model explains findings, it never invents them.

Not open yet

There is nothing to sign up for — yet

Cartogra is being built in the open, one phase at a time, with the plan and the trade-offs written down as they are decided. Watch the repository and you will see the graph land before anyone gets a marketing email about it.

Watch on GitHub → Read the roadmap