sourcegraph · eseliger · Aug 14, 2025 · Aug 14, 2025
diff --git a/docs/admin/access_control/index.mdx b/docs/admin/access_control/index.mdx
@@ -9,9 +9,7 @@
 
 <Callout type="info">This feature is in Beta stage.</Callout>
 
-> NOTE: This page refers to in-product permissions, which determine who can, for example, create a batch change, or who is a site admin. This is *not* the same as [repository permissions](/admin/permissions/), which enforces the same repository access on Sourcegraph as your code host.
-
-> NOTE: Feature supported on Sourcegraph versions 5.0+
+<Callout type="note">This page refers to in-product permissions, which determine who can, for example, create a batch change, or who is a site admin. This is *not* the same as [repository permissions](/admin/permissions/), which enforces the same repository access on Sourcegraph as your code host.</Callout>
 
 Sourcegraph uses [Role-Based Access Control (RBAC)](https://en.wikipedia.org/wiki/Role-based_access_control) to enable fine-grained control over different features and abilities of Sourcegraph, without having to modify permissions for each user individually. Currently, the scope of permissions control is limited to [Batch Changes](/admin/access_control/batch_changes) functionality, but it will be expanded to other areas in the future.
 
@@ -46,13 +44,13 @@ You can read about the specific permission types available for each RBAC-enabled
 
 ### Deleting a role
 
-> NOTE: Built-in system roles cannot be deleted.
+<Callout type="note">Built-in system roles cannot be deleted.</Callout>
 
 To delete a role, click the **Delete** button on it. You will be prompted to confirm your choice. Once deleted, all users previously assigned that role will lose all permissions associated with it. Be aware, though, that the same permissions could still be granted by their other roles.
 
 ## Managing user roles
 
-> NOTE: Built-in system roles cannot be assigned this way.
+<Callout type="note">Built-in system roles cannot be assigned this way.</Callout>
 
 Site admins can manage which roles are assigned to which users from **Site admin > Users & auth > Users**. To view or edit a user's roles, click the triple dots to open the context menu for that user, then click **Manage roles**. This will open a modal dialog where you can see the user's current roles, assign new ones, or unassign current ones. You can type in the input field to search roles by name. Click **Update** to save any changes, or **Cancel** to discard. Note that system roles cannot be revoked or assigned via this modal.
 

diff --git a/docs/admin/config/batch_changes.mdx b/docs/admin/config/batch_changes.mdx
@@ -4,14 +4,10 @@ Batch Changes is generally configured through the same [site configuration](/adm
 
 ## Access control
 
-<Callout type="note"> Feature supported only in Sourcegraph versions 5.0 or more.</Callout>
-
 Batch Changes is [RBAC-enabled](/admin/access_control/) <span class="badge badge-beta">Beta</span>. By default, all users have full read and write access for Batch Changes, but this can be restricted by changing the default role permissions, or by creating new custom roles.
 
 ### Enable organization members to administer
 
-<Callout type="note"> Feature supported only in Sourcegraph versions 5.0.5 or more.</Callout>
-
 By default, only a batch change's author or a site admin can administer (apply, close, rename, etc.) a batch change. However, admins can use [organizations](/admin/organizations) to facilitate closer collaboration and shared administrative control over batch changes by enabling the `orgs.allMembersBatchChangesAdmin` setting for an organization. When enabled, members of the organization will be able to administer all batch changes created in that organization's namespace. Batch changes created in other namespaces (user or organization) will still be restricted to the author and site admins.
 
 ## Rollout windows
@@ -133,14 +129,10 @@ To only allow changesets to be reconciled at 1 changeset per minute on (UTC) wee
 
 ## Incoming webhooks
 
-<Callout type="note"> Feature supported only in Sourcegraph versions 3.33 or more.</Callout>
-
 Sourcegraph can track incoming webhooks from code hosts to more easily debug issues with webhook delivery. Learn [how to setup webhooks and configure logging](/admin/config/webhooks/incoming#webhook-logging).
 
 ## Forks
 
-<Callout type="note"> Feature supported only in Sourcegraph versions 3.36 or more.</Callout>
-
 Sourcegraph can be configured to push branches created by Batch Changes to a fork of the repository, rather than the repository itself, for example if users of your code host typically do not have push access to the original repository. You can enable pushing to forks globally with the `batchChanges.enforceForks` site configuration option. Users can also indicate they do or do not want to push to forks for an individual batch change by specifying the property `changesetTemplate.fork` in their batch spec. If the batch spec property is present, it will override the site configuration option. See the [batch spec YAML reference](/batch-changes/batch-spec-yaml-reference#changesettemplatefork) for more information.
 
 The fork will be created in the namespace of the user publishing the changeset, or the namespace of the service account if [global service account](/batch-changes/configuring-credentials#global-service-account-tokens) is in use. The name of the fork Sourcegraph creates will be prefixed with the name of the original repo's namespace in order to prevent potential repo name collisions. For example, a batch spec targeting `github.com/my-org/project` would create or use any existing fork by the name `github.com/user/my-org-project`.
@@ -157,8 +149,6 @@ To enable forks, update the site configuration to include:
 
 ## Automatically delete branches on merge/close
 
-<Callout type="note"> Feature supported only in Sourcegraph versions 5.1 or more.</Callout>
-
 Sourcegraph can be configured to automatically delete branches created for Batch Changes changesets when changesets are merged or closed by enabling the `batchChanges.autoDeleteBranch` site configuration option.
 
 When enabled, Batch Changes will override any setting on the repository on the code host itself and attempt to remove the source branch of the changeset when the changeset is merged or closed. This is useful for keeping repositories clean of stale branches.
@@ -305,8 +295,6 @@ Installation access tokens are short-lived, non-refreshable tokens that give Sou
 
 ### Rejecting Unverified Commits
 
-<Callout type="note"> Feature supported only in Sourcegraph versions 5.2.4 or more.</Callout>
-
 Admins can configure Batch Changes to error when it creates commits that are not signed. This can be done by enabling the `batchChanges.rejectUnverifiedCommits` setting in the site configuration:
 
 ```json

diff --git a/docs/admin/config/email.mdx b/docs/admin/config/email.mdx
@@ -7,7 +7,7 @@ Sourcegraph uses an SMTP server of your choosing to send emails for:
 - Important updates to a user accounts (for example, creation of API keys)
 - For [`builtin` authentication](/admin/auth/#builtin-password-authentication), password resets and email verification
 
-> NOTE: Sourcegraph Cloud customers can take advantage of mananged SMTP servers - [learn more](/cloud/#managed-smtp).
+<Callout type="note">Sourcegraph Cloud customers can take advantage of mananged SMTP servers - [learn more](/cloud/#managed-smtp).</Callout>
 
 ## User email verification
 
@@ -25,7 +25,7 @@ To verify their email address, the user can do one of the following:
 
 Users with emails [created by the site admin](/admin/auth/#creating-builtin-authentication-users) through the `/site-admin/users/new` UI will have the same behaviour as the above. Users created directly through GraphQL or the `src` CLI assume that the email provided is verified.
 
-> Note: For SSO (Single Sign-On) enabled instances, it is important to remove the basic authentication method from the `auth.providers` list to prevent users from receiving password reset links. This is because users do not need passwords to log in to SSO-enabled instances. Prior to disabling the basic authentication method, please ensure that there is at least one administrator account capable of signing in via SSO. This is essential because once basic authentication is disabled, the username/password combination used to create the initial admin account will no longer be functional.
+<Callout type="note">For SSO (Single Sign-On) enabled instances, it is important to remove the basic authentication method from the `auth.providers` list to prevent users from receiving password reset links. This is because users do not need passwords to log in to SSO-enabled instances. Prior to disabling the basic authentication method, please ensure that there is at least one administrator account capable of signing in via SSO. This is essential because once basic authentication is disabled, the username/password combination used to create the initial admin account will no longer be functional.</Callout>
 
 ## Configuring Sourcegraph to send email via Amazon AWS / SES
 

diff --git a/docs/admin/config/network-filtering.mdx b/docs/admin/config/network-filtering.mdx
@@ -1,9 +1,11 @@
-# Outoing Connection Filtering
+# Outgoing Connection Filtering
+
 Sourcegraph supports outbound connection filtering. Both for regular external connections and so-called "untrusted" connections, where a regular user can provide a URL to make an outbound connection to.
 
 The allow- and denylist support a comma separated list of IP ranges, hostnames and keywords. To block or allow all the internal connections use the “private” keyword, this would block all RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and RFC 4193 (FC00::/7) IP addresses. Keywords can be combined with ranges and IP addresses so it's very customizable.
 
 ## Trusted External Connections
+
 It’s possible for the Sourcegraph instance to deny access to external hosts by setting the environment variable `EXTERNAL_DENY_LIST` on the deployment.
 
 The default denylist is set up to only block localhost and the Cloud metadata service IP address. Expanding the denylist could interfere with internal authentication providers, and they might need to be excluded from the denylist.
@@ -19,14 +21,17 @@ EXTERNAL_DENY_LIST="private,github.com"
 This would deny all connections to hosts in the private network and github.com.
 
 ## Untrusted External Connections
+
 Codemonitors, webhooks and Cody URL context are limited to only be able to access public IP addresses by default. This behavior can be changed with the `UNTRUSTED_EXTERNAL_ALLOW_LIST` environment variable, which configures the allowlist.
 
 ### Example Configuration
+
 If you want Cody to use context from an internal server in addition to internet access, you can add the internal server's IP address to the allowlist:
 
 ```
 UNTRUSTED_EXTERNAL_ALLOW_LIST="external,192.168.1.53"
 ```
 
 ## Implementation Details
+
 To achieve this, we use [gitea's hostmatcher](https://github.com/go-gitea/gitea/blob/v1.22.6/modules/hostmatcher/hostmatcher.go#L39). This is configured by default for the `ExternalClient`, which is used for all external requests. The common options and configuration can be found [here](https://github.com/sourcegraph/sourcegraph-public-snapshot/blob/main/internal/httpcli/client.go#L406C1-L423C2).
diff --git a/docs/admin/config/site_config.mdx b/docs/admin/config/site_config.mdx
@@ -1251,6 +1251,7 @@ All site configuration options and their default values are shown below.
 }
 ```
 {/* SCHEMA_SYNC_END: admin/config/site.schema.json */}
+
 #### Known bugs
 
 The following site configuration options require the server to be restarted for the changes to take effect:
@@ -1267,7 +1268,6 @@ permissions.syncUsersMaxConcurrency
 
 If you are having trouble accessing the web UI, you can make edits to your site configuration by editing the configuration directly.
 
-
 ### Sourcegraph with Docker Compose and single-server Sourcegraph with Docker
 
 Set `FRONTEND_CONTAINER` to: