- Deployment Engine
- Dynamic Providers
- IdP Metadata XML
- Language Executor
- Language Host
- Project File
- Pulumi Service
- Resource Args
- Resource Plugin
- Resource Provider
- Runtime Code
- Secrets Encryption
- Stack Output
- Stack Reference
- Stack Tags
Application Programming Interface. Pulumi offers APIs for working with a wide variety of cloud platforms, as well as higher-level APIs that make it easier to deliver cloud applications and infrastructure.
A checkpoint is recorded by Pulumi at various points so that it can operate reliably—whether that means diffing goal state versus current state during an update, recovering from failure, or destroying resources accurately to clean up afterwards.
Command-line Interface. The Pulumi CLI is open source and works in conjunction with the Pulumi service to deploy changes to your cloud apps and infrastructure.
A Pulumi component is a logical group of resources that contains other components and physical cloud resources.
Configuration values are always stored as strings, but can be parsed as richly typed values. You may set and get configuration values via the CLI or by using the Config object.
The deployment engine is responsible for computing the set of operations needed to drive the current state of your infrastructure into the desired state expressed by your program.
Dynamic Providers are a flexible and low-level mechanism to plug arbitrary code directly into the deployment process. It is currently in preview.
IdP stands for Identity Provider. A Security Assertion Markup Language (SAML) IdP is a service that acts as a user directory.
IdP Metadata XML
IdP Metadata XML is the XML configuration document provided by your Security Assertion Markup Language (SAML) IdP. It contains public information about your user directory, which can be used by the service provider to make authentication requests.
A language executor is a binary named pulumi-language-<language-name>, that Pulumi uses to launch the runtime for the the language your program is written in (e.g. Node or Python). This binary is distributed with the Pulumi CLI.
The language host is responsible for running a Pulumi program and setting up an environment where it can register resources with the deployment engine.
An organization is the primary grouping unit for stacks within the Pulumi Service.
Outputs are a key part of how Pulumi tracks dependencies between resources. Because the values of Outputs are not available until resources are created, these are represented using the special Output type.
Pulumi packages are normal NPM or Python packages. They transitively depend on @pulumi/pulumi which defines how resources created by a Pulumi program will be communicated to the Pulumi engine. The ability to register resources with the Pulumi engine is the only difference between a Pulumi package and any other NPM package.
When your Pulumi program references resources in the local filesystem, they are always relative to the working directory.
A Pulumi project is any folder which contains a Pulumi.yaml file.
The Pulumi.yaml project file specifies metadata about your project.
The Pulumi Service refers to the web application at `app.pulumi.com` which automatically manages deployment state and enables collaboration between developers and operators.
The args provided to a resource determine what inputs will be used to initialize the resource. These can be either raw values or outputs from other resources.
A resource plugin is the binary used by the deployment engine to manage a resource.
A Pulumi resource provider consists of two different pieces: a resource plugin and an SDK.
All resources have a name, which must be unique in the Pulumi program.
Security Assertion Markup Language. You may use a SAML 2.0-compatible identity provider in order to sign in to the Pulumi Service via single sign-on. The SAML SSO feature is only available in Pulumi Enterprise.
A Pulumi Software Development Kit (SDK) provides bindings for each type of resource that the provider can manage.
The Pulumi CLI and programming model offer ways for you to encrypt configuration values with the --secret flag or by programmatically wrapping it as a secret at runtime.
The Pulumi Service automatically manages per-stack encryption keys on your behalf. Anytime you encrypt a value using --secret or by programmatically wrapping it as a secret at runtime, a secure protocol is used between the CLI and Pulumi Service that ensures secret data is encrypted in transit, at rest, and physically anywhere it gets stored.
Self-hosted in Pulumi applies to on-premise "behind a firewall" scenarios, as well as environments hosted within your own AWS, Azure, or GCP account.
SP stands for Service Provider. A Security Assertion Markup Language (SAML) service provider relies on an identity provider for authentication.
A stack is an isolated, independently configurable instance of a Pulumi program. Stacks are commonly used to denote different phases of development (such as development, staging and production) or feature branches (such as feature-x-dev, jane-feature-x-dev).
A stack output is a value exported from a stack. A stack’s outputs can be easily retrieved from the Pulumi CLI and are displayed on pulumi.com.
Stack references provide a way to access the outputs of one stack from another stack.
Stacks have associated metadata in the form of tags, with each tag consisting of a name and value. Stack tags are only supported when logged into the Pulumi Service backend.
Pulumi stores its own copy of the current state of your infrastructure. This is often simply called state, and is stored in transactional snapshots we call checkpoints.