C4 diagrams in Slack: context and container examples

Direct answer: To share a C4 diagram in Slack, write Mermaid using C4Context or C4Container and send it through an app that renders Mermaid. A Slack code block preserves the Mermaid text; it does not draw the diagram. Use a context view for people and external systems around one software system, or a container view for the applications and data stores inside it. Mermaid marks its C4 syntax experimental, so test the result in the Slack app your team will use.

Slack supports code blocks for text and code formatting, while an app such as Mermaid Preview adds a /mermaid command that uploads a rendered PNG. The official C4 model is independent of any notation or tool; Mermaid is one way to express it in a Slack workflow.

Choose the C4 view that answers the review question

C4 uses four static structure levels. A team does not need to create all four: the C4 model says context and container views are enough for many software teams. Choose the narrowest view that answers the question in the Slack thread.

View	Include	Useful review question
System context	One software system, its users, and the external systems it directly interacts with	Which people and external systems touch our system?
Container	The applications and data stores inside one software system, plus directly connected people or systems	Which runnable parts own this responsibility, and how do they communicate?
Component	The major components inside one container	Which modules inside this application own the behavior?
Code	Classes or functions inside one component	Which implementation details need explanation or generation from code?

In C4, a container means an application or data store that runs or holds data. It does not automatically mean a Docker container. A container view communicates the high-level technology choices and how those parts communicate; deployment details such as replicas, load balancers, and failover belong in a separate deployment view. The C4 container guidance explains that boundary.

C4 also has supporting diagram types: system landscape, dynamic, and deployment. A landscape view covers a wider set of systems; a dynamic view describes interactions; and a deployment view shows where software runs in a particular environment. Keep those purposes separate from the four zoom levels instead of fitting every question into one container diagram. See the C4 diagram guide for the distinctions.

Example 1: system context in Mermaid C4

Use C4Context when reviewers need the system boundary and its direct connections, not its internal services. This online-shop example leaves out technologies, protocols, workers, and databases on purpose.

C4Context
    title Online shop - system context
    Person(customer, "Customer", "Buys products online")
    System(shop, "Online shop", "Web and mobile storefront")
    System_Ext(payment, "Payment provider", "Card processing")
    System_Ext(email, "Email service", "Order confirmations")
    Rel(customer, shop, "Browses and places orders")
    Rel(shop, payment, "Charges cards")
    Rel(shop, email, "Sends receipts")

This view can answer whether the shop sends order or payment data to the right external parties. It cannot explain which internal service makes the call; use the container view for that question. The C4 system-context guidance recommends focusing on people and connected systems, with little low-level technology detail.

Example 2: container view for an engineering review

If reviewers ask where payment retries happen, zoom into the shop. A C4 container can be a web app, API, worker, queue, or data store when that element is a running application or stored-data boundary.

C4Container
    title Online shop - container view
    Person(customer, "Customer", "Places orders")
    System_Ext(payment, "Payment provider", "Card processing")
    Container_Boundary(shop, "Online shop") {
        Container(web, "Web storefront", "React")
        Container(api, "Checkout API", "Python")
        ContainerQueue(retries, "Payment retry queue", "SQS")
        Container(worker, "Payment worker", "Python")
        ContainerDb(db, "Orders database", "PostgreSQL")
    }
    Rel(customer, web, "Browses and submits cart")
    Rel(web, api, "Submits cart", "HTTPS")
    Rel(api, payment, "Authorizes card", "HTTPS")
    Rel(api, retries, "Enqueues a failed payment")
    Rel(retries, worker, "Delivers a retry")
    Rel(worker, payment, "Retries authorization", "HTTPS")
    Rel(worker, db, "Records payment state", "SQL")

The example makes ownership and direction reviewable: the API places failed attempts on a queue, the worker retries them, and the database stores payment state. If you are documenting a deployed system, check each box and arrow against the code, configuration, or operational source your team treats as authoritative.

Mermaid C4 syntax has practical limits

Mermaid currently lists five C4 diagram declarations: C4Context, C4Container, C4Component, C4Dynamic, and C4Deployment. Its C4 syntax reference labels the diagram type experimental, so syntax or behavior may change between Mermaid releases.

Layout control is limited: Mermaid does not fully auto-arrange C4 diagrams, and statement order affects where shapes appear. The same reference lists links, tags, and legends among unfinished features. If you need a C4 feature Mermaid does not support, use a tool that implements it. A standard Mermaid flowchart with subgraphs offers more control over grouping and direction, but Mermaid still places nodes with an automatic layout algorithm (flowchart layout documentation). Your labels and conventions—not C4-specific declarations—carry the model meaning. Choose a tool with manual node placement if exact positioning is a requirement.

Before standardizing on Mermaid C4, render a small sample in the exact Slack app and inspect it at the size people will read. Start with one boundary and a few relationships; split the view if labels or crossing lines make the question hard to follow.

Run the review in Slack

1. Name the view and its state. Start the message with “Container view — proposed checkout design” or “System context — current production boundary.” That tells reviewers whether to assess a target design or verify an existing one.
2. Ask one decision question. For example: “Should failed payment authorization be retried by the Checkout API or a separate worker?” Keep questions about box ownership, boundaries, or flow direction in this thread; open a second view when the abstraction changes.
3. Choose how to render it. Mermaid Preview's /mermaid command posts a PNG, so keep the editable source somewhere reviewers can find it. Arialine uses Mermaid 12, including C4, and renders valid pasted Mermaid without an AI call. With workspace saving on and board capacity available, that source can become a versioned board in the Slack conversation.
4. Keep alternatives separate. Arialine's Branch workflow creates a separate board from a chosen version, leaving the original view intact. On Free, the current plan limits include three boards with up to eight versions per board, so each branch uses a board slot; Team lists unlimited boards and versions. When the team chooses an option, update the main board deliberately rather than treating a branch as an automatic merge.
5. Verify the accepted view. Check accepted relationships against implementation and deployment sources before labeling the diagram current.

If workspace saving is off, a render-only paste is not retained. Pasted Mermaid supplied with an explicit edit request still needs to be saved to create or update the board; the setting does not disable edits to boards that already exist. See the pasted-Mermaid privacy guide for this boundary and the Mermaid-in-Slack guide for the board workflow.

Check the diagram before you ask for approval

The C4 review checklist asks reviewers to confirm scope, element types and responsibilities, and the meaning and direction of relationships. For a Slack review, check these details before posting:

• Does the title identify the C4 view, system boundary, and whether this shows current or proposed design?
• Does each box have a name, type, and responsibility? Add technology choices on container views when they matter to the decision.
• Does every arrow point in the correct direction and say what crosses it? Add a protocol such as HTTPS where useful.
• Are external systems visibly outside the system boundary? Are deployment-specific details kept out of a container view?
• Can a reviewer understand acronyms, shapes, and colors without asking the author?

For a full review of labels, boundaries, and missing failure paths, use the Slack diagram-review checklist. If the architecture question concerns a message sequence rather than system structure, use a Mermaid sequence diagram in Slack.

FAQ

Does Slack render C4 Mermaid without an app?

No. Slack can show Mermaid as code in a code block, but rendering it as a diagram requires a Mermaid-capable app. Mermaid Preview documents /mermaid and PNG output in its Slack Marketplace listing.

Does Mermaid support every C4 view?

Mermaid documents context, container, component, dynamic, and deployment syntax. Its reference marks C4 support experimental and does not list a C4Code declaration. The official C4 model also describes code diagrams and system-landscape diagrams, so use another notation or tool if you need those views in Mermaid.

Do I need to maintain all four C4 levels?

No. Maintain the views that answer real questions. The C4 model says system-context and container diagrams are sufficient for many teams; add component, code, or supporting diagrams when a concrete review or operational need calls for them.

Does a C4 container mean Docker?

No. In the C4 model, a container is an application or data store. Docker containers are one possible deployment technology, but deployment topology is a separate concern from the C4 container abstraction.