Add plugins concept page and integrate plugin references across docs (#16406)

This change introduces a new concept page explaining Pulumi's plugin architecture and updates related documentation to reference it. The plugins page covers all five plugin types (resource, language, analyzer, converter, and tool plugins), installation and management, and implementation details.

Related documentation updates:
- how-pulumi-works.md: Add reference to language plugins
- providers.md: Explain providers as resource plugins
- converters.md: Reference converter plugins and clarify standalone tools
- policy/_index.md: Reference analyzer plugins

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Author: jkodroff

content/docs/iac/concepts/how-pulumi-works.md

@@ -34,7 +34,7 @@ In the next section, we will describe each of these components and see how they
 
 ## Language hosts
 
-The _language host_ is responsible for running a Pulumi program and setting up an environment where it can register resources with the _deployment engine_. The language host consists of two different pieces:
+The _language host_ is responsible for running a Pulumi program and setting up an environment where it can register resources with the _deployment engine_. Language hosts are implemented via [plugins](/docs/iac/concepts/plugins/) (specifically, language plugins). The language host consists of two different pieces:
 
 1. A language executor, which is a binary named `pulumi-language-<language-name>`, that Pulumi uses to launch the runtime for the language your program is written in (e.g. Node or Python). This binary is distributed with the Pulumi CLI.
 2. A language SDK is responsible for preparing your program to be executed and observing its execution in order to detect resource registrations. When a resource is _registered_ (via `new Resource()` in JavaScript or `Resource(...)` in Python), the language SDK communicates the registration request back to the _deployment engine_. The language SDK is distributed as a regular package, just like any other code that might depend on your program. For example, the Node SDK is contained in the [`@pulumi/pulumi`](https://www.npmjs.com/package/@pulumi/pulumi) package available on npm, and the Python SDK is contained in the [`pulumi`](https://pypi.org/project/pulumi/) package available on PyPI.

content/docs/iac/concepts/plugins.md

@@ -0,0 +1,108 @@
+---
+title_tag: Plugins
+meta_desc: Learn about Pulumi plugins, the core extensibility mechanism that enables Pulumi to work with cloud providers, languages, and tools.
+title: Plugins
+h1: Plugins
+meta_image: /images/docs/meta-images/docs-meta.png
+menu:
+    iac:
+        name: Plugins
+        parent: iac-concepts
+        weight: 140
+    concepts:
+        weight: 140
+---
+
+{{% notes type="info" %}}
+Most Pulumi users don't need to understand plugins in depth, as most plugin installation and management happens automatically.
+
+If you're interested in learning more about Pulumi internals, see the [Pulumi Developer Documentation](https://pulumi-developer-docs.readthedocs.io/latest/docs/architecture/plugins.html).
+{{% /notes %}}
+
+Plugins are Pulumi's core extensibility mechanism, allowing the Pulumi engine to communicate in a uniform manner with various languages, resource providers, and other tools. Plugins always run as separate processes and mostly use gRPC for communication with the Pulumi engine.
+
+## Plugin types
+
+Pulumi supports five categories of plugins:
+
+### Resource plugins
+
+Resource plugins (also known as [providers](/docs/iac/concepts/resources/providers/)) expose standardized interfaces for managing cloud resources. A listing of providers is available in the [Pulumi Registry](/registry/).
+
+When you first run `pulumi preview` or `pulumi up`, the Pulumi CLI will install any required providers that are not already in your plugin cache.
+
+### Language plugins
+
+Language plugins (also known as language hosts) host programs written in specific languages, enabling the Pulumi engine to execute your Pulumi code without understanding language-specific details. As described in [How Pulumi works](/docs/iac/concepts/how-pulumi-works/#language-hosts), language plugins consist of:
+
+1. A language executor binary named `pulumi-language-<language-name>`, which Pulumi uses to launch the runtime for your program's language (e.g., Node.js or Python). This binary is distributed with the Pulumi CLI.
+1. For all languages except YAML, a language SDK that prepares your program for execution and observes resource registrations.
+
+Pulumi-supported language plugins are installed automatically with the Pulumi CLI. Community-supported language plugins can be installed separately.
+
+### Analyzer plugins
+
+Analyzer plugins scan Pulumi programs for potential issues and power [Pulumi Policy as Code](/docs/insights/policy/). These plugins enable you to enforce compliance, security, and best practices across your infrastructure.
+
+Policy plugins are installed automatically with the Pulumi CLI.
+
+### Converter plugins
+
+Converter plugins transform existing infrastructure-as-code from other tools (like Terraform, Kubernetes YAML, or CloudFormation) into Pulumi programs. Learn more about [conversion tools](/docs/iac/guides/migration/converters/).
+
+Converter plugins are installed automatically with the Pulumi CLI when you run the [`pulumi convert`](/docs/iac/cli/commands/pulumi_convert) command.
+
+### Tool plugins
+
+Tool plugins enable integration between Pulumi and external tools, extending Pulumi's capabilities to work with your existing workflows and toolchains.
+
+## Plugin installation and management
+
+### Automatic installation
+
+The Pulumi CLI normally handles plugin installation automatically. For example:
+
+- **Resource plugins** (provider binaries) are installed automatically when you first run `pulumi preview` or `pulumi up` if they are not already present in the plugin cache
+- **Language plugins** are installed with the Pulumi CLI
+- **Policy plugins** are installed with the Pulumi CLI
+- The Pulumi CLI ensures your resource plugins are present when you run your Pulumi program
+
+### Manual installation
+
+Most users will not need to run the [`pulumi plugin install`](/docs/iac/cli/commands/pulumi_plugin_install/) command manually. However, manual plugin installation can be useful for scenarios like:
+
+- Pre-loading plugins on a custom Docker image to speed up CI/CD pipelines
+- Working in air-gapped environments
+- Testing pre-release versions of plugins
+- Installing plugins that are community-maintained
+
+### Plugin storage
+
+Plugins are stored in different locations depending on their type:
+
+- All plugins that ship with the Pulumi CLI, including all of our supported **Language plugins** and **policy plugins** are stored in `~/.pulumi/bin`
+- All plugins that are installed by the user, whether explicitly or automatically by the Pulumi CLI, are cached in `~/.pulumi/plugins`
+
+### Plugin management commands
+
+You can manage your local plugin cache using the following CLI commands:
+
+- [`pulumi plugin ls`](/docs/iac/cli/commands/pulumi_plugin_ls/) - List installed plugins
+- [`pulumi plugin rm`](/docs/iac/cli/commands/pulumi_plugin_rm/) - Remove cached plugins
+- [`pulumi plugin install`](/docs/iac/cli/commands/pulumi_plugin_install/) - Manually install a plugin
+
+## Plugin implementation details
+
+Plugins are deployed through two approaches:
+
+- **Executables** following the naming convention `pulumi-<kind>-<name>` (e.g., `pulumi-resource-aws`)
+- **Directory-based plugins** containing a `PulumiPlugin.yaml` configuration file, where the engine uses the specified runtime to execute the plugin through the language plugin's interface
+
+For more details about Pulumi plugin architecture and how to contribute to plugin development, see the [Pulumi Developer Documentation](https://pulumi-developer-docs.readthedocs.io/latest/docs/architecture/plugins.html).
+
+## Related topics
+
+- [Providers](/docs/iac/concepts/resources/providers/) - Learn more about resource plugins (providers)
+- [How Pulumi works](/docs/iac/concepts/how-pulumi-works/) - Understand how plugins fit into Pulumi's architecture
+- [Policy as Code](/docs/insights/policy/) - Learn about analyzer plugins for policy enforcement
+- [Conversion tools](/docs/iac/guides/migration/converters/) - Use converter plugins to migrate from other IaC tools

content/docs/iac/concepts/resources/providers.md

@@ -21,6 +21,10 @@ A resource provider handles communications with a cloud or SaaS service to creat
 
 Providers are composed of two parts: an executable, which makes the actual call to the cloud provider's API, and an SDK, which allows you to consume the provider in the language of your Pulumi program. When you run your Pulumi program, Pulumi passes your code to a language host such as Node.js, waits to be notified of resource registrations, assembles a model of your desired state, and calls on the provider executable to produce that state. The resource provider translates those requests into API calls to the cloud service.
 
+{{% notes type="info" %}}
+Providers are a specific type of [plugin](/docs/iac/concepts/plugins/) called a resource plugin. For more information about plugins and how they work in Pulumi, see the [plugins concept page](/docs/iac/concepts/plugins/).
+{{% /notes %}}
+
 ## Installing Providers
 
 There are two methods for installing a provider and using it in your Pulumi program:
@@ -38,7 +42,7 @@ The most common method of installing a provider is to use your language's packag
 - .NET: `Pulumi.Aws`
 - Java: `com.pulumi.aws`
 
-After installing the provider using your package manager, you reference the provider in your Pulumi program to define the desired state of the resources for that provider. When you install the SDK for a provider (e.g., via `npm install <package_name>` in Node.js), the package manager (npm in this example) automatically downloads and installs the provider executable along with the SDK if the executable is not already cached on your system.
+After installing the provider using your package manager, you reference the provider in your Pulumi program to define the desired state of the resources for that provider. When you first run `pulumi preview` or `pulumi up`, the Pulumi CLI will install any required providers that are not already in your plugin cache.
 
 ### Installing a Parameterized Provider via `pulumi package add`
 

content/docs/iac/guides/migration/converters.md

@@ -16,7 +16,7 @@ aliases:
 - /docs/iac/adopting-pulumi/converters/
 ---
 
-The `pulumi convert` command allows you translate supported sources to the various [languages that Pulumi supports](/docs/languages-sdks/), such as TypeScript, JavaScript, Go, Python, C#, or Java.). Conversion sources are supported via a plugin model, and include other IaC tools like Terraform. Pulumi YAML programs can also be converted to any other supported Pulumi language.
+The `pulumi convert` command allows you to translate supported sources to the various [languages that Pulumi supports](/docs/languages-sdks/), such as TypeScript, JavaScript, Go, Python, C#, or Java. Conversion sources are supported via [Pulumi plugins](/docs/iac/concepts/plugins/#converter-plugins), and include the ability to convert code from other IaC tools like Terraform and Azure Bicep. Pulumi YAML programs can also be converted to any other supported Pulumi language.
 
 For the detailed usage of this command and options, refer to the [pulumi convert CLI documentation.](https://www.pulumi.com/docs/cli/commands/pulumi_convert/)
 
@@ -39,17 +39,14 @@ For the detailed usage of this command and options, refer to the [pulumi convert
 
 ### Use cases for using pulumi convert
 
-The `pulumi convert` subcommand is designed to address a variety of migration and conversion scenarios where IaC practices evolve alongside your project needs. Here are some common use cases:
+The `pulumi convert` command is designed to address a variety of migration and conversion scenarios where IaC practices evolve alongside your project needs. Here are some common use cases:
 
 * **Migrating from other IaC tools:** If you're looking to transition your infrastructure definitions from tools like Terraform, Bicep, or ARM templates into Pulumi.
 * **Converting from Pulumi YAML:** If you started your project with Pulumi YAML and find your requirements have evolved, you can convert and take advantage of the benefits offered by popular programming languages, such as complex logic capabilities and the flexibility to create modular and reusable components.
 
 ### Additional conversion tools and resources
 
-The following list of web-based tools and resources can quickly help you convert your source IaC languages or formats for use with the `pulumi convert --from` command. The resulting file can be copied or downloaded for use with a [new Pulumi project](/docs/get-started/).
+In addition to the converter plugins, Pulumi offers the following standalone tools for converting code from other IaC tools to Pulumi:
 
-* [Terraform to Pulumi](/tf2pulumi/)
-* [ARM to Pulumi](/arm2pulumi)
 * [Kubernetes CustomResources to Pulumi](/blog/introducing-crd2pulumi/)
 * [CloudFormation to Pulumi](/cf2pulumi/)
-* [Kubernetes YAML to Pulumi](/kube2pulumi/)

content/docs/insights/policy/_index.md

@@ -22,6 +22,10 @@ aliases:
 
 Pulumi Policy empowers you to set guardrails to enforce compliance across your entire cloud infrastructure—whether resources are managed by Pulumi IaC, provisioned by other tools like Terraform or CloudFormation, or created manually. Using Policy as Code, you can write flexible business and security policies that protect your organization.
 
+{{% notes type="info" %}}
+Policy as Code is implemented via [analyzer plugins](/docs/iac/concepts/plugins/#analyzer-plugins), which are installed automatically with the Pulumi CLI.
+{{% /notes %}}
+
 Policy enforcement works in two modes:
 
 - **Preventative policies**: Block non-compliant resources before deployment, enforcing compliance on Pulumi stack updates