diff --git a/assets/images/actions-approve-deployments.png b/assets/images/actions-approve-deployments.png
new file mode 100644
index 0000000000..2411368d4b
Binary files /dev/null and b/assets/images/actions-approve-deployments.png differ
diff --git a/assets/images/actions-review-deployments.png b/assets/images/actions-review-deployments.png
new file mode 100644
index 0000000000..bb2ae0af84
Binary files /dev/null and b/assets/images/actions-review-deployments.png differ
diff --git a/assets/images/environments-sidebar.png b/assets/images/environments-sidebar.png
new file mode 100644
index 0000000000..2d601526fe
Binary files /dev/null and b/assets/images/environments-sidebar.png differ
diff --git a/assets/images/help/settings/appearance-tab.png b/assets/images/help/settings/appearance-tab.png
index dcd3422ac6..5e5e975891 100644
Binary files a/assets/images/help/settings/appearance-tab.png and b/assets/images/help/settings/appearance-tab.png differ
diff --git a/content/actions/guides/about-continuous-integration.md b/content/actions/guides/about-continuous-integration.md
index b6fd273317..e95c24d84b 100644
--- a/content/actions/guides/about-continuous-integration.md
+++ b/content/actions/guides/about-continuous-integration.md
@@ -25,7 +25,7 @@ Building and testing your code requires a server. You can build and test updates
 
 ### About continuous integration using {% data variables.product.prodname_actions %}
 
-CI using {% data variables.product.prodname_actions %} offers workflows that can build the code in your repository and run your tests. Workflows can run on {% data variables.product.prodname_dotcom %}-hosted virtual machines, or on machines that you host yourself. For more information, see "[Virtual environments for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners)," and "[About self-hosted runners](/actions/automating-your-workflow-with-github-actions/about-self-hosted-runners)."
+CI using {% data variables.product.prodname_actions %} offers workflows that can build the code in your repository and run your tests. Workflows can run on {% data variables.product.prodname_dotcom %}-hosted virtual machines, or on machines that you host yourself. For more information, see "[Virtual environments for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners)" and "[About self-hosted runners](/actions/automating-your-workflow-with-github-actions/about-self-hosted-runners)."
 
 You can configure your CI workflow to run when a {% data variables.product.product_name %} event occurs (for example, when new code is pushed to your repository), on a set schedule, or when an external event occurs using the repository dispatch webhook.
 
diff --git a/content/actions/guides/building-and-testing-nodejs.md b/content/actions/guides/building-and-testing-nodejs.md
index 49f45da43e..9a3120d64f 100644
--- a/content/actions/guides/building-and-testing-nodejs.md
+++ b/content/actions/guides/building-and-testing-nodejs.md
@@ -193,7 +193,7 @@ steps:
 
 {% data reusables.github-actions.setup-node-intro %}
 
-To authenticate to your private registry, you'll need to store your npm authentication token as a secret in your repository settings. For example, create a secret called `NPM_TOKEN`. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
+To authenticate to your private registry, you'll need to store your npm authentication token as a secret. For example, create a repository secret called `NPM_TOKEN`. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
 
 In the example below, the secret `NPM_TOKEN` stores the npm authentication token. The `setup-node` action configures the *.npmrc* file to read the npm authentication token from the `NODE_AUTH_TOKEN` environment variable. When using the `setup-node` action to create an *.npmrc* file, you must set the `NPM_AUTH_TOKEN` environment variable with the secret that contains your npm authentication token.
 
diff --git a/content/actions/guides/building-and-testing-powershell.md b/content/actions/guides/building-and-testing-powershell.md
index be50ffc52f..faca1bcdc2 100644
--- a/content/actions/guides/building-and-testing-powershell.md
+++ b/content/actions/guides/building-and-testing-powershell.md
@@ -214,7 +214,7 @@ The `always()` function configures the job to continue processing even if there
 
 ### Publishing to PowerShell Gallery
 
-You can configure your workflow to publish your PowerShell module to the PowerShell Gallery when your CI tests pass. You can use repository secrets to store any tokens or credentials needed to publish your package. For more information, see "[Creating and using encrypted secrets](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
+You can configure your workflow to publish your PowerShell module to the PowerShell Gallery when your CI tests pass. You can use secrets to store any tokens or credentials needed to publish your package. For more information, see "[Creating and using encrypted secrets](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
 
 The following example creates a package and uses `Publish-Module` to publish it to the PowerShell Gallery:
 
diff --git a/content/actions/guides/building-and-testing-python.md b/content/actions/guides/building-and-testing-python.md
index c1ab59cba5..ee9fe22a68 100644
--- a/content/actions/guides/building-and-testing-python.md
+++ b/content/actions/guides/building-and-testing-python.md
@@ -391,7 +391,7 @@ jobs:
 
 You can configure your workflow to publish your Python package to any package registry you'd like when your CI tests pass.
 
-You can store any access tokens or credentials needed to publish your package using repository secrets. The following example creates and publishes a package to PyPI using `twine` and `dist`. For more information, see "[Creating and using encrypted secrets](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
+You can store any access tokens or credentials needed to publish your package using secrets. The following example creates and publishes a package to PyPI using `twine` and `dist`. For more information, see "[Creating and using encrypted secrets](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
 
 {% raw %}
 ```yaml
diff --git a/content/actions/guides/publishing-docker-images.md b/content/actions/guides/publishing-docker-images.md
index a933d62399..14ae4aea83 100644
--- a/content/actions/guides/publishing-docker-images.md
+++ b/content/actions/guides/publishing-docker-images.md
@@ -50,7 +50,7 @@ To push to Docker Hub, you will need to have a Docker Hub account, and have a Do
 
 The `build-push-action` options required for Docker Hub are:
 
-* `username` and `password`: This is your Docker Hub username and password. We recommend storing your Docker Hub username and password as encrypted secrets in your {% data variables.product.prodname_dotcom %} repository so they aren't exposed in your workflow file. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
+* `username` and `password`: This is your Docker Hub username and password. We recommend storing your Docker Hub username and password as secrets so they aren't exposed in your workflow file. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
 * `repository`: Your Docker Hub repository in the format `DOCKER-HUB-NAMESPACE/DOCKER-HUB-REPOSITORY`.
 
 {% raw %}
diff --git a/content/actions/guides/publishing-nodejs-packages.md b/content/actions/guides/publishing-nodejs-packages.md
index f428baed28..c6272bd7a8 100644
--- a/content/actions/guides/publishing-nodejs-packages.md
+++ b/content/actions/guides/publishing-nodejs-packages.md
@@ -44,7 +44,7 @@ If you add steps in your workflow to configure the `publishConfig` fields in you
 
 Each time you create a new release, you can trigger a workflow to publish your package. The workflow in the example below runs when the `release` event triggers with type `created`. The workflow publishes the package to the npm registry if CI tests pass.
 
-To perform authenticated operations against the npm registry in your workflow, you'll need to store your npm authentication token as a secret in your repository settings. For example, create a secret called `NPM_TOKEN`. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
+To perform authenticated operations against the npm registry in your workflow, you'll need to store your npm authentication token as a secret. For example, create a repository secret called `NPM_TOKEN`. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
 
 By default, npm uses the `name` field of the *package.json* file to determine the npm registry. When publishing to a global namespace, you only need to include the package name. For example, you would publish a package named `npm-hello-world-test` to the `https://www.npmjs.com/package/npm-hello-world-test`.
 
diff --git a/content/actions/learn-github-actions/managing-complex-workflows.md b/content/actions/learn-github-actions/managing-complex-workflows.md
index 66ff5b77ae..ffdff1fdd2 100644
--- a/content/actions/learn-github-actions/managing-complex-workflows.md
+++ b/content/actions/learn-github-actions/managing-complex-workflows.md
@@ -1,7 +1,7 @@
 ---
 title: Managing complex workflows
 shortTitle: Managing complex workflows
-intro: 'This guide shows you how to use the advanced features of {% data variables.product.prodname_actions %}, with secret management, dependent jobs, caching, build matrices, and labels.'
+intro: 'This guide shows you how to use the advanced features of {% data variables.product.prodname_actions %}, with secret management, dependent jobs, caching, build matrices,{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %} environments,{% endif %} and labels.'
 versions:
   free-pro-team: '*'
   enterprise-server: '>=2.22'
@@ -148,6 +148,12 @@ jobs:
 
 For more information, see  ["Using labels with self-hosted runners](/actions/hosting-your-own-runners/using-labels-with-self-hosted-runners)."
 
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
+### Using environments
+
+You can configure environments with protection rules and secrets. Each job in a workflow can reference a single environment. Any protection rules configured for the environment must pass before a job referencing the environment is sent to a runner. For more information, see "[Environments](/actions/reference/environments)."
+{% endif %}
+
 ### Next steps
 
 To continue learning about {% data variables.product.prodname_actions %}, see "[Sharing workflows with your organization](/actions/learn-github-actions/sharing-workflows-with-your-organization)."
diff --git a/content/actions/learn-github-actions/migrating-from-travis-ci-to-github-actions.md b/content/actions/learn-github-actions/migrating-from-travis-ci-to-github-actions.md
index ff321c9472..3c720b7eb0 100644
--- a/content/actions/learn-github-actions/migrating-from-travis-ci-to-github-actions.md
+++ b/content/actions/learn-github-actions/migrating-from-travis-ci-to-github-actions.md
@@ -176,7 +176,7 @@ When migrating from Travis CI, consider the following key features in {% data va
 
 #### Storing secrets
 
-{% data variables.product.prodname_actions %} allows you to store secrets and reference them in your jobs. {% data variables.product.prodname_actions %} also includes policies that allow you to limit access to secrets at the repository and organization level. For more information, see "[Encrypted secrets](/actions/reference/encrypted-secrets)."
+{% data variables.product.prodname_actions %} allows you to store secrets and reference them in your jobs. {% data variables.product.prodname_actions %} organizations can limit which repositories can access organization secrets. {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}Environment protection rules can require manual approval for a workflow to access environment secrets. {% endif %}For more information, see "[Encrypted secrets](/actions/reference/encrypted-secrets)."
 
 #### Sharing files between jobs and workflows
 
diff --git a/content/actions/learn-github-actions/security-hardening-for-github-actions.md b/content/actions/learn-github-actions/security-hardening-for-github-actions.md
index 418711ff42..112a68f67c 100644
--- a/content/actions/learn-github-actions/security-hardening-for-github-actions.md
+++ b/content/actions/learn-github-actions/security-hardening-for-github-actions.md
@@ -19,7 +19,7 @@ This guide explains how to configure security hardening for certain {% data vari
 
 ### Using secrets
 
-Sensitive values should never be stored as plaintext in workflow files, but rather as secrets. [Secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets) can be configured at the organization or repository level, and allow you to store sensitive information in {% data variables.product.product_name %}.
+Sensitive values should never be stored as plaintext in workflow files, but rather as secrets. [Secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets) can be configured at the organization{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}, repository, or environment{% else %} or repository{% endif %} level, and allow you to store sensitive information in {% data variables.product.product_name %}.
 
 Secrets use [Libsodium sealed boxes](https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes), so that they are encrypted before reaching {% data variables.product.product_name %}. This occurs when the secret is submitted [using the UI](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets#creating-encrypted-secrets-for-a-repository) or through the [REST API](/rest/reference/actions#secrets). This client-side encryption helps the minimize risks related to accidental logging (for example, exception logs and request logs, among others) within {% data variables.product.product_name %}'s infrastructure. Once the secret is uploaded, {% data variables.product.product_name %} is then able to decrypt it so that it can be injected into the workflow runtime. 
 
@@ -38,6 +38,10 @@ To help prevent accidental disclosure, {% data variables.product.product_name %}
 - **Audit and rotate registered secrets**
     - Periodically review the registered secrets to confirm they are still required. Remove those that are no longer needed.
     - Rotate secrets periodically to reduce the window of time during which a compromised secret is valid.
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
+- **Consider requiring review for access to secrets**
+    - You can use required reviewers to protect environment secrets. A workflow job cannot access environment secrets until approval is granted by a reviewer. For more information about storing secrets in environments or requiring reviews for environments, see "[Encrypted secrets](/actions/reference/encrypted-secrets)" and "[Environments](/actions/reference/environments)."
+{% endif %}
 
 ### Using third-party actions
 
@@ -66,13 +70,13 @@ This means that a compromise of a single action within a workflow can be very si
 
 ### Considering cross-repository access
 
-{% data variables.product.product_name %} is intentionally scoped for a single repository at a time. The `GITHUB_TOKEN` used in the workflow environment grants the same level of access as a write-access user, because any write-access user can access this token by creating or modifying workflow files. Users have specific permissions for each repository, so having the `GITHUB_TOKEN` for one repository grant access to another would impact the {% data variables.product.prodname_dotcom %} permission model if not implemented carefully. Similarly, caution must be taken when adding {% data variables.product.prodname_dotcom %} authentication tokens to the workflow environment, because this can also affect the {% data variables.product.prodname_dotcom %} permission model by inadvertently granting broad access to collaborators.
+{% data variables.product.product_name %} is intentionally scoped for a single repository at a time. The `GITHUB_TOKEN` grants the same level of access as a write-access user, because any write-access user can access this token by creating or modifying workflow files. Users have specific permissions for each repository, so having the `GITHUB_TOKEN` for one repository grant access to another would impact the {% data variables.product.prodname_dotcom %} permission model if not implemented carefully. Similarly, caution must be taken when adding {% data variables.product.prodname_dotcom %} authentication tokens to a workflow, because this can also affect the {% data variables.product.prodname_dotcom %} permission model by inadvertently granting broad access to collaborators.
 
-We have [a plan on the {% data variables.product.prodname_dotcom %} roadmap](https://github.com/github/roadmap/issues/74) to support a flow that allows cross-repository access within {% data variables.product.product_name %}, but this is not yet a supported feature. Currently, the only way to perform privileged cross-repository interactions is to place a {% data variables.product.prodname_dotcom %} authentication token or SSH key as a secret within the workflow environment. Because many authentication token types do not allow for granular access to specific resources, there is significant risk in using the wrong token type, as it can grant much broader access than intended.
+We have [a plan on the {% data variables.product.prodname_dotcom %} roadmap](https://github.com/github/roadmap/issues/74) to support a flow that allows cross-repository access within {% data variables.product.product_name %}, but this is not yet a supported feature. Currently, the only way to perform privileged cross-repository interactions is to place a {% data variables.product.prodname_dotcom %} authentication token or SSH key as a secret within the workflow. Because many authentication token types do not allow for granular access to specific resources, there is significant risk in using the wrong token type, as it can grant much broader access than intended.
 
 This list describes the recommended approaches for accessing repository data within a workflow, in descending order of preference:
 
-1. **The `GITHUB_TOKEN` in the workflow environment**
+1. **The `GITHUB_TOKEN`**
     -  This token is intentionally scoped to the single repository that invoked the workflow, and has the same level of access as a write-access user on the repository. The token is created before each job begins and expires when the job is finished. For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)."
     - The `GITHUB_TOKEN` should be used whenever possible.
 2. **Repository deploy key**
diff --git a/content/actions/managing-workflow-runs/enabling-debug-logging.md b/content/actions/managing-workflow-runs/enabling-debug-logging.md
index f28a20c8b6..a4787be05a 100644
--- a/content/actions/managing-workflow-runs/enabling-debug-logging.md
+++ b/content/actions/managing-workflow-runs/enabling-debug-logging.md
@@ -13,6 +13,9 @@ versions:
 These extra logs are enabled by setting secrets in the repository containing the workflow, so the same permissions requirements will apply:
 
 - {% data reusables.github-actions.permissions-statement-secrets-repository %}
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
+- {% data reusables.github-actions.permissions-statement-secrets-environment %}
+{% endif %}
 - {% data reusables.github-actions.permissions-statement-secrets-organization %}
 - {% data reusables.github-actions.permissions-statement-secrets-api %}
 
diff --git a/content/actions/managing-workflow-runs/index.md b/content/actions/managing-workflow-runs/index.md
index 8905d8b087..4d5e7554b1 100644
--- a/content/actions/managing-workflow-runs/index.md
+++ b/content/actions/managing-workflow-runs/index.md
@@ -1,7 +1,7 @@
 ---
 title: Managing workflow runs
 shortTitle: Managing workflow runs
-intro: 'You can view the status and results of each step in your workflow, cancel a pending workflow, view billable job execution minutes, debug and re-run a failed workflow, search and download logs, and download artifacts.'
+intro: 'You can view the status and results of each step in your workflow, cancel a pending workflow, {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}review deployments, {% endif %}view billable job execution minutes, debug and re-run a failed workflow, search and download logs, and download artifacts.'
 redirect_from:
   - /actions/configuring-and-managing-workflows/managing-a-workflow-run
   - /articles/viewing-your-repository-s-workflows
@@ -24,6 +24,7 @@ versions:
 {% link_in_list /manually-running-a-workflow %}
 {% link_in_list /re-running-a-workflow %}
 {% link_in_list /canceling-a-workflow %}
+{% link_in_list /reviewing-deployments %}
 {% link_in_list /disabling-and-enabling-a-workflow %}
 {% link_in_list /deleting-a-workflow-run %}
 {% link_in_list /viewing-job-execution-time %}
diff --git a/content/actions/managing-workflow-runs/reviewing-deployments.md b/content/actions/managing-workflow-runs/reviewing-deployments.md
new file mode 100644
index 0000000000..85600eb39f
--- /dev/null
+++ b/content/actions/managing-workflow-runs/reviewing-deployments.md
@@ -0,0 +1,27 @@
+---
+title: Reviewing deployments
+intro: You can approve or reject jobs awaiting review.
+product: '{% data reusables.gated-features.environments %}'
+versions:
+  free-pro-team: '*'
+  enterprise-server: '>=3.1'
+---
+
+{% data reusables.actions.environments-beta %}
+
+### About required reviews in workflows
+
+Jobs that reference an environment configured with required reviewers will wait for an approval before starting. While a job is awaiting approval, it has a status of "Waiting". If a job is not approved within 30 days, the workflow run will be automatically canceled.
+
+For more information about environments and required approvals, see "[Environments](/actions/reference/environments)."
+
+### Approving or rejecting a job
+
+1. Navigate to the workflow run that requires review. For more information about navigating to a workflow run, see "[Viewing workflow run history](/actions/managing-workflow-runs/viewing-workflow-run-history)."
+2. Click **Review deployments**. 
+   ![Review deployments](/assets/images/actions-review-deployments.png)
+3. Select the job environment(s) to approve or reject. Optionally, leave a comment.
+   ![Approve deployments](/assets/images/actions-approve-deployments.png)
+4. Approve or reject:
+   - To approve the job, click **Approve and deploy**. Once a job is approved (and any other environment protection rules have passed), the job will proceed. At this point, the job can access any secrets stored in the environment.
+   - To reject the job, click **Reject**. If a job is rejected, the workflow will fail.
diff --git a/content/actions/reference/authentication-in-a-workflow.md b/content/actions/reference/authentication-in-a-workflow.md
index 81f62e19fd..74f6174055 100644
--- a/content/actions/reference/authentication-in-a-workflow.md
+++ b/content/actions/reference/authentication-in-a-workflow.md
@@ -14,8 +14,6 @@ versions:
 {% data reusables.actions.enterprise-beta %}
 {% data reusables.actions.enterprise-github-hosted-runners %}
 
-Anyone with `write` access to a repository can create, read, and use secrets.
-
 ### About the `GITHUB_TOKEN` secret
 
 {% data variables.product.prodname_dotcom %} automatically creates a `GITHUB_TOKEN` secret to use in your workflow. You can use the `GITHUB_TOKEN` to authenticate in a workflow run.
diff --git a/content/actions/reference/encrypted-secrets.md b/content/actions/reference/encrypted-secrets.md
index efd6d09bd6..7042534c0d 100644
--- a/content/actions/reference/encrypted-secrets.md
+++ b/content/actions/reference/encrypted-secrets.md
@@ -1,6 +1,6 @@
 ---
 title: Encrypted secrets
-intro: Encrypted secrets allow you to store sensitive information in your repository or organization.
+intro: Encrypted secrets allow you to store sensitive information in your organization{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}, repository, or repository environments{% else %} or repository{% endif %}.
 product: '{% data reusables.gated-features.actions %}'
 redirect_from:
   - /github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
@@ -12,14 +12,19 @@ versions:
 ---
 
 {% data reusables.actions.enterprise-beta %}
+{% data reusables.actions.environments-beta %}
 {% data reusables.actions.enterprise-github-hosted-runners %}
 
 ### About encrypted secrets
 
-Secrets are encrypted environment variables that you create in a repository or organization. The secrets you create are available to use in {% data variables.product.prodname_actions %} workflows. {% data variables.product.prodname_dotcom %} uses a [libsodium sealed box](https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes) to help ensure that secrets are encrypted before they reach {% data variables.product.prodname_dotcom %}, and remain encrypted until you use them in a workflow.
+Secrets are encrypted environment variables that you create in an organization{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}, repository, or repository environment{% else %} or repository{% endif %}. The secrets that you create are available to use in {% data variables.product.prodname_actions %} workflows. {% data variables.product.prodname_dotcom %} uses a [libsodium sealed box](https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes) to help ensure that secrets are encrypted before they reach {% data variables.product.prodname_dotcom %} and remain encrypted until you use them in a workflow.
 
 {% data reusables.github-actions.secrets-org-level-overview %}
 
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
+For secrets stored at the environment level, you can enable required reviewers to control access to the secrets. A workflow job cannot access environment secrets until approval is granted by required approvers.
+{% endif %}
+
 #### Naming your secrets
 
 The following rules apply to secret names:
@@ -27,7 +32,10 @@ The following rules apply to secret names:
 * Secret names can only contain alphanumeric characters (`[a-z]`, `[A-Z]`, `[0-9]`) or underscores (`_`). Spaces are not allowed.
 * Secret names must not start with the `GITHUB_` prefix.
 * Secret names must not start with a number.
-* Secret names must be unique at the level they are created at. For example, a secret created at the organization-level must have a unique name at that level, and a secret created at the repository-level must have a unique name in that repository. If an organization-level secret has the same name as a repository-level secret, then the repository-level secret takes precedence.
+* Secret names are not case-sensitive.
+* Secret names must be unique at the level they are created at. For example, {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}a secret created at the environment level must have a unique name in that environment, {% endif %}a secret created at the repository level must have a unique name in that repository, and a secret created at the organization level must have a unique name at that level. 
+  
+  If a secret with the same name exists at multiple levels, the secret at the lower level takes precedence. For example, if an organization-level secret has the same name as a repository-level secret, then the repository-level secret takes precedence.{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %} Similarly, if an organization, repository, and environment all have a secret with the same name, the environment-level secret takes precedence.{% endif %}
 
 To help ensure that {% data variables.product.prodname_dotcom %} redacts your secret in logs, avoid using structured data as the values of secrets. For example, avoid creating secrets that contain JSON or encoded Git blobs.
 
@@ -43,6 +51,10 @@ You can use and read encrypted secrets in a workflow file if you have access to
 
 {% endwarning %}
 
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
+Organization and repository secrets are read when a workflow run is queued, and environment secrets are read when a job referencing the environment starts.
+{% endif %}
+
 You can also manage secrets using the REST API. For more information, see "[Secrets](/rest/reference/actions#secrets)."
 
 #### Limiting credential permissions
@@ -56,12 +68,27 @@ When generating credentials, we recommend that you grant the minimum permissions
 {% data reusables.repositories.navigate-to-repo %}
 {% data reusables.repositories.sidebar-settings %}
 {% data reusables.github-actions.sidebar-secret %}
-1. Click **Add a new secret**.
+1. Click **New repository secret**.
 1. Type a name for your secret in the **Name** input box.
 1. Enter the value for your secret.
 1. Click **Add secret**.
 
-If your repository can access secrets from the parent organization, then those secrets are also listed on this page.
+If your repository {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}has environment secrets or {% endif %}can access secrets from the parent organization, then those secrets are also listed on this page.
+
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
+### Creating encrypted secrets for an environment
+
+{% data reusables.github-actions.permissions-statement-secrets-environment %}
+
+{% data reusables.repositories.navigate-to-repo %}
+{% data reusables.repositories.sidebar-settings %}
+{% data reusables.github-actions.sidebar-environment %}
+1. Click on the environment that you want to add a secret to.
+1. Under **Environment secrets**, click **Add secret**.
+1. Type a name for your secret in the **Name** input box.
+1. Enter the value for your secret.
+1. Click **Add secret**.
+{% endif %}
 
 ### Creating encrypted secrets for an organization
 
@@ -72,7 +99,7 @@ When creating a secret in an organization, you can use a policy to limit which r
 {% data reusables.organizations.navigate-to-org %}
 {% data reusables.organizations.org_settings %}
 {% data reusables.github-actions.sidebar-secret %}
-1. Click **New secret**.
+1. Click **New organization secret**.
 1. Type a name for your secret in the **Name** input box.
 1. Enter the **Value** for your secret.
 1. From the **Repository access** dropdown list, choose an access policy.
@@ -151,7 +178,7 @@ steps:
 
 ### Limits for secrets
 
-Your workflow can have up to 100 secrets. The names of secret environment variables must be unique in a repository.
+You can store up to 1,000 secrets per organization{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}, 100 secrets per repository, and 100 secrets per environment{% else %} and 100 secrets per repository{% endif %}. A workflow may use up to 100 organization secrets and 100 repository secrets.{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %} Additionally, a job referencing an environment may use up to 100 environment secrets.{% endif %}
 
 Secrets are limited to 64 KB in size. To use secrets that are larger than 64 KB, you can store encrypted secrets in your repository and save the decryption passphrase as a secret on {% data variables.product.prodname_dotcom %}. For example, you can use `gpg` to encrypt your credentials locally before checking the file in to your repository on {% data variables.product.prodname_dotcom %}. For more information, see the "[gpg manpage](https://www.gnupg.org/gph/de/manual/r1023.html)."
 
diff --git a/content/actions/reference/environments.md b/content/actions/reference/environments.md
new file mode 100644
index 0000000000..58585b2950
--- /dev/null
+++ b/content/actions/reference/environments.md
@@ -0,0 +1,69 @@
+---
+title: Environments
+intro: You can configure environments with protection rules and secrets. A workflow job can reference an environment to use the environment's protection rules and secrets.
+product: '{% data reusables.gated-features.environments %}'
+versions:
+  free-pro-team: '*'
+  enterprise-server: '>=3.1'
+---
+
+{% data reusables.actions.environments-beta %}
+
+### About environments
+
+You can configure environments with protection rules and secrets. When a workflow job references an environment, the job won't start until all of the environment's protection rules pass. A job also cannot access secrets that are defined in an environment until all the environment protection rules pass.
+
+{% if currentVersion == "free-pro-team@latest" %}
+Environment protection rules and environment secrets are only available on public repositories. If you convert a repository from public to private, any configured protection rules or environment secrets will be ignored, and you will not be able to configure any environments. If you convert your repository back to public, you will have access to any previously configured protection rules and environment secrets.
+{% endif %}
+
+#### Environment protection rules
+
+Environment protection rules require specific conditions to pass before a job referencing the environment can proceed. You can use environment protection rules to require a manual approval or to delay a job.
+
+##### Required reviewers
+
+Use required reviewers to require a specific person or team to approve workflow jobs that reference the environment. You can list up to six users or teams as reviewers. The reviewers must have at least read access to the repository. Only one of the required reviewers needs to approve the job for it to proceed.
+
+For more information on reviewing jobs that reference an environment with required reviewers, see "[Reviewing deployments](/actions/managing-workflow-runs/reviewing-deployments)."
+
+##### Wait timer
+
+Use a wait timer to delay a job for a specific amount of time after the job is initially triggered. The time (in minutes) must be an integer between 0 and 43,200 (30 days).
+
+#### Environment secrets
+
+Secrets stored in an environment are only available to workflow jobs that reference the environment. If the environment requires approval, a job cannot access environment secrets until one of the required reviewers approves it. For more information about secrets, see "[Encrypted secrets](/actions/reference/encrypted-secrets)."
+
+### Creating an environment
+
+{% data reusables.github-actions.permissions-statement-environment %}
+
+{% data reusables.repositories.navigate-to-repo %}
+{% data reusables.repositories.sidebar-settings %}
+{% data reusables.github-actions.sidebar-environment %}
+1. Click **New environment**.
+1. Enter a name for the environment, then click **Configure environment**. Environment names are not case sensitive. An environment name may not exceed 255 characters and must be unique within the repository.
+1. Configure any environment protection rules or environment secrets.
+
+Running a workflow that references an environment that does not exist will create an environment with the referenced name. The newly created environment will not have any protection rules or secrets configured. Anyone that can edit workflows in the repository can create environments via a workflow file, but only repository admins can configure the environment.
+
+### Referencing an environment
+
+Each job in a workflow can reference a single environment. Any protection rules configured for the environment must pass before a job referencing the environment is sent to a runner. When the job is sent to the runner, the job can access the environment's secrets.
+
+For more information on syntax to reference environments in workflows, see "[Workflow syntax for GitHub Actions](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idenvironment)." For more information on reviewing jobs that reference an environment with required reviewers, see "[Reviewing deployments](/actions/managing-workflow-runs/reviewing-deployments)."
+
+When a workflow references an environment, the environment will appear in the repository's deployments. For more information about viewing current and previous deployments, see "[Viewing deployment history](/developers/overview/viewing-deployment-history)."
+
+### Deleting an environment
+
+{% data reusables.github-actions.permissions-statement-environment %}
+
+Deleting an environment will delete all secrets and protection rules associated with the environment. Any jobs currently waiting because of protection rules from the deleted environment will automatically fail.
+
+{% data reusables.repositories.navigate-to-repo %}
+{% data reusables.repositories.sidebar-settings %}
+{% data reusables.github-actions.sidebar-environment %}
+1. Next the the environment that you want to delete, click {% octicon "trashcan" aria-label="The trashcan icon" %}.
+2. Click **I understand, delete this environment**.
diff --git a/content/actions/reference/events-that-trigger-workflows.md b/content/actions/reference/events-that-trigger-workflows.md
index fde2137e11..a4c893987f 100644
--- a/content/actions/reference/events-that-trigger-workflows.md
+++ b/content/actions/reference/events-that-trigger-workflows.md
@@ -743,4 +743,4 @@ on:
 
 {% data reusables.github-actions.actions-do-not-trigger-workflows %} For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)."
 
-If you would like to trigger a workflow from a workflow run, you can trigger the event using a personal access token. You'll need to create a personal access token and store it as a secret. To minimize your {% data variables.product.prodname_actions %} usage costs, ensure that you don't create recursive or unintended workflow runs. For more information, see "[Creating and storing encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)."
+If you would like to trigger a workflow from a workflow run, you can trigger the event using a personal access token. You'll need to create a personal access token and store it as a secret. To minimize your {% data variables.product.prodname_actions %} usage costs, ensure that you don't create recursive or unintended workflow runs. For more information on storing a personal access token as a secret, see "[Creating and storing encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)."
diff --git a/content/actions/reference/index.md b/content/actions/reference/index.md
index 885e33838a..c94ae2f4eb 100644
--- a/content/actions/reference/index.md
+++ b/content/actions/reference/index.md
@@ -27,11 +27,19 @@ You can configure workflows to run when specific GitHub events occur, at a sched
 
 ### Authentication and secrets
 
-{% data variables.product.prodname_dotcom %} provides a token that you can use to authenticate on behalf of {% data variables.product.prodname_actions %}. You can also store sensitive information as a secret in your organization or repository. {% data variables.product.prodname_dotcom %} encrypts all secrets.
+{% data variables.product.prodname_dotcom %} provides a token that you can use to authenticate on behalf of {% data variables.product.prodname_actions %}. You can also store sensitive information as a secret in your organization{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}, repository, or environments{% else %} or repository{% endif %}. {% data variables.product.prodname_dotcom %} encrypts all secrets.
 
 {% link_in_list /authentication-in-a-workflow %}
 {% link_in_list /encrypted-secrets %}
 
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
+### Environments
+
+Workflow jobs can reference environments that have protection rules or environment-specific secrets.
+
+{% link_in_list /environments %}
+{% endif %}
+
 ### {% data variables.product.prodname_dotcom %}-hosted runners
 
 GitHub offers hosted virtual machines to run workflows. The virtual machine contains an environment with tools, packages, and environment variables for GitHub Actions to use.
diff --git a/content/actions/reference/workflow-syntax-for-github-actions.md b/content/actions/reference/workflow-syntax-for-github-actions.md
index 863f1adada..4c3fd48f94 100644
--- a/content/actions/reference/workflow-syntax-for-github-actions.md
+++ b/content/actions/reference/workflow-syntax-for-github-actions.md
@@ -223,7 +223,7 @@ defaults:
 
 A workflow run is made up of one or more jobs. Jobs run in parallel by default. To run jobs sequentially, you can define dependencies on other jobs using the `jobs.<job_id>.needs` keyword.
 
-Each job runs in an environment specified by `runs-on`.
+Each job runs in a runner environment specified by `runs-on`.
 
 You can run an unlimited number of jobs as long as you are within the workflow usage limits. For more information, see "[Usage limits and billing](/actions/reference/usage-limits-billing-and-administration)" for {% data variables.product.prodname_dotcom %}-hosted runners and "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners/#usage-limits)" for self-hosted runner usage limits.
 
@@ -320,6 +320,39 @@ runs-on: [self-hosted, linux]
 
 For more information, see "[About self-hosted runners](/github/automating-your-workflow-with-github-actions/about-self-hosted-runners)" and "[Using self-hosted runners in a workflow](/github/automating-your-workflow-with-github-actions/using-self-hosted-runners-in-a-workflow)."
 
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
+### `jobs.<job_id>.environment`
+
+The environment that the job references. All environment protection rules must pass before a job referencing the environment is sent to a runner. For more information, see "[Environments](/actions/reference/environments)."
+
+You can provide the environment as only the environment `name`, or as an environment object with the `name` and `url`. The URL maps to `environment_url` in the deployments API. For more information about the deployments API, see "[Deployments](/rest/reference/repos#deployments)."
+
+##### Example using a single environment name
+
+```yaml
+environment: staging_environment
+```
+
+##### Example using environment name and URL
+
+```yaml
+environment:
+  name: production_environment
+  url: https://github.com
+```
+
+The URL can be an expression and can use any context except for the `secrets` context. For more information about expressions, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)."
+
+#### Example
+{% raw %}
+```yaml
+environment:
+  name: production_environment
+  url: ${{ steps.step_name.outputs.url_output }}
+```
+{% endraw %}
+{% endif %}
+
 ### `jobs.<job_id>.outputs`
 
 A `map` of outputs for a job. Job outputs are available to all downstream jobs that depend on this job. For more information on defining job dependencies, see [`jobs.<job_id>.needs`](#jobsjob_idneeds).
@@ -769,7 +802,7 @@ The maximum number of minutes to let a job run before {% data variables.product.
 
 ### `jobs.<job_id>.strategy`
 
-A strategy creates a build matrix for your jobs. You can define different variations of an environment to run each job in.
+A strategy creates a build matrix for your jobs. You can define different variations to run each job in.
 
 ### `jobs.<job_id>.strategy.matrix`
 
diff --git a/content/developers/overview/index.md b/content/developers/overview/index.md
index 3e6bb65ca2..c277cc12c8 100644
--- a/content/developers/overview/index.md
+++ b/content/developers/overview/index.md
@@ -11,6 +11,7 @@ versions:
 
 {% link_in_list /about-githubs-apis %}
 {% link_in_list /managing-deploy-keys %}
+{% link_in_list /viewing-deployment-history %}
 {% link_in_list /using-ssh-agent-forwarding %}
 {% link_in_list /secret-scanning %}
 {% link_in_list /replacing-github-services %}
diff --git a/content/developers/overview/viewing-deployment-history.md b/content/developers/overview/viewing-deployment-history.md
new file mode 100644
index 0000000000..bd0b394f48
--- /dev/null
+++ b/content/developers/overview/viewing-deployment-history.md
@@ -0,0 +1,20 @@
+---
+title: Viewing deployment history
+intro: View current and previous deployments for your repository.
+versions:
+  free-pro-team: '*'
+  enterprise-server: '*'
+  github-ae: '*'
+---
+
+{% data reusables.actions.environments-beta %}
+
+You can deliver deployments through {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}{% data variables.product.prodname_actions %} and environments or with {% endif %}the REST API and third party apps. {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}For more information about {% data variables.product.prodname_actions %}, see "[{% data variables.product.prodname_actions %}](/actions)." {% endif %}For more information about deployments with the REST API, see "[Repositories](/rest/reference/repos#deployments)."
+
+To view current and past deployments, click **Environments** on the home page of your repository. ![Environments](/assets/images/environments-sidebar.png)
+
+The deployments page displays the last active deployment of each environment for your repository. If the deployment includes an environment URL, a "View deployment" button that links to the URL is shown next to the deployment.
+
+The activity log shows the deployment history for your environments. By default, only the most recent deployment for an environment has an `Active` status; all previously active deployments have an `Inactive` status. For more information on automatic inactivation of deployments, see "[Inactive deployments](/rest/reference/repos#inactive-deployments)."
+
+You can also use the REST API to get information about deployments. For more information, see "[Repositories](/rest/reference/repos#deployments)."
diff --git a/data/reusables/actions/environments-beta.md b/data/reusables/actions/environments-beta.md
new file mode 100644
index 0000000000..5fe1386417
--- /dev/null
+++ b/data/reusables/actions/environments-beta.md
@@ -0,0 +1,9 @@
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
+
+{% note %}
+
+**Note:** Environments, environment protection rules, and environment secrets are currently in beta and subject to change.
+
+{% endnote %}
+
+{% endif %}
diff --git a/data/reusables/gated-features/actions-shared.md b/data/reusables/gated-features/actions-shared.md
new file mode 100644
index 0000000000..57b1ab7a7d
--- /dev/null
+++ b/data/reusables/gated-features/actions-shared.md
@@ -0,0 +1 @@
+{% data variables.product.prodname_actions %} is available with {% data variables.product.prodname_free_user %}, {% data variables.product.prodname_pro %}, {% data variables.product.prodname_free_team %} for organizations, {% data variables.product.prodname_team %}, {% data variables.product.prodname_ghe_cloud %}, {% data variables.product.prodname_ghe_server %}, and {% data variables.product.prodname_ghe_one %}. {% data variables.product.prodname_actions %} is not available for private repositories owned by accounts using legacy per-repository plans. 
diff --git a/data/reusables/gated-features/actions.md b/data/reusables/gated-features/actions.md
index 5d2317297b..bafbe8fae9 100644
--- a/data/reusables/gated-features/actions.md
+++ b/data/reusables/gated-features/actions.md
@@ -1 +1 @@
-{% data variables.product.prodname_actions %} is available with {% data variables.product.prodname_free_user %}, {% data variables.product.prodname_pro %}, {% data variables.product.prodname_free_team %} for organizations, {% data variables.product.prodname_team %}, {% data variables.product.prodname_ghe_cloud %}, {% data variables.product.prodname_ghe_server %}, and {% data variables.product.prodname_ghe_one %}. {% data variables.product.prodname_actions %} is not available for private repositories owned by accounts using legacy per-repository plans. {% if currentVersion == "free-pro-team@latest" %}{% data reusables.gated-features.more-info %}{% endif %}
+{% data reusables.gated-features.actions-shared %} {% if currentVersion == "free-pro-team@latest" %}{% data reusables.gated-features.more-info %}{% endif %}
diff --git a/data/reusables/gated-features/environments.md b/data/reusables/gated-features/environments.md
new file mode 100644
index 0000000000..77cd45f6aa
--- /dev/null
+++ b/data/reusables/gated-features/environments.md
@@ -0,0 +1 @@
+{% data reusables.gated-features.actions-shared %} Environments, environment protection rules, and environment secrets are available in public repositories for all products and in private repositories for {% data variables.product.prodname_ghe_server %}. {% if currentVersion == "free-pro-team@latest" %}{% data reusables.gated-features.more-info %}{% endif %}
diff --git a/data/reusables/github-actions/permissions-statement-environment.md b/data/reusables/github-actions/permissions-statement-environment.md
new file mode 100644
index 0000000000..8dfdbb1403
--- /dev/null
+++ b/data/reusables/github-actions/permissions-statement-environment.md
@@ -0,0 +1 @@
+To configure an environment in a user account repository, you must be the repository owner. To configure an environment in an organization repository, you must have `admin` access.
diff --git a/data/reusables/github-actions/permissions-statement-secrets-environment.md b/data/reusables/github-actions/permissions-statement-secrets-environment.md
new file mode 100644
index 0000000000..c9445ab95e
--- /dev/null
+++ b/data/reusables/github-actions/permissions-statement-secrets-environment.md
@@ -0,0 +1 @@
+To create secrets for an environment in a user account repository, you must be the repository owner. To create secrets for an environment in an organization repository, you must have `admin` access.
diff --git a/data/reusables/github-actions/sidebar-environment.md b/data/reusables/github-actions/sidebar-environment.md
new file mode 100644
index 0000000000..26955b2ce4
--- /dev/null
+++ b/data/reusables/github-actions/sidebar-environment.md
@@ -0,0 +1 @@
+1. In the left sidebar, click **Environments**.