Open-source alternative to Pulumi Cloud drift detection

Which open-source options replace Pulumi Cloud drift detection

A team on Pulumi Cloud Pro or Enterprise that relies on scheduled drift checks can move most of that routine to a self-managed backend: a CI job that runs pulumi refresh --preview-only and pulumi preview --diff on a timer, against each stack's state in your own bucket or database. The Pulumi CLI is open source, so the detection logic itself stays the same. What changes is who schedules the job, where the output is stored and who gets alerted when something moves. Before a renewal or residency review, confirm with Pulumi which drift scheduling and remediation features your current edition includes, since those limits are set by the vendor and can change.

The gaps are mostly operational. The hosted service gives you one view of stacks, run history and notifications without a pipeline to maintain. In your own CI, you build the schedule for each stack or group of stacks, a credential that can read cloud state without write rights, a check that turns a non-empty diff into a failed job, and an alert route to the owning team. Detection is the easy part. Refresh also writes to state, so a scheduled refresh can collide with a normal deployment or a held lock. Run the check in preview-only mode first, and keep any write path behind a reviewed change.

Handling what the schedule finds is a decision to write down before the first run. For each drifted resource, the owning team either accepts the live change and updates the program to match, or reverts it by applying the code again. Assign that decision to a named role and record it in the pull request or ticket. Two limits matter most. The scheduled check only sees resources a Pulumi stack declares, so resources created by hand or by another tool stay invisible unless you add a separate inventory scan. Also, how much a provider reports on refresh depends on that provider. Confirm both points with Pulumi and test on a non-production stack before you retire the hosted schedule.

Mapping Pulumi Cloud drift capabilities to open-source options

This table maps each drift capability in Pulumi Cloud to the component that covers it on a self-managed backend, such as a CI scheduler running preview and refresh. Read the rows as a checklist of what you must build, and treat the gap rows as work you own. The main takeaway is that the CLI can detect drift, but history, review and approval records must be assembled from your CI system and Git.

Capability	Pulumi Cloud approach	Open-source or DIY equivalent	What to confirm
Scheduled drift runs	Managed scheduled drift detection on Pro and Enterprise editions	CI cron schedule running pulumi preview with refresh against each stack	Scheduler minimum interval and whether concurrent runs on one stack are blocked
Change detection output	Drift results shown per stack in the service	Preview diff captured as CI log or artifact, parsed for changed resources	Output format your parser expects and retention period in your CI
Alerting	Built-in notifications from the service	Chat or email notification step triggered on a non-empty diff	Exit code handling so a failed refresh alerts separately from detected drift
Remediation approval	Review and apply drift fixes inside the service	Pull request or manual approval gate before pulumi up runs in CI	Who holds approval rights and whether approvals are enforced by branch protection
Drift history	Stored history of detected drift in the service	No built-in history UI; retained CI logs, artifacts or a log store you maintain	How long your CI keeps logs and whether an assessor can retrieve them by date
Access control	Team permissions managed in the service	CI secrets scoped per stack and repository role controls on who can trigger runs	That cloud credentials used by the scheduler are limited to refresh and preview actions
Git-based review	Not the primary workflow in the service	Drift reports or proposed changes opened as pull requests for review	Whether your forge supports automated pull request creation from CI jobs
Secrets during refresh	Encrypted secrets handled by the service	Secrets provider configured in the stack, with CI logs masked for sensitive values	That previews do not print secret values into logs your team can read

Which CI scheduler fits your drift checks

Drift detection on a DIY Pulumi backend is a scheduled job that runs preview or refresh against each stack and reports differences. The four options below differ mainly in who can change the schedule, where cloud credentials live, and how a failed or drifted run reaches a person. Match the scheduler to your existing access model before you choose the tool.

General CI system on a cron trigger

Most teams already run a CI system with cron-style schedules, so a nightly job that runs pulumi preview --diff per stack is the simplest starting point. It fits when the CI system already holds the cloud credentials used for deployments and when your change process covers pipeline edits. The trade-off is that anyone who can edit the pipeline can often reach the same credentials, so restrict pipeline ownership and scope the drift job to read-only roles. Alerting usually means a failed job or a message posted from the job, so confirm how your CI system notifies on scheduled runs and where the logs are kept.

Git forge scheduled pipelines

If your repositories sit on a self-hosted forge such as GitLab, Gitea or Forgejo, its built-in scheduled pipelines can run drift checks next to the code they test. This suits teams that want the schedule defined in the same repository and reviewed like any other change. The trade-off is that scheduled pipelines often run with the project's variables, so anyone with maintainer rights may read secrets used by the job. Ask whether scheduled runs can use protected variables only and whether the forge can send failure notifications to your chat or ticketing tools.

Kubernetes-based job runner

A CronJob in the cluster that manages your infrastructure, or a runner that executes stack checks as pods, keeps credentials inside the cluster and uses Kubernetes RBAC and namespaces to limit access. It fits teams that already operate clusters and want drift runs to share the same audit and network controls as workloads. The trade-off is that the job's service account can become a broad cloud identity, so use workload identity with narrow roles. Confirm how job failures surface, because a failed CronJob pod produces no alert unless you add monitoring that watches for it.

External scheduler calling the pipeline

An external scheduler, or a small script on a host you control, can trigger the CI pipeline through its API on a fixed time. This separates the schedule from the pipeline, so the team that owns timing can differ from the team that owns the stacks. The trade-off is an extra service holding a token that can start pipelines, which becomes a privileged credential to rotate and audit. Keep the token limited to triggering one pipeline, and confirm that the trigger records who or what started each run so drift reports can be traced.

Alerting and ownership of drift results

Whichever scheduler you choose, a drift run produces a result that someone must act on, and that step is where DIY setups usually fail. Route results to a named owner per stack, separate expected drift from unexpected drift, and keep the output of each run for review. Decide who may approve a pulumi up that corrects drift, because a scheduled job should report changes rather than apply them. Confirm your chosen tools can retain logs for as long as your change records require.

Running drift checks alongside Pulumi Cloud and your other tools

Some teams move a subset of stacks first, often non-production environments, while production stays on Pulumi Cloud. In this model, drift jobs run per stack, so each stack's scheduled job must point at the backend that holds its state. Keep the Pulumi CLI and provider versions identical on both paths so that a preview means the same thing regardless of where the state lives.

Scheduler per backend: Configure each CI job with the backend it uses, so a refresh never runs against a backend that does not hold that stack's state.
Shared secrets provider: Keep the existing secrets provider and its key access in place on both paths, so stack configuration decrypts the same way wherever the state is stored.
Identity unchanged: Reuse the existing CI identity and cloud roles, and add only the storage permissions the self-managed backend requires.
Common alert routing: Send drift output from both paths to the same chat channel and ticket queue, tagged with the stack name and backend, so responders do not monitor two dashboards.

Before each cutover, confirm that no stack name is active in both backends, because two state files for one stack will diverge.

Moving drift checks off Pulumi Cloud without losing coverage

This sequence moves each scheduled drift check to a CI pipeline on your own backend without gaps in coverage. Each stack is checked by both systems for a period your team sets, and the hosted schedule is turned off only after the findings match.

Inventory every scheduled drift check
The platform lead lists each stack that has a hosted drift schedule enabled, along with its schedule, its notification targets, its owning team and any remediation that runs automatically. Also list stacks that are checked by hand, since they are easy to miss. The output is a written inventory that every later step uses as its checklist. The step is done when each stack has one owner and one documented alert destination.
Establish the self-managed backend and migrate state
The platform team sets up the state backend you chose, such as object storage or PostgreSQL, and moves each stack using the stack migration process. Confirm that the backend's access controls, versioning and backup match your policy before any state moves. After each migration, run pulumi preview on the stack and confirm that it reports no unexpected changes. The step is done when every inventoried stack previews cleanly from its new backend.
Recreate the drift schedule in CI
The platform team creates a scheduled pipeline in your CI system that runs pulumi refresh --preview-only and then pulumi preview --expect-no-changes for each stack, using the same cloud credentials and provider configuration as deployments. Configure the job so that a non-zero exit code opens a ticket or posts to the team channel named in the inventory. The step is done when a deliberately introduced test change is detected and alerted on in a scheduled run.
Capture what the hosted feature recorded
Before the hosted feature is switched off, record what it kept for you: run history, timestamps, the drift detected on each run, who received alerts, and any remediation it applied. Decide where each of these lives in your setup, such as CI run logs, retained artifacts in object storage, or a findings register in your ticketing system. Confirm the retention period you need for audit with your compliance lead. The step is done when every category in that list has a named home and a documented retention rule.
Run both systems in parallel
For a period the team sets in advance, the hosted schedule and the CI schedule both run against each stack. After each cycle, the reviewer compares the findings from each system for the same stack and time window. Any difference is investigated and its cause written down, whether it is a timing issue, a missing credential or a real drift gap. The step is done when the reviewer signs off that the two systems agree for the agreed period, with every discrepancy explained.
Turn off the hosted schedule
Once the parallel period closes with no unexplained differences, the platform lead disables the hosted drift schedules, stack by stack, and records the date on each inventory line. Keep the hosted history readable until your retention requirements are met, and confirm with your Pulumi Cloud contract what access remains after the schedule is disabled. The CI schedule continues as the only drift check. The step is done when no hosted schedule is active and the CI schedule has run without gaps since the switch.

Where a CI-based drift check falls short of the hosted feature

A CI drift check has three structural limits, and the first is that refresh changes the state it is meant to check. A scheduled pulumi refresh writes what the cloud currently reports into the stack state, so the drift it found is overwritten before anyone reviews it. A preview-only refresh reports differences without writing, and a person then decides what happens next. Preview output is also not a history store. The CI log shows one run, and the diff disappears when the CI retention window ends unless you export it to storage you control. Ask whether your CI system keeps artifacts long enough for your audit needs. Confirm this behavior against the exact CLI version you run, because flags and defaults change between releases.

A refresh-based check only sees what the provider's read logic returns. If a provider does not read a setting back, or a change is made through a console action the provider does not model, the check reports no drift even though the environment has changed. Resources created outside the program, such as policy attachments added by another team's tooling, can fall outside the stack's view entirely. Treat coverage as something to measure. Pick a sample of resources, change one non-critical attribute in each by hand, and confirm the scheduled job reports it. Record which attributes escaped detection. That list shows where the CI check is blind, and it is the list to take to your vendor or provider maintainers when you ask what the hosted feature covers.

The remaining gaps are operational. The hosted feature handles scheduling and remediation for you, while a DIY job has no remediation policy unless your team writes one. Decide in advance who approves a pulumi up that corrects drift, and whether correction runs automatically or only after review. Concurrency is the other gap. If a scheduled refresh starts while a deployment is writing state, two runs can race on the same stack. Confirm how your chosen backend handles locking, and make the pipeline serialize drift jobs and deployments on the same stack with a shared concurrency group or lock. Test both limits in a non-production account first, including a deliberate concurrent run, and document the results before you rely on the job as compliance evidence.

What it costs and takes to replace Pulumi Cloud drift detection

What does it cost to replace Pulumi Cloud drift detection with a self-managed setup?

The cost is a mix of recurring infrastructure and one-time engineering, and no single price applies because it depends on how many stacks you run and how often you schedule checks. The recurring parts are CI runner minutes for scheduled pulumi preview and refresh jobs, object storage or database hosting for state history, the secrets provider you choose, and the alerting tools that route results to people. The one-time parts are building the pipeline, writing alert rules and documenting the remediation runbook. Pulumi Cloud bills its paid tiers in credits and per managed resource, so compare your current bill against the same resource count in your own infrastructure. Ask any provider for a quote that lists each component separately, with who pays for it and what recurs each month.

What drives the cost of scheduled drift checks up or down?

The main drivers are the number of stacks, the number of resources per stack, and how often each stack is checked. Refresh and preview time grows with resource count and provider API calls, so large stacks consume more runner minutes and may hit cloud API rate limits. Frequency matters too: a nightly check costs far less than a check every hour across the same estate. Splitting stacks by team or environment shortens each run and keeps failures isolated. Storage costs stay small for most teams, but retention of plan output and audit logs grows over time. Ask the provider to model cost for your actual stack count, resource count and schedule, not for an average.

Can our team build drift detection on a self-managed backend without outside help?

A team that already runs Pulumi from CI and understands its state backend can build a basic scheduled preview job without outside help. The harder work is consistent behavior across many stacks: credential handling for each cloud account, locking when a scheduled job overlaps a deployment, secret redaction in plan output, alert routing and a remediation path that people trust. Pulumi Cloud handled some of these for you, so the gaps are usually in alerting, history and access control rather than in the core diff. Estimate internal effort by listing which of these your team has built before. If the answer is few, a fixed-scope engagement with a written deliverable list can reduce the risk of gaps.

How long does it take to set up drift detection on a DIY backend?

No researched duration applies to this work, so the timeline depends on your environment rather than a published figure. The main factors are how many stacks and cloud accounts are in scope, whether a state backend already exists, how many alert destinations you connect, and how many approvals your change process requires. A pilot on a small set of non-production stacks usually reveals the credential and locking issues early, which makes the rest of the schedule easier to estimate. Ask any provider to break the timeline into phases with entry and exit criteria, and ask which dependencies sit with your team, such as access approvals or network changes.

What do we need to give a provider or our own team to run drift detection?

The work needs scoped cloud credentials, a complete inventory of stacks and their owners, and named owners for alert routing. Read-only credentials are enough for detection, so keep write access separate and limit it to a remediation role that requires approval. The inventory should list each stack, its backend, its secrets provider and the cloud accounts it touches, because drift checks fail quietly when a stack is missing from the schedule. Alert routing needs at least one owner per stack and a fallback for nights and holidays. Confirm with your security team how credentials will be stored, rotated and logged before any job runs.

Can drift remediation be automated safely?

Automatic remediation is possible, but it is safest to start with detection and manual approval. Running pulumi up on a schedule can revert changes that someone made on purpose during an incident, so a remediation job needs a clear rule for which drift it may correct and which it must only report. Common controls include a protected branch or approval gate, a dry run that posts the plan for review, a freeze window during change events, and a rollback path. Many teams automate only low-risk resource types, such as tags, and keep security groups, IAM and data stores behind review. Ask any provider how remediation is gated and whether it can be turned off per stack.

What are the limits of drift detection on a self-hosted backend?

Scheduled previews show differences between the state file and the cloud, but they do not explain why the change happened or who made it. Drift from changes outside Pulumi, such as console edits or another tool, appears only if the refresh reads that resource, and resources not in state may be missed entirely. Results are only as current as the last run, so changes made between checks are invisible until the next one. Audit trails also need separate work, because your CI logs and cloud audit logs must be joined to show the actor. Confirm these limits with the provider in writing and decide which gaps your change process will accept.

How do we request a quote for drift detection work?

Ask for a written scope that names the stacks, cloud accounts, backends and alert destinations in scope, plus the deliverables for each. Request separate line items for one-time build work, such as pipeline design, credential setup and runbooks, and for recurring work, such as maintenance, upgrades and testing. Ask which costs are infrastructure you pay directly, such as runner minutes, storage and secrets services, and which are professional services. Ask for the assumptions behind the quote, the acceptance criteria and what happens if the stack count grows. DeployOpen works from a fixed written scope, so a quote follows from that scope, and ongoing support is available as a retainer.

Cost components of a self-managed drift check

The one-time work in a self-managed drift check is designing the schedule, routing alerts and writing the runbooks for handling what the check finds. Someone has to decide which stacks are checked, how often, and whether a refresh-only preview is allowed to run against production without human approval. Alert routing is a separate design task: a nightly job that posts to a shared channel nobody watches costs nothing to build and delivers no value. Runbooks cover the decisions that Pulumi Cloud's scheduled drift feature handled for you, such as whether to reconcile code to match the live cloud or to revert the live resource to match code. Expect this work to be paid as engineering time, whether it is done by your platform team or by a fixed-scope engagement with a partner. Ask any quote to itemize these tasks separately from the recurring items below.

The recurring costs are CI runner minutes, storage for the state history, the secrets provider that decrypts state and cloud credentials, and on-call time for drift alerts. Runner minutes scale with the number of stacks, the check frequency and the time each pulumi preview takes, so a check that runs hourly across many stacks consumes far more than a daily one. Storage grows with the number of state versions retained, which in turn depends on how often stacks change. Secrets provider cost depends on whether you use a cloud KMS, which bills per key and per request, or a self-run service that you must patch and back up. Alert volume is the largest variable: each cloud account, region and stack that drifts adds noise, and the number of accounts often matters more to on-call load than the number of stacks. Ask your provider to show these drivers as separate line items, and confirm them against your own stack and account counts before comparing totals with the Pulumi Cloud cost vs a self-managed backend comparison.

How DeployOpen scopes and delivers drift detection replacement

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For drift detection on a self-managed Pulumi backend, that means a written scope covering scheduled preview runs, alerting, and the runbooks your teams use when drift is found.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope lists which Pulumi stacks, state backends and CI runners are covered by scheduled drift checks.
Scope also names who receives drift alerts and which drift categories require review before any remediation.

How we build

We configure scheduled CI jobs that run preview with refresh against each stack and store the output as an artifact.
We wire failed or non-empty drift results to the alert channels your operations team already monitors.
We test the pipeline against deliberately changed test resources in a non-production environment before enabling it.

How we hand over

You receive pipeline configuration, the drift triage runbook and documented access rules for the state backend.
Handover covers how to decide between reverting code, accepting the change, or importing it into the program.
Documentation records what the drift checks cover, and what they do not, so auditors and engineers read the same scope.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover Pulumi CLI upgrades, CI runner changes and periodic review of the drift check coverage.
Ask any provider to confirm in writing which drift events its support covers and its response expectations.