Estate

What it is

When an alert fires, its metrics, logs, recent deployments, owner and runbook may live in different systems. Estate reads those systems and brings the information together by service, with links back to the source tools.

It is an operations application, not a JVM dependency. It can watch services written with any stack. A service catalogue describes the services and their relationships; adapters read the monitoring and deployment systems you already run.

It fits a mixed-tool environment where investigating a service means visiting several dashboards. If one existing platform already gives you that view, start there.

Install

Estate runs as a container or from its TypeScript source with Bun. The documented container is ghcr.io/matthewjones372/estate:main, a moving development tag. The example configuration is in the repository, so clone it before mounting examples/.

git clone https://github.com/matthewjones372/estate.git
cd estate
docker run --rm -p 8080:8080 \
  -v "$PWD/examples:/etc/estate" \
  ghcr.io/matthewjones372/estate:main

Open http://localhost:8080. The default example points at unavailable tools; connection errors are expected until you configure your own sources. For a populated first screen, use the self-contained demo below.

A populated first example

The source demo runs Estate against simulated source systems. It gives you services, alerts and deployments to explore without connecting any accounts.

bun install
bun examples/demo/run.ts

Open http://localhost:8080. The scenario is a fictional online grocer with unhealthy production dependencies. Its AI answers are canned and labelled. This demonstrates the UI and data relationships, not an observation of a real incident.

Connect the tools you have

catalog.yaml describes services, environments, owners, stores, jobs and the signals to show for them. estate.yaml names the source systems, authentication and storage settings. The separation lets a service catalogue live in Git without hard-coding credentials into it.

Petshop’s settings connect Prometheus, Alertmanager, Loki and Tempo. Its catalogue names the HTTP service and browser application, the Postgres and Kafka stores, metrics queries and the adoption journey.

sources:
  demo:
    prometheus: { url: http://prometheus:9090 }
    alertmanager: { url: http://alertmanager:9093 }
    loki: { url: http://loki:3100 }
    tempo: { url: http://tempo:3200 }

Estate can read other combinations, including Datadog, CloudWatch, Kubernetes and different deployment tools. Use the real-tool configuration guide for supported adapters and their settings. The doctor command checks source connectivity and reports mismatches.

Read-only operation is configurable. Notes, silences and debug controls have their own storage and permission requirements; enable the actions your operators actually need. AI assistance and the read-only MCP interface are optional.

Where Petshop uses it

The local Compose stack runs Estate at http://localhost:8095. It shows the shop’s alerts, JVM and connection-pool metrics, outbox backlog, Kafka lag and trace journeys. The monitoring data comes from the demo’s running services.

The demo simulates Kubernetes, Argo CD and build-history responses with demo/tools/fake.ts. Those release and pod displays are examples, not evidence that the local shop was deployed through Kubernetes. The hosted fake shop at demo.surefold.dev does not expose this local operations stack.

Run the Petshop operations demo · Read its service catalogue · Compose configuration

Limits and where next

Estate depends on the source data and queries you configure. It reads operational data from the connected tools rather than replacing their telemetry stores; its own notes and alert history can be stored separately. Missing or stale source data needs to remain visible when interpreting the page.

The Petshop configuration grants anonymous visitors an operator role for a local demonstration. Use the project’s authentication and deployment guidance for a real installation.