UML Deployment Diagrams: A Complete Guide
Deployment diagrams show where software actually runs: the physical nodes, the artifacts deployed on them, and the connections between them. This guide covers nodes, artifacts, and modern cloud topologies.
Every other UML diagram describes software in the abstract. The deployment diagram is the one that touches the ground: it shows the physical or virtual hardware your system runs on and which pieces of software are installed where. When someone asks how the system is actually deployed, whether the web tier and database sit on the same box, how many application servers there are, or where the load balancer fits, a deployment diagram answers in a single picture.
This makes deployment diagrams valuable for operations, capacity planning, security review, and onboarding anyone who needs to reason about the runtime topology rather than the code. This guide covers nodes and artifacts, the connections between them, and how to adapt the notation to containers and cloud infrastructure. You can draw them at /diagrams, and they complement the component diagrams covered under /diagram-tools/uml-diagram.
Nodes: the hardware and execution environments
The central element is the node, drawn as a three-dimensional box (a cube). A node is a physical or virtual resource where software executes. There are two flavors: a device node represents physical hardware, such as a server, a load balancer, or a mobile phone, while an execution environment node represents a software container that hosts other software, such as an operating system, a web server, a JVM, or a Docker runtime.
Nodes nest. You commonly draw a device node for a physical or cloud server, containing an execution environment node for the OS or container runtime, which in turn hosts the application. This nesting mirrors reality: an application runs inside a container, which runs on a host, which lives in a data center. The level of detail you show should match the audience. An ops team wants the full stack; an architecture overview might show only the top-level nodes.
Artifacts: the deployable things
An artifact is a concrete, deployable piece of software: a JAR file, an executable, a compiled binary, a database schema, a configuration file, or a container image. It is drawn as a rectangle with the artifact stereotype or a small document icon. Artifacts are what actually get placed onto nodes, and the relationship between them is called a deployment, sometimes shown by simply drawing the artifact inside the node box or with a dependency arrow labeled deploy.
The distinction between an artifact and a component matters. A component is a logical unit of design; an artifact is the physical file that realizes it. The OrderService component might be realized by an order-service.jar artifact, which is deployed to an application server node. Deployment diagrams live in the world of artifacts and nodes, the physical realization, which is exactly why they are the diagram operations teams care about.
Communication paths
Nodes are connected by communication paths, drawn as solid lines between them, optionally labeled with the protocol or network in use, such as HTTPS, TCP/IP, or JDBC. These lines show which nodes talk to which, which is essential information for both performance and security reasoning. A path labeled HTTPS between the load balancer and the web servers, and a JDBC path between the application servers and the database, together sketch the network shape of the system.
Communication paths are where a deployment diagram starts to double as a security diagram. When every connection between nodes is drawn and labeled with its protocol, it becomes easy to spot an unencrypted link, a database exposed to the public tier, or a missing firewall boundary. Many teams annotate the diagram with trust zones or network segments precisely to make these questions visible during review.
Modeling modern cloud and container topologies
UML deployment notation predates the cloud, but it adapts to it well if you apply it pragmatically. The key is to map cloud concepts onto nodes and artifacts sensibly rather than trying to reproduce a vendor's exact console.
- Model a container image as an artifact and the container runtime (such as a Docker engine) as an execution environment node.
- Model a Kubernetes pod as an execution environment node, nested inside a worker node, inside the cluster.
- Model a managed database or queue as a node with a stereotype naming the service, rather than detailing its internals.
- Use communication paths labeled with protocols to show the network edges, and group nodes into availability zones or VPCs with enclosing boxes.
- Show a load balancer as a device node fronting a set of identical application nodes to convey horizontal scaling.
- Keep serverless functions as artifacts deployed to a platform node rather than inventing per-invocation detail.