OpenMetadata

Column-level lineage, data catalog, glossary. Auto-ingests from Airbyte, dbt, and PostgreSQL to show how data flows end to end.

Tier

Cold. OpenMetadata is a three-container stack (server + Elasticsearch + ingestion) totalling ~6 GB of images and ~3 GB of RAM when running. Stakeholders rarely open it; engineers open it when they need to understand lineage. OrcheStack pulls its images during deploy so first Open from the dashboard is instant, then spins the stack up on demand and stops it when idle.

Role

OpenMetadata pulls metadata from every stage (Airbyte sources, PostgreSQL schemas, dbt models, Metabase dashboards) to produce column-level lineage graphs. It answers the question: "if I change this column, what breaks downstream?"

First start

Even with images pre-pulled, the first start of OpenMetadata takes 5–10 minutes on a typical laptop because:

1. Elasticsearch boots and waits to report healthy (~60–90 s).
2. The OpenMetadata server then runs schema migrations against its application DB on the shared orchestack-postgres (~2–3 min on first install, ~5 s on warm starts).
3. The server starts and waits for ES to index its system catalogue.
4. The openmetadata-ingestion sidecar comes up last (it bundles OpenMetadata's own Airflow for metadata ingestion — distinct from the Apache Airflow service you configured for business DAGs).

While this is happening, the dashboard tile reports Starting. If it sits there beyond 30 minutes, check the audit log for session_autostart_failed events; the orchestrator caps OpenMetadata's start at 1800 s (30 min) before reporting failure.

Signing in

OpenMetadata has its own login screen at /signin. OrcheStack can't auto-sign-in to OpenMetadata in v0.1.x because OpenMetadata is served on a different origin from the OrcheStack dashboard — same-origin restrictions prevent us from writing its session token into your browser. We'll fix this in a later milestone (it requires running OpenMetadata behind a reverse-proxy that rewrites its SPA asset paths, and we've deferred that work to v0.2).

For now, OrcheStack gives you one-click access to the credentials from the dashboard:

1. From the dashboard grid, open OpenMetadata's Details · pin · activity page (link at the bottom of the tile).
2. In the Connection card on the right, click Reveal. Admin email and password appear with Copy buttons next to each.
3. Copy the email → click Open → paste into OpenMetadata's email field. Repeat for password.

Only admins can reveal credentials (the orchestrator enforces this server-side). Every reveal is captured in the audit log.

Configuration

All of these are editable later from Edit config on the OpenMetadata tile.

When to open it

Typical triggers: before a schema change (to check downstream impact), after a pipeline failure (to see which models are affected), during an audit (to document data provenance).

Troubleshooting

"Pulling…" forever on the dashboard, then "Failed to start"

Combined image size is ~6 GB. On residential broadband the default 60-minute pull cap can be exceeded. Check the audit log for service_pull_failed; the underlying images can be pulled manually with docker compose -f services/openmetadata.yml -p orchestack-service-openmetadata pull from the install directory (no orchestrator timeout that way).

Sign-in fails with "invalid credentials"

OpenMetadata 1.6.x validates passwords against its own rules at first-start (min length, no common patterns). If your wizard password was rejected the bootstrap hook auto-generates a strong replacement and writes it to OPENMETADATA_ADMIN_PASSWORD in .env. Use the Reveal flow above to read the actual current password.

Dashboard shows "Stopped" but the OpenMetadata UI still loads

Polling lag — the orchestrator reconciles state every 30 s. The UI you're seeing is the running container; the dashboard will catch up on the next tick.