LikeC4 for Architecture as Code

Architecture diagrams are useful until they become stale. Platform teams add queues, gateways, databases, workers, and control-plane services every week, but the diagram in the wiki often stops matching production. LikeC4 is trending because it makes the diagram source live beside the system it describes.

The project is inspired by the C4 model and Structurizr DSL, but it gives teams room to define their own notation, element types, relationships, and nested levels. That flexibility matters when your real architecture does not fit a generic template.

What Is LikeC4?

LikeC4 is an open-source modeling language and toolkit for describing software architecture as code. You write *.c4 or *.likec4 files, then use the CLI, editor tooling, React components, Vite plugin, web components, API, or MCP server to visualize and reuse the model.

The operational value is simple. A service map can live in Git, go through pull request review, and update with the same workflow as application code. When a team changes a dependency, adds a new internal API, or moves a database boundary, the architecture model can change in the same branch.

Key Features

• A readable DSL for modeling systems, components, relationships, and custom notation.
• Hot-reload local previews with likec4 serve, likec4 start, or likec4 dev.
• Static website builds for publishing diagrams into internal docs or portals.
• Exports to PNG, JSON, Mermaid, Dot, D2, DrawIO, and other static formats.
• Validation and formatting commands that fit into CI checks.
• MCP server and API access for AI agents that need accurate architecture context.

Installation

LikeC4 requires Node.js 20 or newer. In an npm project, install it as a development dependency:

npm i -D likec4

For a quick preview in a repository with LikeC4 sources, use npx:

npx likec4 start

To make it available globally:

npm install --global likec4
likec4 [command]

Usage For Platform Teams

Start small. Model the systems that matter during incidents: the public entry point, authentication service, control plane, workers, queues, databases, and third-party dependencies.

likec4 serve
likec4 validate
likec4 build -o ./dist

For documentation pipelines, publish the static build from CI. For review workflows, add validation and formatting checks so architecture files do not silently drift.

If your team uses AI assistants for operations, the MCP server is the interesting part:

likec4 mcp --stdio
likec4 mcp --http

That gives agents a structured architecture source instead of forcing them to infer topology from scattered code, manifests, and stale docs.

Operational Tips

Do not try to model everything on day one. Pick the paths that matter for reliability: request routing, alert-critical services, data stores, queues, external APIs, and deployment boundaries.

Keep architecture changes in the same pull request as service changes. Review the diagram diff with the code diff. If a new dependency appears in Kubernetes manifests or Terraform, it should probably appear in the model too.

For incident response, link diagrams from runbooks. A responder should be able to jump from an alert to the relevant system view without searching through an internal wiki.

Conclusion

LikeC4 is useful because it treats architecture as an operational artifact, not a presentation artifact. For SRE teams, a versioned and validated service map can reduce confusion during reviews, incidents, migrations, and onboarding.

If your team wants AI-assisted incident workflows with clear infrastructure context, Akmatori helps SRE teams investigate alerts, coordinate response, and automate safe actions. For reliable global infrastructure, check out Gcore.