diff --git a/website/content/docs/concepts/workers.mdx b/website/content/docs/concepts/workers.mdx index a2822c4a02..06f49674fc 100644 --- a/website/content/docs/concepts/workers.mdx +++ b/website/content/docs/concepts/workers.mdx @@ -18,7 +18,8 @@ such as the database, KMS, Vault, identity providers, and plugins. private targets. Instead of exposing a private network to the public, or allowing users to have access to entire private networks, workers create a direct network tunnel between users and targets. -![Boundary architecture example showing workers and controllers](/img/access-model.png) +![How Boundary Works](/img/how-boundary-works_light.png#light-theme-only) +![How Boundary Works](/img/how-boundary-works_dark.png#dark-theme-only) ## Capabilities You can use workers in various ways depending on your needs, as follows: diff --git a/website/content/docs/install-boundary/architecture/high-availability.mdx b/website/content/docs/install-boundary/architecture/high-availability.mdx index 15def79d14..1a73fd32dd 100644 --- a/website/content/docs/install-boundary/architecture/high-availability.mdx +++ b/website/content/docs/install-boundary/architecture/high-availability.mdx @@ -22,7 +22,7 @@ The following ports should be available: The general architecture for the server infrastructure requires 3 controllers and 3 workers. Note that it is possible to run a controller and worker within the same process, but the guide here assumes separate deployments. The documentation here uses virtual machines running on Amazon EC2 as the example environment, but this use case can be extrapolated to almost any cloud platform to suit operator needs: -![](/img/production.png) +![](/img/boundary-network.png) As shown above, Boundary is broken up into its controller and worker server components across 3 [EC2 instances](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance), in 3 separate [subnets](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/subnet), in three separate availability zones, with the controller API and UI being publically exposed by an [application load balancer (ALB)](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lb). The worker and controller VM's are in independent [auto-scaling groups](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_group), allowing them to maintain their exact capacity. diff --git a/website/content/docs/oss/index.mdx b/website/content/docs/oss/index.mdx index a2ba90fdcf..a54052d586 100644 --- a/website/content/docs/oss/index.mdx +++ b/website/content/docs/oss/index.mdx @@ -24,7 +24,8 @@ Boundary Community Edition is designed to be straightforward to understand, high and resilient. It can run in clouds, on-premise, or within secure enclaves. Boundary does not require an agent to be installed on the end host. -![How Boundary Works](/img/how-boundary-works.png) +![How Boundary Works](/img/how-boundary-works_light.png#light-theme-only) +![How Boundary Works](/img/how-boundary-works_dark.png#dark-theme-only) ## Tutorial diff --git a/website/content/docs/overview/what-is-boundary.mdx b/website/content/docs/overview/what-is-boundary.mdx index 83b290fb87..d3d6a27d44 100644 --- a/website/content/docs/overview/what-is-boundary.mdx +++ b/website/content/docs/overview/what-is-boundary.mdx @@ -31,7 +31,8 @@ It also gives a brief walkthrough of the end user's experience. The illustration below displays Boundary's core workflow. -![Boundary core workflow](/img/boundary-core-workflow.png) +![Boundary core workflow](/img/boundary-core-workflow_light.png#light-theme-only) +![Boundary core workflow](/img/boundary-core-workflow_dark.png#dark-theme-only) The core Boundary workflow consists of four stages: diff --git a/website/public/img/access-model.png b/website/public/img/access-model.png deleted file mode 100644 index eada43e22a..0000000000 Binary files a/website/public/img/access-model.png and /dev/null differ diff --git a/website/public/img/boundary-core-workflow.png b/website/public/img/boundary-core-workflow.png deleted file mode 100644 index 471af5f098..0000000000 Binary files a/website/public/img/boundary-core-workflow.png and /dev/null differ diff --git a/website/public/img/boundary-core-workflow_dark.png b/website/public/img/boundary-core-workflow_dark.png new file mode 100644 index 0000000000..4050483146 Binary files /dev/null and b/website/public/img/boundary-core-workflow_dark.png differ diff --git a/website/public/img/boundary-core-workflow_light.png b/website/public/img/boundary-core-workflow_light.png new file mode 100644 index 0000000000..61e76fb920 Binary files /dev/null and b/website/public/img/boundary-core-workflow_light.png differ diff --git a/website/public/img/how-boundary-works.png b/website/public/img/how-boundary-works.png deleted file mode 100644 index a9bd98a5ec..0000000000 Binary files a/website/public/img/how-boundary-works.png and /dev/null differ diff --git a/website/public/img/how-boundary-works_dark.png b/website/public/img/how-boundary-works_dark.png new file mode 100644 index 0000000000..1d11c8e976 Binary files /dev/null and b/website/public/img/how-boundary-works_dark.png differ diff --git a/website/public/img/how-boundary-works_light.png b/website/public/img/how-boundary-works_light.png new file mode 100644 index 0000000000..d7ab7a354b Binary files /dev/null and b/website/public/img/how-boundary-works_light.png differ diff --git a/website/public/img/production.png b/website/public/img/production.png deleted file mode 100644 index fea007af12..0000000000 Binary files a/website/public/img/production.png and /dev/null differ