The transition from a managed SaaS model to a self-hosted infrastructure is a critical strategic pivot for organizations prioritizing data sovereignty, strict regulatory compliance, and absolute environmental control. The self-hosted version of the Pulumi Service provides a robust alternative to the standard managed cloud offering found at app.pulumi.com, effectively transplanting the entire state management and governance engine into a private network. This architectural shift allows an enterprise to maintain the full suite of Pulumi's cloud engineering capabilities—including sophisticated state management, granular role-based access controls (RBAC), and rigorous policy-as-code compliance guardrails—while ensuring that no metadata or state information ever leaves the organization's boundary. For entities operating within highly regulated sectors such as finance, healthcare, or government, this capability is not merely a preference but a fundamental requirement to meet jurisdictional data residency laws and security mandates.
Enterprise Licensing and Availability
The availability of self-hosted Pulumi is strictly tied to specific enterprise-tier licensing agreements. Unlike the open-source Pulumi CLI, the backend service required for remote state management and the graphical management interface is a proprietary offering.
Self-hosting is exclusively available to users of the Pulumi Enterprise Edition. Specifically, it is offered as an additional license for the Business Critical Edition of Pulumi. This licensing structure ensures that organizations receiving the self-hosted binaries also have access to the necessary enterprise support and architectural guidance required to maintain a production-grade deployment.
For organizations currently evaluating the feasibility of this move, Pulumi provides the capability to initiate a guided Proof of Concept (PoC). This process involves collaborating with a Pulumi solutions architect to determine the optimal deployment strategy and ensure that the self-hosted instance meets the specific performance and security needs of the organization before a full commercial commitment is made.
Comparative Analysis: Self-Hosted vs. Managed Service
While the managed Pulumi Cloud (app.pulumi.com) handles the operational overhead of the backend, the self-hosted version shifts the responsibility of the "undifferentiated heavy lifting" to the internal DevOps or Platform Engineering team.
The self-hosted version is designed to provide full control of data. In the managed version, Pulumi manages the database and object storage. In the self-hosted version, all data—including stack state, user accounts, and audit logs—is stored in a MySQL database and an encrypted object store located entirely within the customer's own network. This eliminates the risk of third-party data breaches at the service provider level and satisfies mandates for air-gapped communications.
Furthermore, the self-hosted installation enables true air-gapped operation. This means the entire ecosystem can function with zero communication to the public internet. This is a critical requirement for FedRAMP-compliant environments or top-secret government networks where any external outbound request is flagged as a security violation. In contrast, the managed service requires an active internet connection to communicate with the Pulumi Cloud API.
The trade-off for this control is the operational burden. Users of the self-hosted version are solely responsible for:
- Data Backups: Implementing a redundant backup strategy for both the MySQL database and the object storage volumes.
- Service Availability: Monitoring the health of the API and Console containers and ensuring high availability (HA) across availability zones.
- Lifecycle Management: Coordinating and applying updates to the service binaries and database schemas.
Core System Architecture and Components
The self-hosted Pulumi Service is not a single monolithic application but a distributed set of services designed to handle different aspects of the infrastructure-as-code lifecycle.
Essential Service Components
The backend is comprised of several key containers, each serving a distinct purpose in the orchestration of state and user management.
- API Service: This is the core engine of the system. It handles requests from the Pulumi CLI, manages the logic of state transitions, and enforces RBAC policies. The container image is located at
https://hub.docker.com/r/pulumi/service/. - Console Service: This provides the management UI (the "dashboard") where users can visually track stack updates, manage team memberships, and review history. The container image is located at
https://hub.docker.com/r/pulumi/console/. - Migrations Service: This component is responsible for updating the database schema to ensure the API and Console services are running against a compatible data structure. The container image is located at
https://hub.docker.com/r/pulumi/migrations/.
It is important to note that these container image repositories are private. Access is granted only to licensed Enterprise customers.
Persistence Layer Requirements
To support these services, the environment must provide two primary types of persistent storage.
- Relational Database: A MySQL 5.6 DB server is required. This database stores the structured data for the service, including user profiles, organization settings, and the metadata for stacks. The system requires at least 20GB of dedicated storage space for the MySQL data volume to account for growth in user and stack metadata.
- Object Storage: A minimum of 50GB of SSD-backed storage is required for the object store. This is where the actual "state" files (the JSON representations of the infrastructure) are stored. Because state files are the source of truth for the infrastructure, the use of SSDs is recommended to ensure low latency during
pulumi upandpulumi previewoperations.
Deployment Topology and Infrastructure Options
Pulumi's design allows it to be deployed across a vast array of environments, making it agnostic to the underlying cloud or physical hardware.
Environment Versatility
The deployment topology can be adapted to various needs:
- On-Premise Data Centers: Utilizing VMware, OpenStack, or bare-metal servers.
- Public Cloud Providers: Deploying into AWS, Azure, or GCP using virtual machines or managed Kubernetes.
- Air-Gapped Environments: Deploying in isolated networks with no external internet access, fulfilling strict security protocols.
- Kubernetes Clusters: Utilizing K3s or full-scale Kubernetes clusters for orchestration, as supported by the production-ready Infrastructure as Code (IaC) configurations found in the
pulumi-self-hosted-installersrepository.
Reference Implementations
The pulumi-self-hosted-installers GitHub repository serves as the primary resource for deploying these services. It contains reference implementations that span from local development setups (for testing) to cloud-native Kubernetes clusters (for production). These configurations allow organizations to use IaC to deploy their own IaC management platform, ensuring that the deployment process itself is versioned and repeatable.
Identity and Access Management Integration
One of the primary advantages of the self-hosted Pulumi Service is the ability to integrate directly with existing corporate identity providers. This removes the need to manage separate sets of credentials and allows for centralized offboarding and onboarding.
The self-hosted installation supports the following identity providers:
- GitHub Enterprise: Integration for organizations using self-hosted GitHub instances.
- GitLab Enterprise: Integration for those leveraging GitLab's enterprise-grade version control and CI/CD.
- SAML SSO: A universal standard that allows Pulumi to integrate with almost any modern identity provider (IdP) such as Okta, Ping Identity, or Azure Active Directory.
- Email/Password: A basic authentication method for smaller teams or environments where an external IdP is not available.
- Azure Active Directory: Native integration for organizations heavily invested in the Microsoft ecosystem.
- Bitbucket: Support for Atlassian's version control platform.
By using these integrations, administrators can manage permissions across the organization via federated identity and group management, ensuring that the principle of least privilege is applied to infrastructure changes.
Deployment Configuration and Quickstart Parameters
For organizations initiating a self-evaluation or a Proof of Concept, Pulumi provides sample docker-compose files. While docker-compose is an excellent tool for rapid deployment and testing, it is not strictly required; any OCI-compatible container orchestrator can be used.
During the initial setup, particularly when using the run-ee.sh script provided in the self-evaluation package, certain environment variables must be configured to link the containers to their persistence layers.
| Variable | Description | Default Value |
|---|---|---|
PULUMI_DATA_PATH |
The persistent path on the host where the service stores checkpoint objects. | /tmp/pulumi-ee/data |
PULUMI_LOCAL_DATABASE_NAME |
The hostname or IP address of the MySQL database instance. | pulumi-db |
PULUMI_LOCAL_DATABASE_PORT |
The network port on which the MySQL database is listening. | Not specified (Typically 3306) |
Failure to set PULUMI_DATA_PATH to a persistent volume will result in the loss of state data whenever the container is restarted, which would be catastrophic in a production environment.
Alternative Lightweight State Management with MinIO
For users who do not require the full Enterprise Service (API and Console) but still want to avoid the Pulumi Cloud SaaS, a lightweight alternative is to use a self-hosted state backend. This approach focuses purely on where the state file lives, rather than providing a full management UI and RBAC system.
MinIO Implementation
A common pattern for "semi-self-hosting" involves using MinIO, an S3-compatible object storage server. This allows teams to keep stack state under their own control and avoid seat caps associated with the SaaS offering.
Recommended specifications for a MinIO-backed Pulumi setup on a VPS (such as a RamNode VPS) include:
- Operating System: Ubuntu 24.04 LTS.
- Hardware: Cloud VPS with at least 2 vCPU and 2 GB of RAM.
- Time Investment: Approximately 45 to 60 minutes for full configuration.
- Licensing: Pulumi CLI (Apache 2.0) and MinIO (AGPL v3).
Support Matrix for MinIO Backend
When using this architecture, Pulumi continues to support its full range of programming languages:
- TypeScript
- Python
- Go
- .NET
- Java
- YAML
Hardening and Initial Server Configuration
When deploying a self-hosted backend—whether the full Enterprise Service or a MinIO state store—server hardening is a non-negotiable prerequisite to prevent unauthorized access to sensitive infrastructure state.
Network Security and Firewalling
Initial server hardening should begin with updating the package manager and installing essential security utilities. The following commands are used to prepare an Ubuntu-based environment:
bash
sudo apt update && sudo apt -y upgrade
sudo apt -y install ufw fail2ban ca-certificates curl gnupg
The Uncomplicated Firewall (UFW) must be configured to follow a "deny by default" policy for incoming traffic, only allowing specific ports required for management and service access:
bash
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
Service-Level Security
To protect against brute-force attacks on the management interface or SSH port, fail2ban should be enabled and started immediately:
bash
sudo systemctl enable --now fail2ban
Furthermore, the SSH daemon configuration (sshd_config) must be audited to ensure that password authentication is disabled and root login is prohibited, forcing the use of SSH keys:
PasswordAuthentication noPermitRootLogin no
CLI Installation
Once the environment is hardened, the Pulumi CLI is installed to interact with the self-hosted backend. The standard installation procedure is as follows:
bash
curl -fsSL https://get.pulumi.com | sh
echo 'export PATH="$HOME/.pulumi/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
pulumi version
Infrastructure Requirements Summary
The following table summarizes the hardware and software requirements for a standard Self-Hosted Pulumi Enterprise deployment.
| Requirement | Specification | Purpose |
|---|---|---|
| MySQL Version | 5.6 | Relational data and metadata storage |
| MySQL Storage | $\ge$ 20GB | Database volume for user and stack data |
| Object Storage | $\ge$ 50GB SSD | Storage for state files (checkpoints) |
| OS Compatibility | Any (On-prem/Cloud) | Host environment for containers |
| Orchestrator | OCI-Compatible | Deployment of API, Console, and Migrations |
Comprehensive Analysis of Self-Hosting Trade-offs
Deciding between Pulumi Cloud and a self-hosted deployment is a balance between operational agility and absolute control.
From a security perspective, the self-hosted model is peerless. By eliminating the "third-party" element from the state management equation, the organization removes a significant attack vector. The state file contains the blueprint of the entire infrastructure—including resource IDs, dependencies, and sometimes sensitive metadata. Keeping this inside a private network, potentially air-gapped, ensures that even a total compromise of a SaaS provider would not expose the organization's architectural secrets.
However, the "Total Cost of Ownership" (TCO) increases with self-hosting. The organization must now account for the human capital required to manage the MySQL database and the object store. A failure in the MySQL database or the loss of the object storage volume without a verified backup would result in a "state loss" event. In Pulumi, losing the state file is a catastrophic event, as it disconnects the code from the actual deployed resources, necessitating a manual and time-consuming "import" process for every single resource in the infrastructure.
Moreover, the integration with federated identity (SAML, GitHub Enterprise) adds a layer of complexity to the initial setup but provides immense long-term value by aligning infrastructure access with corporate HR and security policies.
Ultimately, the self-hosted Pulumi Service is an enterprise-grade tool designed for those who view their infrastructure state as a high-value asset that must be guarded with the same rigor as their most sensitive production databases. Whether deployed via a Kubernetes cluster using the pulumi-self-hosted-installers or as a leaner MinIO-backed setup, the result is a sovereign cloud engineering platform that empowers the organization to scale its infrastructure without sacrificing its security posture.