From cee0af406bb5eeba14da04802d0ea0f54090e9ab Mon Sep 17 00:00:00 2001 From: Max Brydak <57046745+mbrydak@users.noreply.github.com> Date: Mon, 20 Nov 2023 04:11:41 +0100 Subject: [PATCH] fix typo in readme (#803) --- docs/readme/howitworks.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/readme/howitworks.mdx b/docs/readme/howitworks.mdx index ffc457359..c8cc97c26 100644 --- a/docs/readme/howitworks.mdx +++ b/docs/readme/howitworks.mdx @@ -9,7 +9,7 @@ Digger has 2 main components: When a PR is opened, Digger starts a CI job that runs `terraform plan` and posts plan output as comment. You can then comment "digger apply" to run `terraform apply`. Digger can also be configured to run apply only after the PR has been merged; to check plan output against OPA policies; to run drift detection on schedule; and so on. -The orchestrator backend does not have access to your cloud account, or terraform ates, or plan output, or tfvars, or any other sensitive data. It just triggers CI jobs; your sensitive data never leaves the high-trust environment of your CI. For this reason, there is little reason to self-host the backend of Digger (although you still can). Much easier to use the managed cloud version of the orchestrator. +The orchestrator backend does not have access to your cloud account, or terraform states, or plan output, or tfvars, or any other sensitive data. It just triggers CI jobs; your sensitive data never leaves the high-trust environment of your CI. For this reason, there is little reason to self-host the backend of Digger (although you still can). Much easier to use the managed cloud version of the orchestrator. Digger can also run as a standalone GitHub Action without a backend. In this case: