Merge branch 'main' into labeler

Author: Sharra-writes

CHANGELOG.md

@@ -1,5 +1,11 @@
 # Docs changelog
 
+**28 July 2025**
+
+We have restructured the general "[Billing and payments](https://docs.github.com/en/billing)" articles to align with the Copilot and Actions docs. In addition, we've combined a few old "About" articles to directly answer common questions that new users have: [How GitHub billing works](https://docs.github.com/en/billing/get-started/how-billing-works) and [Introduction to billing and licensing](https://docs.github.com/en/billing/get-started/introduction-to-billing).
+
+<hr>
+
 **16 July 2025**
 
 We've added documentation describing how to use the GraphQL API to create a new issue and, in the same request, assign the issue to Copilot coding agent.

assets/images/help/copilot/code-review/vscode-review-progress@2x.png

@@ -7,10 +7,15 @@ redirect_from:
   - /actions/hosting-your-own-runners/about-self-hosted-runners
   - /actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners
   - /actions/concepts/runners/about-self-hosted-runners
+  - /actions/hosting-your-own-runners
 versions:
   fpt: '*'
   ghes: '*'
   ghec: '*'
+contentType: concepts
+topics:
+  - CI
+  - CD
 ---
 
 A self-hosted runner is a system that you deploy and manage to execute jobs from {% data variables.product.prodname_actions %} on {% data variables.product.github %}.

assets/images/help/copilot/coding-agent/agents-page.png

@@ -22,6 +22,7 @@ redirect_from:
   - /actions/how-tos/hosting-your-own-runners
   - /actions/how-tos/managing-self-hosted-runners
   - /actions/how-tos/hosting-your-own-runners/managing-self-hosted-runners
+  - /github/automating-your-workflow-with-github-actions/hosting-your-own-runners
 ---
 
 {% data reusables.actions.enterprise-github-hosted-runners %}

assets/images/help/copilot/copilot-chat-in-repository.png

@@ -108,11 +108,8 @@ By default, the rate limit for {% data variables.product.prodname_actions %} is
 
 If the number of AJAX requests to your {% data variables.product.prodname_ghe_server %} instance causes problems, then you may need to edit the rate limit for the WebSockets controller used by these live updates. For details of how to view Alive requests, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/about-the-monitor-dashboards).
 
-By default, a maximum of 100 requests is allowed per minute for each IP address. Administrators with access to the administrative shell can use the [ghe-config](/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities#ghe-config) utility to set `app.github.web-sockets-rate-limit` with the number of requests allowed per minute for each IP address or disable this rate limit. Setting the limit to any value that is not a positive integer (for example, `0`, `-1`, `disabled`) disables rate limiting on the WebSockets controller for live updates.
+When primary rate limits are enabled, by default a maximum of 100 requests is allowed per minute for each IP address. Administrators with access to the administrative shell can use the [ghe-config](/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities#ghe-config) utility to set `app.github.web-sockets-rate-limit` with the number of requests allowed per minute for each IP address or disable this rate limit. Setting the limit to any value that is not a positive integer (for example, `0`, `-1`, `disabled`) disables rate limiting on the WebSockets controller for live updates.
 
 {% data reusables.github-connect.rate-limit-live-dotcom-requests %}
 
-> [!IMPORTANT]
-> This rate limit will not apply until you also enable the global rate limiter directly using `ghe-config app.github.rate-limiting-enabled 1` or indirectly by enabling rate limits for the {% data variables.product.prodname_enterprise_api %}](#enabling-rate-limits-for-the-github-enterprise-server-apis). When you enable the global rate limiter, other {% data variables.product.github %} features may also experience rate limits. Monitor your instance closely to check for any unexpected request rejections.
-
 After you make any changes to the values of these settings, run [ghe-config-apply](/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities#ghe-config-apply) to apply the settings.

content/actions/concepts/runners/self-hosted-runners.md

@@ -13,9 +13,6 @@ redirect_from:
   - /admin/user-management/managing-repositories-in-your-enterprise/accessing-user-owned-repositories-in-your-enterprise
 ---
 
-> [!NOTE]
-> Temporarily accessing user-owned repositories is currently in {% data variables.release-phases.public_preview %} for {% data variables.product.prodname_emus %} and subject to change.
-
 ## About temporary access to user-owned repositories
 
 If your enterprise uses {% data variables.product.prodname_emus %}, and you've allowed users to create repositories owned by their user accounts, you can temporarily access any user-owned repository within your enterprise.

content/actions/how-tos/manage-runners/self-hosted-runners/index.md

@@ -13,9 +13,6 @@ redirect_from:
   - /admin/user-management/managing-repositories-in-your-enterprise/viewing-user-owned-repositories-in-your-enterprise
 ---
 
-> [!NOTE]
-> Viewing user-owned repositories is currently in {% data variables.release-phases.public_preview %} for {% data variables.product.prodname_emus %} and subject to change.
-
 If your enterprise uses {% data variables.product.prodname_emus %}, and you've allowed users to create repositories owned by their user accounts, you can view all user-owned repositories within your enterprise.
 
 You can also temporarily access any user-owned repository. For more information, see [AUTOTITLE](/admin/user-management/managing-repositories-in-your-enterprise/accessing-user-owned-repositories-in-your-enterprise).

content/admin/configuring-settings/configuring-user-applications-for-your-enterprise/configuring-rate-limits.md

@@ -30,29 +30,33 @@ If you do hit a rate limit and need to retry an API request, use the `x-ratelimi
 
 ## Secure your app's credentials
 
-You can generate a private key and client secret for your {% data variables.product.prodname_github_app %}. With these credentials, your app can generate installation access tokens, user access tokens, and refresh tokens. These tokens can be used to make API requests on behalf of an app installation or user.
+You can generate a private key and client secret for your {% data variables.product.prodname_github_app %}. Private keys are used to generate installation access tokens, while client secrets are used to get user access tokens and refresh tokens. These tokens can be used to make API requests on behalf of an app installation or user.
 
-You must store these credentials securely. The storage mechanism depends on your integrations architecture and the platform that it runs on. In general, you should use a storage mechanism that is intended to store sensitive data on the platform that you are using.
+You must store private keys, tokens, and client secrets securely. However, the storage mechanism and its relative security depends on your integrations architecture and the platform that it runs on. In general, you should use a storage mechanism that is intended to store sensitive data on the platform that you are using.
 
 ### Private keys
 
-The private key for your {% data variables.product.prodname_github_app %} grants access to every account that the app is installed on.
+The private key for your {% data variables.product.prodname_github_app %} grants access to every account that the app is installed on. It **must** be stored securely and never shared broadly.
 
 Consider storing your {% data variables.product.prodname_github_app %}'s private key in a key vault, such as [Azure Key Vault](https://azure.microsoft.com/en-gb/products/key-vault), and making it sign-only.
 
 Alternatively, you can store the key as an environment variable. However, this is not as strong as storing the key in a key vault. If an attacker gains access to the environment, they can read the private key and gain persistent authentication as the {% data variables.product.prodname_github_app %}.
 
-You should never hard code your private key in your app, even if your code is stored in a private repository. If your app is a native client, client-side app, or runs on a user device (as opposed to running on your servers), you should never ship your private key with your app.
+You should never hard code your private key in your app, even if your code is stored in a private repository. If your app is a native client, client-side app, or runs on a user device (as opposed to running on your servers), you must never ship your private key with your app.
 
-You should not generate more private keys than you need. You should delete private keys that you no longer need. For more information, see [AUTOTITLE](/apps/creating-github-apps/authenticating-with-a-github-app/managing-private-keys-for-github-apps).
+You should not generate more private keys than you need. You should delete private keys that are no longer in use. For more information, see [AUTOTITLE](/apps/creating-github-apps/authenticating-with-a-github-app/managing-private-keys-for-github-apps).
 
 ### Client secrets
 
-Client secrets are used to generate user access tokens for your app, unless your app uses device flow. For more information, see [AUTOTITLE](/apps/creating-github-apps/authenticating-with-a-github-app/generating-a-user-access-token-for-a-github-app#using-the-device-flow-to-generate-a-user-access-token).
+Client secrets are required to generate user access tokens for your app, unless your app uses the device flow. For more information, see [AUTOTITLE](/apps/creating-github-apps/authenticating-with-a-github-app/generating-a-user-access-token-for-a-github-app#using-the-device-flow-to-generate-a-user-access-token).
 
-If your app is a website or web app, consider storing your client secret in a key vault, such as [Azure Key Vault](https://azure.microsoft.com/products/key-vault), or as an encrypted environment variable or secret on your server.
+If your app is a confidential client, meaning it can safely keep the client secret secure, consider storing your client secret in a key vault, such as [Azure Key Vault](https://azure.microsoft.com/products/key-vault), or as an encrypted environment variable or secret on your server.
 
-If your app is a native client, client-side app, or runs on a user device (as opposed to running on your servers), you cannot secure your client secret. You should use caution if you plan to gate access to your own services based on tokens generated by your app because anyone can access the client secret to generate a token.
+If your app is a public client (a native app that runs on the user's device, CLI utility, or single-page web application), you cannot secure your client secret. You will have to ship the client secret in the application's code, and you should use PKCE to better secure the authentication flow. You should use caution if you plan to gate access to your own services based on tokens generated by your app because public clients are trivially spoofable - anyone can reuse your app's client ID to sign in.
+
+#### Don't enable device flow without reason
+
+It is preferable to use the authorization code with PKCE over the device flow, if you are concerned about using the client secret in a public client. The device flow does not require redirect URIs at all, which means that an attacker can use the device flow to remotely impersonate your app as part of a phishing attack. For this reason, do not enable the device flow for your application unless you are using the app in a constrained environment (CLIs, IoT devices, or headless systems).
 
 ### Installation access tokens, user access tokens, and refresh tokens