EventCatalog

Open-source documentation for event-driven architectures, honestly reviewed. No marketing fluff, just what you get when you deploy it.

TL;DR

• What it is: Open-source (MIT) architecture catalog for distributed systems — a searchable, visual, AI-queryable hub for documenting events, services, schemas, domains, and how they all connect [README][website].
• Who it’s for: Engineering teams and architects at companies running microservices or event-driven systems who are tired of architecture knowledge scattered across Confluence, Notion, outdated Miro boards, and Slack threads [website].
• Cost: The core tool is MIT-licensed and free to self-host. EventCatalog Studio, a visual design companion, is a separate commercial product in active development [4][README].
• Key strength: The only open-source tool that combines markdown-based architecture documentation, interactive node-graph visualization, schema browsing across AsyncAPI/OpenAPI/Protobuf/Avro, and an MCP server for AI-native discovery — all from a single catalog [README][3].
• Key weakness: It’s a documentation and discovery tool, not a governance enforcement layer. Your catalog is only as accurate as the people maintaining it. Early-stage bootstrapped project with one primary maintainer (David Boyne), so long-term sustainability is a legitimate question [1].

---

What is EventCatalog

EventCatalog is a static-site generator and catalog application for event-driven architectures. You describe your services, events, commands, queries, domains, and schemas in markdown and YAML files, commit them to git, run one command, and get a browsable website your entire team can use to navigate your system [README].

The pitch on the homepage captures the actual problem well: “Knowledge lives across Confluence, Notion, Slack, and people’s heads. New engineers spend weeks piecing together what should be obvious. Eventually, teams stop trusting documentation at all.” [website]. That’s the real competitive context — not other tools, but the default state of most organizations, which is architecture knowledge trapped in scattered, half-maintained artifacts.

The project was created by David Boyne. In 2024, he left AWS to work on it full-time. By November 2024 he went fully bootstrapped [1]. The README cites 69 contributors and reports “31,000+ catalogs created” — which suggests meaningful real-world adoption even if the GitHub star count (around 2,600 in our merged profile) is modest relative to the usage number [README].

The tech stack is Astro + React for the catalog application, with a Node.js SDK for programmatic management and a CLI scaffolding tool (npx @eventcatalog/create-eventcatalog@latest my-catalog) that gets you running in seconds [README].

---

Why people choose it

The IcePanel team published one of the cleaner early reviews, and the framing holds up: EventCatalog fills the gap between event storming workshops and production reality [2]. Event storming and event modeling help teams design systems collaboratively. EventCatalog gives those design artifacts a home that stays alive alongside the code, checked into git, versioned with the same discipline as everything else [2].

The MCP angle is newer and arguably the most interesting development. The Skywork analysis [3] documents the EventCatalog MCP server, which exposes your catalog to any AI tool — Claude Desktop, Cursor, Windsurf, or custom agents. The practical payoff: instead of grepping through wikis to answer “what services consume the OrderPlacedEvent and what schema version are they on?”, you ask your IDE and get a structured answer pulled directly from your catalog [3]. For teams already using AI-assisted development, this is a genuine workflow change, not a feature demo.

The bootstrapper perspective from David Boyne’s own writing [1] is also useful context: he talks about talking to one or two users every week, tracking problems in Notion, and using real user pain to drive the roadmap rather than building in the dark. That approach is visible in the product — the catalog is narrowly focused on the problems it actually solves (discoverability, ownership, schema navigation) rather than trying to be an all-in-one platform.

What comes through consistently: teams adopt EventCatalog because the alternatives are worse. Confluence gets stale and nobody updates it. Miro boards have no owner. Slack threads disappear. EventCatalog’s git-native approach puts documentation in the same review process as code, which at least gives it a fighting chance of staying accurate [2][website].

---

Features

Core catalog:

• Documents domains, services, events, commands, queries, schemas, teams, channels, workflows, and ubiquitous language in one place [website][README]
• Everything lives in markdown and YAML files in git — version controlled, reviewable in PRs, diffable [website]
• Full semantic versioning for events, commands, and services [README]
• Ownership assignment per domain, service, and event [2]

Visualization:

• Interactive node graphs mapping services, events, and how they connect — generated from your documentation, not drawn by hand [README][website]
• Business flow documentation — end-to-end workflow stories that reference existing services and messages [README]
• Architecture diagrams that update when your documentation updates [website]

Schema management:

• Schema explorer across OpenAPI, AsyncAPI, Protobuf, JSON Schema, and Avro [README]
• Schema field search — find any property across your entire catalog and see where it’s used [README]
• Pull schemas from registries; when schemas change, generated docs update automatically [website]
• One command (npm run generate) refreshes everything, runnable in CI/CD [website]

Generators (15+):

• Auto-generate catalog content from AsyncAPI, OpenAPI, Kafka, Confluent, AWS EventBridge, RabbitMQ, and more [README]
• SDK and API support for integrating with any system in your stack [website]

AI and MCP:

• Built-in AI chat for natural language questions about your architecture [README][website]
• MCP server exposing your catalog to Claude Desktop, Cursor, Windsurf, and any MCP-compatible tool [3][README]
• The MCP integration enables AI tools to answer schema questions, trace service dependencies, and generate flow diagrams in-editor [3]

Enterprise features:

• OAuth2, RBAC, schema governance, and breaking change detection listed in the README [README]
• SSO listed as a canonical feature in the merged profile [merged profile]
• EventCatalog Studio (separate commercial product) adds visual diagramming, import/export, AI architecture assistant, GitHub integration, and design versioning — roadmap items are in progress as of this writing [4]

---

Pricing: SaaS vs self-hosted math

This is where the data gets thin, so honesty matters more than completeness.

Core EventCatalog: MIT licensed, free to self-host. Pricing data not available — there is no listed paid tier for the base catalog application. The business model appears to be built around EventCatalog Studio, a commercial design and collaboration tool [4].

EventCatalog Studio: Separate product, currently in active development. The roadmap [4] lists features like visual architecture design, AsyncAPI/OpenAPI import/export, GitHub integration, and self-hosting options as in-progress. Pricing for Studio is not published in any of the reviewed sources.

Self-hosting the core catalog: Since EventCatalog generates a static site, hosting costs are minimal. You can serve it from GitHub Pages, Netlify, Vercel, or any static host for free or near-free. There is no database, no queue, no runtime server required for the catalog itself [2][README]. The main cost is engineering time to set it up and keep the documentation maintained.

What you’d be replacing: The typical alternative isn’t a paid tool — it’s Confluence ($5.75–$11/user/month for mid-size teams) or Notion ($8–15/user/month) plus Miro or Lucidchart for diagrams ($8–16/user/month), none of which are designed for this use case. For a 20-person engineering team, that’s potentially $400–$800/month in tooling that still produces stale, disconnected architecture docs. EventCatalog at $0 for the core — plus the time to maintain it — is a different trade-off calculation, not a simple cost comparison.

---

Deployment reality check

The install path is genuinely fast: npx @eventcatalog/create-eventcatalog@latest my-catalog, open localhost:3000, start writing [README]. For a developer, the first 30 minutes are not the problem.

The real deployment question is: where does the catalog live and how do you keep it updated? Three patterns work in practice:

1. Static site with CI/CD: Commit catalog to git, run npm run generate in your pipeline, deploy to any static host. Zero ongoing server cost, automatic on every push [website][README].
2. Self-hosted with generators: Point EventCatalog generators at your Kafka cluster, EventBridge, or AsyncAPI specs and let them refresh content on a schedule. Requires your catalog repository to have access to your event bus [website][README].
3. Manual with git discipline: Teams document changes as part of their PR process. Works if your review culture enforces it; falls apart if it doesn’t.

The gap that matters: EventCatalog documents what you tell it. It doesn’t crawl your codebase and auto-discover services. The 15+ generators help if you already use AsyncAPI or OpenAPI specs — they generate catalog entries from existing specs automatically [README][website]. But if your architecture lives only in code and tribal knowledge, you’re starting from a blank catalog and need to invest the documentation effort upfront.

David Boyne’s bootstrapper post [1] is worth reading for setup philosophy: he’s explicit that he talks to users weekly and ships only things users actually ask for. That’s reassuring for a small project — the roadmap is user-driven, not feature-count-driven.

EventCatalog Studio’s roadmap [4] mentions self-hosting Docker and Kubernetes configurations as in-progress, which suggests the commercial product will eventually be self-hostable too — important for enterprise buyers who can’t send architecture data to a SaaS.

---

Pros and cons

Pros

• Actually MIT-licensed. The core catalog is genuinely open source with no commercial restrictions. You can self-host, fork, embed in internal tooling, or contribute [README].
• Git-native documentation. Architecture docs live in the same repository as code, get reviewed in PRs, and are versioned with the same tooling your team already uses [2][website].
• MCP server is genuinely useful. Not a gimmick — exposing your architecture catalog to AI tools in your IDE changes how developers answer “what consumes this event?” questions [3].
• Schema coverage is broad. OpenAPI, AsyncAPI, Protobuf, JSON Schema, Avro — the schema explorer works across formats [README].
• 15+ generators prevent doc rot. If you already maintain AsyncAPI or OpenAPI specs, generators keep the catalog in sync automatically rather than requiring manual updates [README][website].
• Fast to try. One npx command, no database, no server to configure — you have a working catalog in minutes [README].
• Active solo founder with user focus. David Boyne is shipping, talking to users weekly, and documenting his process publicly [1]. The project isn’t abandoned.

Cons

• Single primary maintainer. For a tool you’re betting your architecture documentation on, a bootstrapped solo project is a real sustainability risk [1]. The 69 contributors help, but governance depth matters for long-term adoption.
• Documentation is only as good as your discipline. No automated discovery from code. If your team doesn’t maintain the catalog during development, it drifts — same as every other documentation approach.
• Generators require spec discipline. The auto-generation features only work if you already have AsyncAPI, OpenAPI, or similar specs. Many teams don’t [2].
• Pricing for commercial features is unclear. EventCatalog Studio, where enterprise features like visual design, AI assistant, and GitHub integration live, has no published pricing [4]. You can’t plan a budget.
• Studio self-hosting is still in progress. If you need the commercial features on-premise, you’re waiting on the roadmap [4].
• Not a governance enforcement tool. EventCatalog can document a breaking change policy; it cannot prevent a team from shipping a breaking change. Schema governance listed as a feature requires team discipline to actually enforce [README].
• Relatively small GitHub community. 2,600 stars is modest compared to documentation tools like Backstage (50K+). Fewer community answers when things break [merged profile].

---

Who should use this / who shouldn’t

Use EventCatalog if:

• You’re running microservices or an event-driven architecture and engineers can’t answer “what produces this event?” without asking in Slack.
• Your team already uses AsyncAPI or OpenAPI specs and wants documentation to derive from them automatically rather than being maintained separately.
• You want architecture knowledge in git — reviewable, versioned, diffable — instead of Confluence pages that go stale.
• You’re using Claude Desktop, Cursor, or any MCP-capable AI tool and want your architecture catalog accessible directly from your IDE.
• You need a free, self-hostable starting point and are willing to invest the upfront time to document your system.

Skip it (keep Confluence/Notion for now) if:

• Your team has fewer than three services and a single engineer who knows everything — the overhead of maintaining a catalog isn’t justified.
• You need your documentation vendor to have an enterprise support contract and SLA. A bootstrapped open-source project can’t offer that today.
• You’re looking for a tool that auto-discovers your architecture from code without manual documentation effort.

Watch EventCatalog Studio before committing if:

• You need visual collaborative design alongside the catalog — Studio is building toward that but pricing and availability aren’t finalized [4].
• You’re an enterprise with strict on-premise requirements — self-hosting for Studio is on the roadmap but not shipped yet [4].

---

Alternatives worth considering

• Backstage (Spotify) — the largest open-source developer portal. Much broader scope (software catalog, scaffolding, plugins), much higher deployment complexity. If EventCatalog is a documentation tool, Backstage is a platform — bigger investment, bigger payoff for large orgs.
• AsyncAPI Studio — browser-based editor specifically for AsyncAPI specs. Narrower than EventCatalog (AsyncAPI only, no multi-protocol catalog) but tighter integration if your whole team works in AsyncAPI.
• Apicurio Registry — schema registry focused on governance and validation rather than documentation and discovery. Complementary to EventCatalog rather than competing.
• IcePanel — the IcePanel team wrote one of the better EventCatalog explainers [2], and IcePanel itself is a commercial C4 model diagramming tool. Different angle: IcePanel is visualization-first, EventCatalog is documentation-first.
• Confluence + Miro — the default fallback. Gets the job done with tools teams already have, but produces the exact “Confluence updated 2 years ago / Miro Board Owner: ???” problem EventCatalog exists to solve [website].

---

Bottom line

EventCatalog solves a real problem — distributed architecture knowledge is genuinely hard to maintain, and the default answer (scattered wikis and tribal knowledge) reliably fails at scale. The git-native approach, broad schema support, 15+ generators, and MCP server integration make it the most purpose-built open-source tool for event-driven architecture documentation available today. The honest caveats: it’s a single bootstrapped maintainer, the commercial product (Studio) is mid-development with unpublished pricing, and the catalog is only as useful as the team’s discipline in maintaining it. For an engineering team that already has AsyncAPI or OpenAPI specs and wants AI tools to understand their architecture, the investment to try it is almost nothing — one npx command and thirty minutes. For teams considering it as a long-term documentation platform, the sustainability question around a solo bootstrapped project deserves a frank internal conversation before committing.

---

Sources

1. David Boyne — “10 Lessons from 6 Months of Bootstrapping My Open Source Startup” (May 2, 2025). https://boyney123.substack.com/p/10-lessons-from-6-months-of-bootstrapping
2. IcePanel — “Document service events with EventCatalog” (May 3, 2023). https://icepanel.medium.com/document-service-events-with-eventcatalog-4e55d3c2d4b5
3. Skywork AI — “Unlocking Your Architecture: A Deep Dive into the EventCatalog MCP Server” (October 27, 2025). https://skywork.ai/skypage/en/unlocking-architecture-eventcatalog-mcp-server/1981238542433746944
4. EventCatalog Studio — Product Roadmap. https://www.eventcatalog.studio/roadmap

Primary sources:

• GitHub repository and README: https://github.com/event-catalog/eventcatalog (MIT license, 69+ contributors)
• Official website: https://eventcatalog.dev
• Live demo: https://demo.eventcatalog.dev