diff --git a/website/content/docs/internals/limits.mdx b/website/content/docs/internals/limits.mdx
index 4db0ca7a9..0a647e33f 100644
--- a/website/content/docs/internals/limits.mdx
+++ b/website/content/docs/internals/limits.mdx
@@ -285,3 +285,21 @@ The current number of unexpired leases can be monitored via the
 The Transform secret engine obeys the [FF3-1 minimum and maximum sizes
 on the length of an input](/docs/secrets/transform#input-limits), which
 are a function of the alphabet size.
+
+### External plugin limits
+
+The [plugin system](/docs/internals/plugins) launches a separate process
+initiated by Vault that communicates over RPC. For each secret engine and auth
+method that's enabled as an external plugin, Vault will spawn a process on the
+host system. For the Database Secrets Engines, external database plugins will
+spawn a process for every configured connection.
+
+Regardless of plugin type, each of these processes will incur resource overhead
+on the system, including but not limited to resources such as CPU, memory,
+networking, and file descriptors. There's no specific limit on the number
+secrets engines, auth methods, or database configured connections that can be
+enabled. This ultimately depends on the particular plugin resource utilization,
+the extent to which that plugin is being called, and the available resources on
+the system. For plugins of the same type, each additional process will incur a
+roughly linear increase in resource utilization. This assumes the usage of each
+plugin of the same type is similar.
diff --git a/website/content/docs/internals/plugins.mdx b/website/content/docs/internals/plugins.mdx
index 889f4fa48..74c6f3892 100644
--- a/website/content/docs/internals/plugins.mdx
+++ b/website/content/docs/internals/plugins.mdx
@@ -37,6 +37,33 @@ It is possible to enable a custom plugin with a name that's identical to a
 built-in plugin. In such a situation, Vault will always choose the custom plugin
 when enabling it.
 
+## Plugin Lifecycle
+
+Vault plugins are long-running processes that remain running once they are
+spawned by Vault, the parent process. Plugin processes can be started by Vault's
+active node and performance standby nodes. Additionally, there are cases where
+plugin processes may be terminated by Vault. These cases include but are not
+limited to:
+
+- Vault active node step-down
+- Vault barrier seal
+- Vault graceful shutdown
+- Disabling a Secrets Engine or Auth method that uses external plugins
+- Database configured connection deletion
+- Database configured connection update
+- Database configured connection reset request
+- Database root credentials rotation
+- WAL Rollback from a previously failed root credentials rotation operation
+
+The lifecycle of plugin processes are managed automatically by Vault.
+Termination of these processes are typical in certain scenarios, such as the
+ones listed above. Vault will start plugin processes when needed, typically by
+lazily loading the plugin when a request that requires the plugin is received by
+Vault. A plugin process may be started or terminated through other internal
+processes within Vault as well. Since Vault manages and tracks the lifecycle of
+its plugins, these processes should not be terminated by anything other than
+Vault.
+
 ## Plugin Communication
 
 Vault creates a mutually authenticated TLS connection for communication with the