Deployment Diagram

A deployment diagram models the physical architecture of a system—showing how software artifacts are deployed onto hardware nodes and how those nodes communicate. While class diagrams and sequence diagrams describe logical software structure and behavior, deployment diagrams ground the system in physical reality: which servers run which components, how servers connect to each other, what protocols they use, and where databases and external services reside. This is essential for operations teams, infrastructure architects, and anyone responsible for system performance, reliability, and security.

Core Concepts

Node: A physical or virtual computing resource that hosts software. Nodes can be hardware devices (servers, workstations, mobile devices, IoT sensors) or execution environments (virtual machines, Docker containers, application servers). Nodes are represented as 3D boxes.

Artifact: A physical piece of software deployed onto a node—executable files, libraries, configuration files, database scripts, or container images. Artifacts are shown inside nodes to indicate deployment relationships.

Communication Path: A connection between nodes representing a network link, protocol, or communication channel. Labeled with the protocol used (HTTP, TCP/IP, JDBC, MQTT).

Device: A node that represents physical hardware—a server, router, or mobile phone.

Execution Environment: A software node that provides a runtime platform for artifacts—a JVM, Docker container, web server, or database engine.

Notation

Real-World Example: E-Commerce Platform Deployment

This deployment diagram communicates:

• Static assets are served through a CDN for performance
• An application load balancer distributes traffic across multiple containers
• The application auto-scales horizontally (N containers)
• Database is separated from application servers with primary-replica configuration
• Redis handles caching and sessions
• RabbitMQ handles asynchronous message processing
• Communication protocols are labeled on each connection

Another Example: Mobile Application Architecture

When to Use Deployment Diagrams

System procurement: Specifying hardware requirements for purchasing decisions.

Operations planning: Documenting how to deploy and configure the production system.

Performance analysis: Identifying network bottlenecks, single points of failure, and scalability constraints.

Security review: Showing trust boundaries, encrypted communication channels, and firewall placement.

Cloud architecture: Documenting AWS/Azure/GCP infrastructure configuration for IaC (Infrastructure as Code) planning.

Disaster recovery: Showing primary and failover deployments, backup locations, and recovery topology.

Deployment Diagram Best Practices

Show the most significant nodes and connections—do not clutter with every minor component. Label communication paths with protocols and port numbers when relevant. Distinguish between physical devices and execution environments using stereotypes. Include multiplicity where applicable (showing that N containers exist behind a load balancer). Show external systems and third-party services that the system depends on. Include security boundaries (DMZ, private subnet, VPN connections) to support security reviews.

Common Modeling Decisions

Level of detail: A high-level deployment diagram might show only major tiers (web, application, database). A detailed diagram for a single service might show individual containers, sidecars, and configuration mounts.

Cloud vs. on-premises: Cloud deployments use service names (RDS, ECS, S3) rather than hardware specifications. On-premises deployments might specify server models, RAM, and disk configurations.

Development vs. production: Different deployment diagrams may exist for development (single node, all services together), staging (production-like but smaller scale), and production (full redundancy and scaling) environments.