Architecture Diagrammer

Architecture Diagrammer

Create C4 model architecture diagrams. Design system context, container, component diagrams visually. Export to PNG/SVG. Free software architecture tool

A system architecture diagram answers "what are the moving parts and how do they connect" at the level appropriate to the audience. The C4 model (Context, Container, Component, Code) is the most-cited modern framework for this — start with one page showing your system among external systems, then zoom in. This diagrammer builds C4-style architecture diagrams with proper notation, AWS/Azure/GCP service icons where appropriate, and exports to PNG/SVG and as Structurizr DSL or PlantUML-C4 for version control.

The four C4 levels and what each shows

  • Level 1 — System Context. Your system as a box, surrounded by external actors (users, other systems). Single page. Audience: everyone, including non-technical.
  • Level 2 — Container. Inside your system: web app, mobile app, API server, database, message queue. Audience: technical, but not deeply familiar with the code.
  • Level 3 — Component. Inside one container: modules / services / classes that make up the container. Audience: developers actively working on this container.
  • Level 4 — Code. UML class diagrams or similar at the code level. Audience: developers; rarely produced in 2026 (UML class diagrams are not in fashion).

Most teams produce Level 1 + Level 2 for new systems and stop there. Level 3 is created on demand for areas being heavily modified. Level 4 is essentially documentation of code that the IDE already shows.

Working example: a SaaS app at Container level

Input

A SaaS web application: React frontend, Node.js API, PostgreSQL, Redis, S3, Stripe integration

Output

External actors:
  - User (web browser)
  - Admin (web browser)

Our system (Container level):
  - Web App [React SPA]
      Served from CDN. Talks to API over HTTPS.
  - API Server [Node.js, Express]
      Stateless. Behind ALB. Connects to DB, Redis, S3, Stripe.
  - Database [PostgreSQL 16]
      Primary + read replica. Stores users, orders, sessions.
  - Cache [Redis 7]
      Session store + computed results cache.
  - File Storage [AWS S3]
      User uploads + product images.

External systems we depend on:
  - Stripe (payment processing)
  - SendGrid (transactional email)
  - Sentry (error monitoring)

Relationships:
  User → Web App: Loads via HTTPS
  Web App → API Server: REST calls
  API Server → Database: SQL queries
  API Server → Cache: get/set
  API Server → S3: upload/download files
  API Server → Stripe: payment intents
  API Server → SendGrid: transactional emails

A Container diagram is enough for most "explain how the system works" conversations. New developers can read it in a few minutes; ops teams can identify resources to monitor; product managers can see what depends on what. Drop into Container level when "show me the architecture" comes up.

Conventions that make architecture diagrams readable

  • Labels on every box AND every line — "What is this box?" "What does this line mean (REST? gRPC? queue? sync? async?)" must be answerable without context.
  • Color coding — match the cloud provider (orange for AWS, blue for Azure, multicolor for GCP), or use color to distinguish layers (gray for external, blue for internal, red for legacy).
  • Direction matters — arrow direction shows initiator. "Web App → API" = web app calls API. Use bidirectional arrows only when both initiate.
  • Group related containers — boxes-around-boxes for "this is the inside of a Kubernetes cluster", "this lives in AWS region us-east-1".
  • Legend — always include one. What does "dotted line" mean? What does the icon mean? Without legend, the diagram is ambiguous.
  • Date — mark "as of [date]" so future readers know whether the diagram is current.

When to reach for this tool

  • You are starting a new project and want to communicate the design with stakeholders.
  • You are onboarding new team members and need a "here is how everything fits together" reference.
  • You are doing system-design interviews / preparing to give one and want to practice the visual communication.
  • You are auditing an existing system and need to map its current state.

What this tool will not do

  • It will not auto-discover your architecture. Some tools (AWS Config, Terraform graph) can infer architecture from cloud resources or IaC; this tool diagrams what you specify.
  • It will not validate that the diagram matches reality. Whether the boxes exist, whether the arrows correspond to actual calls — your responsibility to verify.
  • It will not replace specialized infrastructure diagrams. Network topology, security perimeter, deployment topology — each has its own conventions; C4 is for application architecture.
  • It will not handle every cloud provider's icon library exhaustively. AWS, Azure, GCP basics covered; obscure services or other clouds (Oracle, IBM) may need generic icons.

Frequently asked questions

Is the C4 model "just UML"?

No. UML has 13+ diagram types; C4 has 4 levels. UML is comprehensive and academically rigorous; C4 is practical and opinionated. C4 acknowledges that "the diagram's purpose is to communicate", not "the diagram is the formal specification". For practical architecture documentation in 2026, C4 has won.

How often should I update architecture diagrams?

Level 1 (System Context): rarely — major changes only (new external system, new audience). Level 2 (Container): on significant changes (new service, new database, new external dependency). Level 3 (Component): only when working on that container — treat as "active doc" during heavy development, ignore otherwise.

Should architecture diagrams be in git?

Yes — alongside the code they describe. For text-source diagrams (Structurizr DSL, PlantUML C4, Mermaid), commit the source; renders are reproducible. For visual editor outputs, commit the JSON / DSL plus the rendered image.

How detailed should diagrams be?

Enough that a new reader can answer "what does this box do" and "what does this arrow mean" without help. Not so detailed that maintaining accuracy is impossible. Tactical: "we have a Redis" is more useful than "we have 3 Redis nodes in cluster mode with sentinel" — unless your audience needs to know the cluster details.

What is Structurizr DSL?

A text-based DSL (domain-specific language) for defining C4 architecture diagrams. The same source generates Context, Container, and Component diagrams. Lives in git; views are auto-generated. Adopted by some teams as the "single source of truth" for architecture. Slight learning curve, big consistency win.

How is this different from network diagrams?

Network diagrams show physical / network topology (subnets, load balancers, firewalls, VPCs). C4 / architecture diagrams show logical components and relationships. Both are useful; both are different abstractions. The same system has both; do not conflate them.

Related tools

Diagram & Flowchart Editor

Create flowcharts, UML diagrams, mind maps visually. Export to SVG/PNG. Free online diagram maker and flowchart creator

Database Schema Designer

Visual ERD designer for database schemas. Create tables, define relationships, foreign keys. Export to SQL for MySQL, PostgreSQL, SQLite. Free online ERD tool

State Machine Designer

Design finite state machines visually. Define states, transitions, actions. Generate XState code. Free online FSM and statechart editor

Docker Compose Builder

Build docker-compose.yml files visually. Add MySQL, PostgreSQL, Redis, MongoDB services. Free online Docker Compose YAML generator

Last updated · E-Utils editorial team