StrongDM 101 · Training Guide · September 2025
StrongDM 101 · September 2025

Basic Architecture
& Deployment

A comprehensive interactive guide covering the core concepts of StrongDM's proxy network, components, control plane, and deployment patterns.

7Modules
~20Minutes
8Quiz Questions
🔌

Proxy Architecture

Learn how StrongDM acts as a proxy, routing traffic between users and protected resources through a secure TLS-encrypted channel.

🛡️

Gateways & Relays

Understand the distinct roles Gateways and Relays play, and when to use each component in real-world deployments.

⚙️

Control Plane

Discover how the SDM control plane orchestrates authentication, authorization, and routing decisions across the network.

🗺️

Mesh Routing

Explore how StrongDM's default mesh routing algorithm selects optimal paths and handles failover scenarios automatically.

💡

Learning Objectives

After completing this guide, you will be able to illustrate component relationships, explain node identification, describe how resources are identified, and explain how the API decides to block or allow traffic.

Module 01

How Proxies Work

StrongDM operates as a proxy — intercepting and forwarding traffic on behalf of users to protected resources, while holding the necessary credentials to authenticate.

▸ Basic Proxy Model
User
👤 Client
Request
Proxy
🔄 Proxy
Forwarded
Target
🗄️ Resource
▸ StrongDM Proxy Network
User
👤 Client
Native Protocol
StrongDM
💻 SDM Client
TLS
StrongDM
🚪 Gateway
StrongDM Proxy Network
Native Protocol
Target
🗄️ Resource
ConceptDetail
User Experience Users connect using familiar tools — terminals, browsers, SQL clients — as if connecting directly. No workflow change required.
Internal Transport Within the StrongDM network, all communication between clients and nodes uses TLS encryption.
Final Hop Protocol The Gateway connects to the resource using the same protocol as the user's initial connection (SSH, PostgreSQL, HTTPS, etc.).
Credentials The proxy (Gateway) holds resource credentials and authenticates on behalf of the user, enabling centralized credential management.
🔐

Key Insight

Users never directly interact with resource credentials. The Gateway handles authentication to the resource, while StrongDM handles user identity and authorization centrally.

Module 02

Gateways & Relays

Two types of nodes make up the StrongDM proxy network. Understanding when to use each is fundamental to proper deployment design.

🚪

Gateway

Publicly accessible node that accepts inbound connections from StrongDM clients. Serves a listen address that clients connect to. The entry point to the StrongDM network.


Public Facing
📡

Relay

Internally deployed node that initiates an outbound connection to a Gateway. Lives inside private/segmented networks with no inbound traffic permitted. Connects to resources on behalf of users.


Internal Only
▸ Gateway + Relay Architecture
USER'S NETWORK
StrongDM
💻 Client
DMZ
Node
🚪 Gateway
INITIATE ↑
ESTABLISH ↓
RESOURCE NETWORK
🔒 Stateful Firewall
Node
📡 Relay
Target
🗄️ Resource
⚡

Why Relays Matter

Relays initiate the connection outbound to the Gateway, leveraging stateful firewall behavior. This eliminates the need to open inbound firewall ports to your private resource network — a major security advantage.

PropertyGatewayRelay
Inbound connections✅ Yes (from clients & relays)❌ No
Outbound connectionsTo resources (flat)To Gateway + resources
Listen address✅ Required❌ Not required
Network placementDMZ / publicPrivate / internal subnet
BinarySame sdm binary — run in "sdm relay" mode
Module 03

StrongDM Control Plane

The control plane (hosted at app.strongdm.com) orchestrates authentication, authorization, and routing — it's the brain of the StrongDM network.

▸ Client Connection Sequence
💻 Client
1. User logs on
3. TLS connect
⚙️ Control Plane
app.strongdm.com
✔ Verifies user identity & permissions
✔ Determines accessible resources
✔ Returns list of relevant Gateways
🚪 Gateway
Accepts TLS
⚠️

Important Distinction

The client establishes TLS connections to all Gateways returned by the control plane. However, the actual Gateway used for a specific resource connection is selected later as part of the routing decision — not during initial setup.

ComponentRole
Control PlaneHosted SaaS at app.strongdm.com. Manages identity, authorization, resource definitions, audit logs, and routing metadata.
Data PlaneThe actual traffic flow through Client → Gateway → (Relay →) Resource. User data never passes through StrongDM's cloud.
CommunicationAll components communicate to control plane over TCP 443. Nodes identify themselves using tokens issued at registration.
ResilienceIf control plane connectivity is lost, existing sessions continue using cached data. New connections may be affected until connectivity restores.
Module 04

Deployment: Flat Network

The simplified Gateway-only architecture — used in lab environments and specific production use cases where all components share network visibility.

🧪

Lab Environment Pattern

This is the architecture used in both the StrongDM-in-a-box lab guide and the default Instruqt lab environment — designed for learning, not production use.

▸ Flat / Gateway-Only Architecture
⚙️ Control Plane — app.strongdm.com (TCP 443)
StrongDM Client
💻 SDM Client
MFA enabled
TCP 5000
Gateway Node
🚪 Gateway
Public IP
Direct
🗄️ Resource 0
🗄️ Resource 1
✅

When to Use

• Lab & testing environments
• Proxying public websites or cloud consoles
• Databases needing private admin access but with public exposure
• Cloud CLIs and management interfaces

⚠️

Requirements

• Resource must be directly accessible by Gateway
• Gateway must be publicly reachable from the SDM client
• If a firewall exists between resource and Gateway, allow TCP 5000
• Nodes are hardened for public exposure

🚫

Do Not Use StrongDM-in-a-box in Production

The lab network has critical shortcomings: only one Gateway (no HA), no Relay deployed, client/Gateway/resources all share the same network, and resources are directly accessible without security devices between them.

Module 05

Deployment: Gateway & Relay

The recommended production architecture. Relays allow resources to remain in private subnets with no inbound access, dramatically reducing the attack surface.

🏭

Production Recommendation

StrongDM strongly recommends deploying Relays in production environments. Best practice is to deploy both Gateways and Relays in an HA (High Availability) configuration — at minimum two of each.

▸ Gateway + Relay Production Architecture
⚙️ Control Plane — TCP 443 to Gateway & Relay
StrongDM
💻 Client
TCP 5000
PUBLIC SUBNET
Gateway
🚪 Gateway
INITIATE ←
TRAFFIC →
INTERNAL HIGH-TRUST
Relay
📡 Relay
🗄️ DB
🖥️ Server
BenefitExplanation
No inbound firewall rules neededRelays initiate outbound connections to the Gateway. The stateful firewall allows return traffic without needing to open inbound ports to private resources.
Resources stay privateResources only need to be accessible from the Relay — never from the internet or public-facing segments.
Segmentation preservedMultiple Relays can serve different network segments (Dev, Prod) from a single Gateway pair.
Reduced blast radiusEven if the Gateway is compromised, resources remain inaccessible without the Relay acting as an internal intermediary.
Module 06

Mesh Routing

StrongDM's default routing algorithm — clients discover available routes from the control plane and intelligently select paths to resources.

🗺️

What is a Route?

A route is a path through available nodes that leads to a desired resource. For example: GW → Resource or GW → Relay → Resource

🔀

Route Selection

Listeners retrieve routes from the control plane (or 15-second TTL cache), randomize order, sort by length (direct routes preferred), then attempt each in order until one succeeds.

▸ Route Selection Algorithm
1
Retrieve routes from Control Plane (or 15s TTL cache)
2
Randomize route order for load distribution
3
Sort by length — GW→Resource preferred over GW→Relay→Resource
4
Attempt each route in order until one succeeds
Routing Scenarios
1
One Gateway → One Resource, Client can reach Gateway
▾

Only one route exists, so it always gets used. Straightforward — client connects directly through the single Gateway to the resource.

2
Two Gateways → One Resource
▾

Either Gateway will be chosen per new connection, randomly. This provides automatic load balancing across the two Gateways for that resource.

3
One Gateway, Two Relays between GW and Resource
▾

The route will switch between the two Relays per new connection, randomly. Load is distributed across both Relays automatically.

4
Two Gateways → One Resource, Client can only reach one GW
▾

Only the route through the accessible Gateway will be used. The inaccessible Gateway's route will fail during the attempt phase and the algorithm moves on.

5
Two Gateways, GW2 goes offline mid-operation
▾

New connections will take a little longer (~15 seconds) until the listener recognizes GW2 is offline and updates its route cache. Existing sessions are unaffected.

6
Two GWs: one in Europe, one in Australia — User in Europe
▾

Half of new connections will go to Australia (and time out due to geographic distance), and half to Europe. This is a cautionary case — geographic proximity matters for routing efficiency and HA design.

📚

Advanced Routing Options

Explicit routing and Proxy Clusters are covered in StrongDM 201 – Deployment (Advanced). These are not used in StrongDM-in-a-box or the default Instruqt environment.

Module 07

Knowledge Check

Test your understanding of the StrongDM architecture concepts covered in this guide. Click an answer to check it.

Question 01 / 08Within the StrongDM network, what protocol is used for communication between the SDM client and the Gateway?

A
SSH
B
TLS (Transport Layer Security)
C
IPSec VPN
D
HTTP
✓ Correct! All communication inside the StrongDM proxy network uses TLS encryption. The user connects to the SDM client using a native protocol, but internally it's TLS all the way to the Gateway.
✗ Not quite. Internally, the StrongDM proxy network uses TLS between clients and nodes. The native protocol (SSH, PostgreSQL, etc.) is only used at the final hop from Gateway to resource.

Question 02 / 08What is the key difference between a Gateway and a Relay in StrongDM?

A
Gateways are more secure than Relays
B
Gateways serve a listen address for inbound connections; Relays only make outbound connections
C
Relays are cloud-hosted, Gateways are on-premise
D
They use different binaries and software packages
✓ Correct! Both run the same sdm binary in "sdm relay" mode. The sole technical difference is that Gateways configure a listen address, allowing other nodes and clients to connect to them inbound.
✗ Not quite. Both run the same sdm binary. The key distinction is about connectivity: Gateways accept inbound connections (they have a listen address), while Relays only initiate outbound connections to Gateways.

Question 03 / 08Why do Relays eliminate the need to reconfigure firewalls for inbound access to resource networks?

A
Relays bypass firewalls entirely using UDP tunnels
C
Relays are placed in the DMZ alongside the Gateway
B
Relays initiate outbound connections to the Gateway, leveraging stateful firewall behavior to allow return traffic
D
Relays use port 443 which is always open
✓ Correct! Stateful firewalls track outbound connections and permit the return traffic. Since the Relay initiates the connection outward to the Gateway, the firewall allows the established session's traffic both ways without needing an explicit inbound rule.
✗ The answer is about stateful firewall behavior. Relays initiate the connection outbound from the private network to the Gateway. Stateful firewalls allow return traffic on established sessions, so no inbound rules are needed.

Question 04 / 08What does the StrongDM control plane return to a client after the user logs on?

A
A list of all resources in the organization
B
The user's credentials for each resource
C
A list of relevant Gateways for resources the user can access
D
A VPN configuration file
✓ Correct! The control plane first determines which resources the user is authorized to access, then identifies the relevant Gateways for those resources and returns them to the client so it can establish TLS connections.
✗ The control plane determines which resources the user can access and which Gateways serve those resources — then returns that list of relevant Gateways to the client for TLS connection setup.

Question 05 / 08In StrongDM's default mesh routing, how are routes ordered before attempting connections?

A
By alphabetical order of Gateway hostname
B
Randomized first, then sorted by route length (shorter routes preferred)
C
By the Gateway with the most available bandwidth
D
Always in the order returned by the control plane
✓ Correct! The client randomizes the routes (for load distribution), then sorts by length — so a direct GW→Resource path is preferred over GW→Relay→Resource — and then attempts each in order until one succeeds.
✗ Routes are first randomized (to spread load), then sorted by hop count — shorter routes (GW→Resource) are tried before longer ones (GW→Relay→Resource). The client then attempts each until one succeeds.

Question 06 / 08Which architecture is used in the StrongDM-in-a-box lab environment?

A
Gateway + Relay with HA configuration
B
Flat (Gateway-only) network with a single Gateway
C
Explicit routing with proxy clusters
D
Multi-region Gateway mesh
✓ Correct! The lab environment uses a simplified flat (Gateway-only) network. This makes it easy to learn, but it's not appropriate for production because there's only one Gateway, no Relay, and all components share the same network.
✗ The StrongDM-in-a-box environment uses a flat (Gateway-only) network with a single Gateway — simple for learning but not suitable for production deployments.

Question 07 / 08If a client has two Gateways available but one goes offline, how long does it typically take for the client to stop attempting the offline Gateway?

A
Immediately — the control plane notifies the client instantly
B
60 seconds
C
Approximately 15 seconds (TTL cache expiry)
D
The client must be restarted
✓ Correct! Routes are cached locally with a ~15 second TTL. During this window, new connections may take slightly longer as the client tries the offline Gateway first before failing over to the working one.
✗ The client caches routes locally with a 15-second TTL. Until the cache expires, it may still attempt the offline Gateway (and fail over to the working one), causing a brief delay on new connections.

Question 08 / 08Why is a Gateway + Relay deployment preferred over a flat (Gateway-only) network for production?

A
Relays provide faster throughput than direct Gateway connections
B
Flat networks require a StrongDM license upgrade
C
Relays allow resources to remain in private subnets with no inbound access, reducing the attack surface
D
Gateways cannot connect to databases directly
✓ Correct! The primary benefit of Relays is keeping resources in private, non-internet-routable subnets. The Relay initiates outbound connections, so no inbound firewall rules are needed for the resource network — greatly reducing the attack surface.
✗ The main reason is security isolation. With a Relay, resources can live in private subnets with no inbound access allowed from outside. This eliminates the need to expose resources to public networks at all.
🎓

Training Complete!

You've completed the StrongDM 101 — Basic Architecture & Deployment training guide. You're now ready to work with StrongDM deployments confidently.

Certificate of Completion
StrongDM 101
Basic Architecture
📖

Next Steps

Proceed to StrongDM 201 — Deployment (Advanced) to learn about explicit routing, proxy clusters, and multi-environment architectures.

🔗

Key References

Bookmark How StrongDM Works and the StrongDM Docs for ongoing reference.