github · docs-bot · Mar 19, 2026 · Mar 18, 2026 · Mar 19, 2026 · Mar 19, 2026
diff --git a/config/kubernetes/default/deployments/webapp.yaml b/config/kubernetes/default/deployments/webapp.yaml
@@ -16,6 +16,8 @@ spec:
         # See https://thehub.github.com/epd/engineering/dev-practicals/observability/logging/ for more details
         fluentbit.io/parser: logfmt_sloppy
         observability.github.com/splunk_index: docs-internal
+        ad.datadoghq.com/webapp.logs: '[{"source":"nodejs","service":"docs-internal","tags":["env:staging"]}]'
+        ad.datadoghq.com/tolerate-unready: 'true'
     spec:
       dnsPolicy: Default
       containers:
@@ -47,6 +49,15 @@ spec:
             # configuration set in config/moda/configuration/*/env.yaml
             - configMapRef:
                 name: application-config
+          env:
+            - name: POD_NAME
+              valueFrom:
+                fieldRef:
+                  fieldPath: metadata.name
+            - name: POD_NAMESPACE
+              valueFrom:
+                fieldRef:
+                  fieldPath: metadata.namespace
           # Zero-downtime deploys
           # https://thehub.github.com/engineering/products-and-services/internal/moda/feature-documentation/pod-lifecycle/#required-prestop-hook
           # https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks

diff --git a/config/kubernetes/production/deployments/webapp.yaml b/config/kubernetes/production/deployments/webapp.yaml
@@ -18,6 +18,8 @@ spec:
         # See https://thehub.github.com/epd/engineering/dev-practicals/observability/logging/ for more details
         fluentbit.io/parser: logfmt_sloppy
         observability.github.com/splunk_index: docs-internal
+        ad.datadoghq.com/webapp.logs: '[{"source":"nodejs","service":"docs-internal","tags":["env:production"]}]'
+        ad.datadoghq.com/tolerate-unready: 'true'
     spec:
       dnsPolicy: Default
       containers:
@@ -50,6 +52,15 @@ spec:
             # configuration set in config/moda/configuration/*/env.yaml
             - configMapRef:
                 name: application-config
+          env:
+            - name: POD_NAME
+              valueFrom:
+                fieldRef:
+                  fieldPath: metadata.name
+            - name: POD_NAMESPACE
+              valueFrom:
+                fieldRef:
+                  fieldPath: metadata.namespace
           # Zero-downtime deploys
           # https://thehub.github.com/engineering/products-and-services/internal/moda/feature-documentation/pod-lifecycle/#required-prestop-hook
           # https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks

diff --git a/content/actions/concepts/runners/actions-runner-controller.md b/content/actions/concepts/runners/actions-runner-controller.md
@@ -26,10 +26,10 @@ The following diagram illustrates the architecture of ARC's autoscaling runner s
 
 <!-- The numbers in the ordered list below correspond to numbers in the above diagram, which is why we use explicit numbering here. -->
 
-1. {% data variables.product.prodname_actions_runner_controller %} is installed using the supplied Helm charts, and the controller manager pod is deployed in the specified namespace. A new AutoScalingRunnerSet resource is deployed via the supplied Helm charts or a customized manifest file. The AutoScalingRunnerSet Controller calls GitHub's APIs to fetch the runner group ID that the runner scale set will belong to.
-1. The AutoScalingRunnerSet Controller calls the APIs one more time to either fetch or create a runner scale set in the {% data variables.product.prodname_actions %} service before creating the Runner ScaleSet Listener resource.
+1. {% data variables.product.prodname_actions_runner_controller %} is installed using the supplied Helm charts, and the controller manager pod is deployed in the specified namespace. A new AutoScalingRunnerSet resource is deployed via the supplied Helm charts or a customized manifest file. The AutoScalingRunnerSet Controller calls the {% data variables.product.github %}'s API to fetch the runner group ID that the runner scale set will belong to.
+1. The AutoScalingRunnerSet Controller calls the API one more time to either fetch or create a runner scale set in the {% data variables.product.prodname_actions %} service before creating the Runner ScaleSet Listener resource.
 1. A Runner ScaleSet Listener pod is deployed by the AutoScalingListener Controller. In this pod, the listener application connects to the {% data variables.product.prodname_actions %} Service to authenticate and establish an HTTPS long poll connection. The listener stays idle until it receives a `Job Available` message from the {% data variables.product.prodname_actions %} Service.
-1. When a workflow run is triggered from a repository, the {% data variables.product.prodname_actions %} Service dispatches individual job runs to the runners or runner scale sets where the `runs-on` key matches the name of the runner scale set or labels of self-hosted runners.
+1. When a workflow run is triggered from a repository, the {% data variables.product.prodname_actions %} Service dispatches individual job runs to the runners or runner scale sets where the `runs-on` key matches the name of a runner scale set or the labels of a runner scale set or self-hosted runner.
 1. When the Runner ScaleSet Listener receives the `Job Available` message, it checks whether it can scale up to the desired count. If it can, the Runner ScaleSet Listener acknowledges the message.
 1. The Runner ScaleSet Listener uses a Service Account and a Role bound to that account to make an HTTPS call through the Kubernetes APIs to patch the Ephemeral RunnerSet resource with the number of desired replicas count.
 1. The Ephemeral RunnerSet attempts to create new runners and the EphemeralRunner Controller requests a Just-in-Time (JIT) configuration token to register these runners. The controller attempts to create runner pods. If the pod's status is `failed`, the controller retries up to 5 times. After 24 hours the {% data variables.product.prodname_actions %} Service unassigns the job if no runner accepts it.
@@ -71,7 +71,7 @@ Each resource that is deployed by ARC is given a name composed of:
 |-------|---------------|------|-----------------|-------------|-------|
 | `autoscalingrunnerset.yaml` | AutoscalingRunnerSet | INSTALLATION_NAME | 0 | Top level resource working with scale sets | The name is limited to 45 characters in length. |
 | `no_permission_service_account.yaml` | ServiceAccount | INSTALLATION_NAME-gha-rs-no-permission | 21 | Service account mounted to the runner container | This is created if the container mode is not "kubernetes" and `template.spec.serviceAccountName` is not specified. |
-| `githubsecret.yaml` | Secret | INSTALLATION_NAME-gha-rs-github-secret | 20 | Secret containing values needed to authenticate to the GitHub API | This is created if `githubConfigSecret` is an object. If a string is provided, this secret will not be created. |
+| `githubsecret.yaml` | Secret | INSTALLATION_NAME-gha-rs-github-secret | 20 | Secret containing values needed to authenticate to the {% data variables.product.github %} API | This is created if `githubConfigSecret` is an object. If a string is provided, this secret will not be created. |
 | `manager_role.yaml` | Role | INSTALLATION_NAME-gha-rs-manager | 15 | Role provided to the manager to be able to reconcile on resources in the autoscaling runner set's namespace  | This is always created. |
 | `manager_role_binding.yaml` | RoleBinding | INSTALLATION_NAME-gha-rs-manager | 15 | Binding manager_role to the manager service account.  | This is always created. |
 | `kube_mode_role.yaml` | Role | INSTALLATION_NAME-gha-rs-kube-mode | 17 | Role providing necessary permissions for the hook  | This is created when the container mode is set to "kubernetes" and `template.spec.serviceAccount` is not provided. |
@@ -176,6 +176,8 @@ The supported runner image is released as a separate container image, which you
 
 ## Next steps
 
+If you're new to ARC, see [AUTOTITLE](/actions/tutorials/use-actions-runner-controller/get-started) to try out the basics.
+
 When you're ready to use ARC to execute workflows, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/using-actions-runner-controller-runners-in-a-workflow).
 
 {% data reusables.actions.actions-runner-controller-labels %} See [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/using-self-hosted-runners-in-a-workflow).

diff --git a/.../actions/how-tos/deploy/configure-and-manage-deployments/control-deployments.md b/.../actions/how-tos/deploy/configure-and-manage-deployments/control-deployments.md
@@ -1,7 +1,7 @@
 ---
 title: Deploying with GitHub Actions
 shortTitle: Control deployments
-intro: Learn how to control deployments with features like environments and concurrency.
+intro: '{% data variables.product.prodname_actions %} gives you fine-grained control over deployments with environments, concurrency groups, and protection rules.'
 versions:
   fpt: '*'
   ghes: '*'
@@ -54,8 +54,54 @@ You can configure environments with protection rules and secrets. When a workflo
 
 Concurrency ensures that only a single job or workflow using the same concurrency group will run at a time. You can use concurrency so that an environment has a maximum of one deployment in progress and one deployment pending at a time. For more information about concurrency, see [AUTOTITLE](/actions/using-jobs/using-concurrency).
 
-> [!NOTE]
-> `concurrency` and `environment` are not connected. The concurrency value can be any string; it does not need to be an environment name. Additionally, if another workflow uses the same environment but does not specify concurrency, that workflow will not be subject to any concurrency rules.
+{% ifversion actions-environments-without-deployments %}
+
+## Using environments without deployments
+
+By default, when a workflow job references an environment, {% data variables.product.company_short %} creates a deployment object to track the deployment. You can opt out of deployment creation by setting `deployment` to `false` in the environment configuration. The valid values are `true` (default) and `false`. You can also use an expression, for example `deployment: {% raw %}${{ github.ref_name == 'main' }}{% endraw %}`.
+
+```yaml
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    environment:
+      name: staging
+      deployment: false
+    steps:
+      - name: run tests
+        env:
+          API_KEY: {% raw %}${{ secrets.API_KEY }}{% endraw %}
+        run: echo "Running tests with staging secrets"
+```
+
+When `deployment` is set to `false`:
+
+* The job has full access to environment secrets and variables.
+* No {% data variables.product.github %} deployment object is created—the deployment history for the environment is not updated.
+* Wait timer protection rules still apply—the job waits for the configured duration.
+* Required reviewers still apply—reviewers must still approve before the job runs.
+
+This is useful when you want to use environments for:
+
+* **Organizing secrets**—group related secrets under an environment name without creating deployment records.
+* **Access control**—restrict which branches can use certain secrets via environment branch policies, without deployment tracking.
+* **CI and testing jobs**—reference an environment for its configuration without adding noise to the deployment history.
+
+### Interaction with protection rules
+
+The `deployment` property controls which protection rules apply:
+
+| Protection rule | `deployment: true` (default) | `deployment: false` |
+|----------------|------------------------------|---------------------|
+| **None** | Deployment created, job runs | No deployment, job runs |
+| **Wait timer** | Wait timer enforced | Wait timer still enforced |
+| **Required reviewers** | Reviewers must approve | Reviewers must approve |
+| **Custom deployment protection rule app** | App webhook sent, must approve | **Job fails with error** |
+
+Custom deployment protection rules ({% data variables.product.prodname_github_apps %}) require a deployment object to function. If you set `deployment: false` on an environment that has custom deployment protection rules, the job will fail immediately with an annotation or error message explaining that the environment's protection rules are incompatible with `deployment: false`. Either remove `deployment: false` from your workflow, or remove the custom deployment protection rules from the environment.
+
+Note that `concurrency` and `environment` are not connected. The concurrency value can be any string; it does not need to be an environment name. Additionally, if another workflow uses the same environment but does not specify concurrency, that workflow will not be subject to any concurrency rules.
+{% endif %}
 
 For example, when the following workflow runs, it will be paused with the status `pending` if any job or workflow that uses the `production` concurrency group is in progress. It will also cancel any job or workflow that uses the `production` concurrency group and has the status `pending`. This means that there will be a maximum of one running and one pending job or workflow in that uses the `production` concurrency group.
 

diff --git a/...w-tos/deploy/configure-and-manage-deployments/create-custom-protection-rules.md b/...w-tos/deploy/configure-and-manage-deployments/create-custom-protection-rules.md
@@ -40,6 +40,12 @@ For general information about deployment protection rules, see [AUTOTITLE](/acti
 
 Once a workflow reaches a job that references an environment that has the custom deployment protection rule enabled, {% data variables.product.company_short %} sends a `POST` request to a URL you configure containing the `deployment_protection_rule` payload. You can write your deployment protection rule to automatically send REST API requests that approve or reject the deployment based on the `deployment_protection_rule` payload. Configure your REST API requests as follows.
 
+{% ifversion actions-environments-without-deployments %}
+
+Custom deployment protection rules are not compatible when a workflow job's environment is set to `deployment: false`. For more information, see [AUTOTITLE](/actions/how-tos/deploy/configure-and-manage-deployments/control-deployments#interaction-with-protection-rules).
+
+{% endif %}
+
 1. Validate the incoming `POST` request. For more information, see [AUTOTITLE](/webhooks-and-events/webhooks/securing-your-webhooks#validating-payloads-from-github).
 1. Use a JSON Web Token to authenticate as a {% data variables.product.prodname_github_app %}. For more information, see [AUTOTITLE](/apps/creating-github-apps/authenticating-with-a-github-app/authenticating-as-a-github-app#about-authentication-as-a-github-app).
 1. Using the installation ID from the `deployment_protection_rule` webhook payload, generate an install token. For more information, see [AUTOTITLE](/developers/apps/building-github-apps/authenticating-with-github-apps#authenticating-as-a-github-app).

diff --git a/content/actions/how-tos/manage-runners/index.md b/content/actions/how-tos/manage-runners/index.md
@@ -9,6 +9,7 @@ children:
   - /github-hosted-runners
   - /self-hosted-runners
   - /larger-runners
+  - /use-actions-runner-controller
   - /use-proxy-servers
 contentType: how-tos
 ---

diff --git a/content/actions/how-tos/manage-runners/self-hosted-runners/apply-labels.md b/content/actions/how-tos/manage-runners/self-hosted-runners/apply-labels.md
@@ -22,9 +22,6 @@ For information on how to use labels to route jobs to specific types of self-hos
 
 {% data reusables.actions.self-hosted-runner-management-permissions-required %}
 
-> [!NOTE]
-> Actions Runner Controller does not support multiple labels, to find out more please read our [Actions Runner Controller documentation](/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/about-actions-runner-controller#using-arc-runners-in-a-workflow)
-
 ## Creating a custom label
 
 You can create custom labels for runners at the repository{% ifversion ghec or ghes %}, organization, and enterprise{% else %} and organization{% endif %} levels.

diff --git a/content/actions/how-tos/manage-runners/self-hosted-runners/use-in-a-workflow.md b/content/actions/how-tos/manage-runners/self-hosted-runners/use-in-a-workflow.md
@@ -55,7 +55,7 @@ runs-on: [self-hosted, linux, ARM64]
 * `linux` - Only use a Linux-based runner.
 * `ARM64` - Only use a runner based on ARM64 hardware.
 
-To create individual self-hosted runners without the default labels, pass the `--no-default-labels` flag when you create the runner. Actions Runner Controller does not support multiple labels.
+To create individual self-hosted runners without the default labels, pass the `--no-default-labels` flag when you create the runner.
 
 ## Using custom labels to route jobs
 

diff --git a/...ner-controller/authenticate-to-the-api.md → ...ner-controller/authenticate-to-the-api.md b/...ner-controller/authenticate-to-the-api.md → ...ner-controller/authenticate-to-the-api.md
@@ -1,7 +1,7 @@
 ---
 title: Authenticating ARC to the GitHub API
 shortTitle: Authenticate to the API
-intro: Learn how to authenticate {% data variables.product.prodname_actions_runner_controller %} to the {% data variables.product.company_short %} API.
+intro: Authenticate {% data variables.product.prodname_actions_runner_controller %} to the {% data variables.product.company_short %} API.
 versions:
   fpt: '*'
   ghec: '*'
@@ -11,9 +11,8 @@ redirect_from:
   - /actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/authenticating-to-the-github-api
   - /actions/how-tos/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/authenticating-to-the-github-api#deploying-using-personal-access-token-classic-authentication
   - /actions/tutorials/actions-runner-controller/authenticating-arc-to-the-github-api
-contentType: tutorials
-category:
-  - Use and manage runners
+  - /actions/tutorials/use-actions-runner-controller/authenticate-to-the-api
+contentType: how-tos
 ---
 
 You can authenticate {% data variables.product.prodname_actions_runner_controller %} (ARC) to the {% data variables.product.prodname_dotcom %} API by using a {% data variables.product.prodname_github_app %} or by using a {% data variables.product.pat_v1 %}.