Connect the infrastructure

Boxes placed on infrastructure still don't tell the reader what talks to what. Connections between nodes or instances complete the picture: traffic paths, protocols, and the plumbing in between. You can also show inferred connections that derive from your C4 model and flag unmatched connections where deployment differs from the logical architecture.

Step 1 — Add a connection

Connections between instances in the deployment viewer

In the deployment editor, add a connection from the source node or instance to its target.

Step 2 — Label for clarity

Label it with the transport where it matters: "HTTPS", "TCP 5432", "AMQP". A labeled connection tells the reader not just "they talk" but "how".

Step 3 — Check direction

Check each connection reads in the direction of who initiates, same as a C4 relationship. The arrow points from the source to the target.

Reconnect a connection's endpoints

Select a connection on the canvas to open its form on the right. The "From" and "To" dropdowns let you re-point the connection to a different node or instance without deleting and recreating it. When you reconnect, the label, technology, and description carry over.

Alternatively, select the connection and drag either endpoint on the canvas to a new target. The endpoint snaps to the target's connection handle.

The same form carries a Line style field — the project-wide connection styles (colour, width, solid/dashed/dotted) shared with the C4 and F4 diagrams. See Connection line styles.

Choose which side a line uses

Each end of a connection can be pinned to a side of its element — Auto, Top, Right, Bottom, or Left — in the Sides control under the From/To pickers. Use it when the automatic anchor fights a dense topology and you want a line to run down a particular column.

Dragging an endpoint onto the handle you want has the same effect; dragging it onto a different element still re-points the connection.

Route a connection by hand

The router decides where every line goes, and on a dense deployment diagram you often know better which corridor a line should take. Select a connection and drag it anywhere along its length: a waypoint appears there and the line runs through it, ignoring the automatic router from then on.

  • Drag a waypoint to move it — it is a corner, so both directions redraw the line.
  • A handle on a straight run shows as a bar lying along that run (it can only slide that way); a round dot is a free corner. Waypoints snap to the line's own ends and to each other, with a guide showing what they lined up with — hold Alt to place one freely.
  • Double-click a waypoint to remove it. Remove the last one and the line routes itself again.
  • The ↺ chip on the line re-fits it to the route the diagram would pick now, while keeping it under your control; Back to automatic routing in the connection's form hands it back entirely.

A hand-routed line keeps its path when nodes move — that is the point of routing it yourself, and the ↺ chip is the way back to a sensible path.

A line drawn inside an instance is routed once. Connections between two children of the same instance belong to the instance, not to one environment, so the route you draw is drawn identically in every copy of that instance, in every environment — exactly like the children it connects. Everything else belongs to its environment, and is routed there.

Hide or show connections

In the editor and viewer toolbars, one Show connections / Hide connections toggle controls whether connection lines are drawn at all — hiding removes every line, explicit and inferred alike. This is useful when you're focusing on the infrastructure topology and the lines are cluttering the view.

While connections are shown, two independent checkboxes sit next to the toggle: Mark unmatched and Mark inferred (both covered below). They add markings on top of the normal picture; unticking them never removes your real connections.

You can also hide or show individual connections by selecting one, opening its form, and clicking Hide connection or Show connection.

Mark inferred connections from C4

Your C4 model holds the logical relationships — the API talks to the database, the frontend calls the API. If those C4 containers map to instances on your deployment diagram, those relationships can show up automatically as inferred connections, drawn as dotted lines. Tick Mark inferred (available in both the editor and the viewer) to overlay them. Inferred connections let you spot when the deployment topology is missing a logical path — if every C4 relationship should cross the network, inferred connections make gaps obvious.

When an inferred connection is real and permanent (not just a test path), promote it: in the editor, click the dotted line to select it — its panel explains where it comes from and offers Add as deployment connection, which turns it into a real, editable connection carrying the C4 label and technology. Your deployment diagram then owns the decision about transport and labels.

Mark unmatched connections

When you draw a deployment connection whose endpoints both map to C4 nodes (container or system, walked through nested placements), but no C4 relationship covers it, it can be flagged as unmatched. Tick Mark unmatched (editor and viewer) and such connections get a red-bordered label with a warning icon — the line itself stays as drawn. Unmatched connections are fully legal to keep (you might document infrastructure-only paths, or temporary redirects); the warning just marks a gap between your logical model and deployment reality.

To close the gap from the deployment side, select the unmatched connection in the editor: its form shows the warning and offers Add to C4 model, which creates the missing C4 relationship so the two views agree again.

Tips

  • Connect the plumbing. Load balancers, gateways, and queues earn their place only when connected — an orphaned infrastructure box is clutter.
  • Don't duplicate the logical story. The purpose of the communication lives in the C4 relationship; the deployment connection adds the transport and path.
  • Cross-environment connections are a smell. Production calling staging usually means a modeling mistake — or a real problem worth knowing about.

Where next