When to Use Pilum (and When Not To)

Pilum is not the right tool for every deployment. This page describes where it earns its place in a stack and where you should use something else.

Use Pilum when

1. You deploy to multiple targets from one repo

This is the core use case Pilum was built for. If one project ships a container to GCP Cloud Run, a function to AWS Lambda, a frontend to Cloudflare Pages, a CLI to Homebrew, and a package to npm, the native answer is five different pipelines with five different configuration formats. Pilum standardizes that into pilum.yaml files and one command:

pilum deploy --tag=v1.2.0

Pilum itself is dogfooded this way: it deploys every SID Technologies product — dozens of services across Cloud Run, Cloud Run Jobs, Lambda, Cloudflare Pages, npm, and Homebrew — from monorepos, daily.

2. You want deploys from your laptop that match deploys from CI

Waiting on a full CI round-trip to test a change on real infrastructure is slow. Pilum runs the same recipe locally and in CI, so pilum deploy on your machine does exactly what the pipeline does — same build, same push, same deploy, same validation. Dry-run mode (--dry-run) prints every command before anything executes.

3. You have a developer/DevOps divide

One person maintains the Terraform or Pulumi that provisions infrastructure; application developers just need to ship code onto it. Recipes give developers a small, validated YAML surface (pilum.yaml) while the infrastructure definitions stay where they belong. Nobody deploys by editing Terraform.

4. You are tired of CI glue scripts

The bash that builds an image, extracts the tag, pushes it, and threads it into a deploy step is the most fragile part of most pipelines. That loop — build → push → deploy, with dependency ordering, parallel waves, and deployment locks — is precisely what Pilum replaces with declarative recipes.

Do NOT use Pilum when

You are single-cloud on GCP with a mature pipeline

If everything you ship is a Cloud Run service or GKE workload, Google’s native chain — Cloud Build, Artifact Registry, Cloud Deploy, Skaffold/Cloud Code for inner-loop development — is excellent, deeply integrated, and staffed by Google. Pilum adds a layer you may not need. See Pilum vs. GCP native tooling for the detailed comparison.

Your CI/CD already does this cleanly

If your GitHub Actions reusable workflows or GitLab CI templates already pass image tags into your IaC without hand-rolled glue, and developers aren’t blocked on deploy velocity, Pilum solves a problem you don’t have. See Pilum vs. CI/CD pipelines — the two are complements, not competitors, but you don’t need a complement to a thing that isn’t hurting.

You are standardizing a large organization on a platform layer

Internal developer platforms (Backstage, Score) exist for org-wide standardization with governance, scorecards, and portals. Pilum is a deployment CLI, not an IDP. It works great inside such a platform as the deploy step; it is not one itself.

You want GitOps as the operating model

If your model is “the cluster reconciles itself from git” (Argo CD, Flux), Pilum’s imperative deploy loop is the wrong shape. Pilum is push-based by design.

The one-line test

Count your deployment targets. At one, use that platform’s native tooling. At three or more — or at one plus npm, Homebrew, or static hosting — Pilum starts paying for itself.