Goliash: What's Deployed Where, Across Every Orchestrator

I run a lot of services across a lot of environments. ECS clusters in staging and production. Nomad jobs on bare metal. Docker Swarm on some older infrastructure. Kubernetes where the team insisted. Each environment has its own version of each service deployed. Some have drifted. Some are behind on releases. Some I honestly don't know — I check deployment logs, container tags, ECS task definitions, Nomad job specs, and Kubernetes deployments manually, in different tools, across different clusters.

I got tired of that. So I'm building Goliash.

What Goliash is

Goliash (goliash.dev) is a universal tracker of deployed service versions. The core question it answers: what is running where, at which version, in which environment — and whether that matches what it should be.

Three things in one view:

• What version of each service is deployed in each environment right now
• Whether a new release is available upstream (GitHub, container registries, package feeds)
• Whether environments have drifted from each other or from a desired state

Notifications when something changes — a new release drops, a service falls behind, a deployment happens, drift is detected.

The problem it solves

The information exists. It's scattered. ECS task definitions, Nomad job specs, Kubernetes deployments, Docker Swarm service inspect outputs — every orchestrator exposes running versions differently, in different APIs, with different data models. Aggregating this into a single view currently means writing your own scripts, building your own dashboards, or accepting that you won't have a clean picture of your fleet.

For a single orchestrator, purpose-built tools exist (ArgoCD for Kubernetes, Portainer for Docker). For a mixed fleet — ECS in production, Nomad on bare metal, Docker Swarm on legacy infrastructure — there's nothing that aggregates across all of them into one consistent view. That's the gap Goliash fills.

Platform support

Goliash is built for heterogeneous infrastructure. Supported orchestrators and runtimes:

• Amazon ECS — task definitions, services, running task versions per cluster
• HashiCorp Nomad — job specifications, running allocations, version per job per namespace
• Docker Swarm — service inspect, image tags, replica state
• Kubernetes — deployments, daemonsets, statefulsets, image versions per namespace
• Docker Compose and bare Docker hosts — containers and image tags from any host

The goal is a unified data model across all of them: every service has a name, an environment, a running version, and a desired version. The orchestrator is an implementation detail underneath.

Upstream awareness and drift

Knowing what's deployed is half the problem. The other half is knowing what's available. Goliash pulls release information from Docker Hub, GHCR, Quay, ECR, and private registries, compared against semver policies per service. Release dates and notes pulled from GitHub via a built-in catalog or the image's own source label.

Drift detection compares versions across environments. Staging on 1.5.0 while prod is still on 1.3.2 — shown immediately without checking both manually. End-of-life tracking flags services on release cycles that have reached EOL.

Architecture

The agent runs next to what it watches and sends full snapshots to the server via HTTPS — read-only, connects out, never needs inbound access. An outage loses nothing because each snapshot is complete. The server turns snapshots into history, maps containers to services, compares with upstream releases, and notifies you. It can also collect from what it reaches directly, without an agent.

One binary for the agent, one for the server. SQLite by default, PostgreSQL for larger deployments. Signed releases.

MCP server

Goliash has a built-in MCP server. Claude, Cursor, and any MCP-compatible assistant can answer questions like "what runs in prod?" or "what changed in the last two hours?" directly from live deployment data, scoped to an API token's permissions.

Notifications

Slack, Discord, Telegram, ntfy, signed webhooks, and email. Instant or as daily/weekly digests. Acknowledgements to silence a notification once you've seen it.

Install

Helm, Docker Compose, Docker Swarm, Nomad, and ECS deployment options. See goliash.dev/install for the full install guide.

Multi-tenant

A single Goliash deployment can track infrastructure across multiple teams, organizations, or accounts. Each tenant sees only their own services and environments. Useful for agencies managing multiple client environments, or platform teams serving multiple internal product teams.

Status

Goliash is live at goliash.dev with docs, install instructions, and a getting-started guide. The GitHub repo is at github.com/pipozzz/goliash. OSS-first — self-hosted before any cloud offering.

If you're running mixed orchestrator infrastructure and the "what's deployed where" problem resonates, try it and let me know how it fits your fleet. Which integrations matter, what the matrix should show for your setup, what notifications are actually useful vs noise.