1
1
# Architecture
2
2
3
- This document provides a high level overview of Coder's architecture.
3
+ The Coder deployment model is flexible and offers various components that
4
+ platform administrators can deploy and scale depending on the use cases. This
5
+ page describes possible deployments, challenges, and risks associated with them.
4
6
5
- ## Single region architecture
7
+ Learn more about our [ Reference Architectures] ( ../admin/architectures/index.md )
8
+ and platform scaling capabilities.
6
9
7
- ![ Architecture Diagram] ( ../images/architecture-single-region.png )
8
-
9
- ## Multi-region architecture
10
-
11
- ![ Architecture Diagram] ( ../images/architecture-multi-region.png )
10
+ ## Components
12
11
13
- ## coderd
12
+ ### coderd
14
13
15
14
coderd is the service created by running ` coder server ` . It is a thin API that
16
15
connects workspaces, provisioners and users. coderd stores its state in Postgres
@@ -24,7 +23,7 @@ It offers:
24
23
- Workspace Web Applications (e.g easily access code-server)
25
24
- Agent registration
26
25
27
- ## provisionerd
26
+ ### provisionerd
28
27
29
28
provisionerd is the execution context for infrastructure modifying providers. At
30
29
the moment, the only provider is Terraform (running ` terraform ` ).
@@ -33,7 +32,7 @@ By default, the Coder server runs multiple provisioner daemons.
33
32
[ External provisioners] ( ../admin/provisioners.md ) can be added for security or
34
33
scalability purposes.
35
34
36
- ## Agents
35
+ ### Agents
37
36
38
37
An agent is the Coder service that runs within a user's remote workspace. It
39
38
provides a consistent interface for coderd and clients to communicate with
@@ -50,7 +49,7 @@ Templates are responsible for
50
49
[ creating and running agents] ( ../templates/index.md#coder-agent ) within
51
50
workspaces.
52
51
53
- ## Service Bundling
52
+ ### Service Bundling
54
53
55
54
While coderd and Postgres can be orchestrated independently, our default
56
55
installation paths bundle them all together into one system service. It's
@@ -61,7 +60,7 @@ situations that necessitate decomposition:
61
60
- Achieving greater availability and efficiency (horizontally scale individual
62
61
services)
63
62
64
- ## Workspaces
63
+ ### Workspaces
65
64
66
65
At the highest level, a workspace is a set of cloud resources. These resources
67
66
can be VMs, Kubernetes clusters, storage buckets, or whatever else Terraform
@@ -72,3 +71,17 @@ while those that don't are called _peripheral resources_.
72
71
73
72
Each resource may also be _ persistent_ or _ ephemeral_ depending on whether
74
73
they're destroyed on workspace stop.
74
+
75
+ ## Deployment models
76
+
77
+ ### Single region architecture
78
+
79
+ ![ Architecture Diagram] ( ../images/architecture-single-region.png )
80
+
81
+ <!-- Single VM, up to 100 users, Docker+sysbox container runtime -->
82
+
83
+ ### Multi-region architecture
84
+
85
+ ![ Architecture Diagram] ( ../images/architecture-multi-region.png )
86
+
87
+ <!-- Run multiple provisioners in each cloud, allowing Coder to deploy against it (zero trust) -->
0 commit comments