Why can't I send my Structurizr Lite link?

Structurizr Lite runs on localhost, usually in Docker on your machine. The URL means nothing to anyone else — the same reason a local dev server link never works for a colleague.

How do I share a C4 model without buying seats?

Export the diagrams — Structurizr's CLI can emit static HTML, SVG or PlantUML — and publish the result as a page. Reviewers get a URL; nobody needs a workspace account.

Which C4 level should I publish?

Whichever the audience needs. Context and container diagrams are the ones non-engineers act on; component diagrams are usually a distraction outside the owning team.

Can the whole model go on one page?

Yes, and it works well — context, then containers, then components, each with its prose. That ordering is the point of C4, and a single scrolling page preserves it better than a diagram picker.

Does this stay in sync with the DSL?

If you export and publish from CI on every merge, yes. The published URL then always reflects the committed model.

Share a Structurizr C4 model

The C4 model is diagrams-as-code done properly: one DSL file, four levels of zoom, everything version-controlled next to the system it describes.

Then the head of product asks to see the architecture, and your options are a localhost:8080 link that means nothing to them, or a cloud workspace seat they will use once.

localhost is not a share link

Structurizr Lite is a container you run locally. It is the right tool for authoring, and the URL it prints is reachable only from your machine — see why a localhost link doesn't work for others.

The cloud workspace solves reachability by adding accounts, which works for the engineers and stalls for everyone else. The people who most need the context diagram — product, compliance, a prospective customer's security reviewer — are exactly the people you will not be provisioning seats for.

Export, then publish

The Structurizr CLI turns the DSL into artifacts you own:

structurizr-cli export -workspace workspace.dsl -format plantuml
# or -format mermaid, or the static site export

Render those to SVG and assemble one page — context first, containers second, components last, each with a paragraph saying what the reader is looking at:

<h1>Payments platform — architecture</h1>

<h2>1 · System context</h2>
<p>Who talks to the platform, and what for.</p>
<!-- context.svg -->

<h2>2 · Containers</h2>
<p>The deployable units and the protocols between them.</p>
<!-- containers.svg -->

Publish it and you have one URL that holds the whole model, in the order C4 intends it to be read.

One page beats a diagram picker

Structurizr's own UI gives you a dropdown of views, which is right for exploration and wrong for review. A reviewer opening a picker does not know which view answers their question, so they look at one, form a partial impression and leave.

A single scrolling page enforces the narrative: zoom out, then in, with the prose that connects them. It is also the version you can hand to someone who has never heard of C4 and expect a useful reaction.

Keep it current from CI

An architecture diagram nobody regenerates becomes a lie within a quarter. Export and publish in the pipeline on every merge to main, updating the same report id:

- run: structurizr-cli export -workspace docs/workspace.dsl -format mermaid
- run: ./scripts/publish-architecture.sh

The URL you pasted into the onboarding doc six months ago still shows the current system. See publishing from CI.

Worth knowing

Publish context and container levels. Component diagrams age fastest and interest the fewest people.
Comments anchor per diagram, so a security reviewer's question lands on the container it is about — see commenting on HTML.
Access control still applies. An architecture page is usually not something to leave open; restrict it like any other report — see security.
5 MB per report body.

Try it

Free — unlimited reports, commenters and revisions.

Publish a diagram →