FAQ

Does Pilum bypass my cloud provider’s IAM or logging?

No. Pilum drives the same provider CLIs and APIs you would call yourself — its recipe “ingredients” generate standard commands (gcloud run deploy, and so on) executed with your existing credentials. IAM policies apply identically: Pilum cannot do anything your credentials can’t. Deploys appear in your provider’s logging and audit trails exactly as if you had run the commands by hand. You can verify this yourself: pilum deploy --dry-run prints every command before anything executes.

Is Pilum maintained? What’s the bus factor?

Pilum is dogfooded as the deployment tool for every SID Technologies product — Torch, Statio, Capsa, Vigil, and the websites you’re reading this on — dozens of services deployed with it continuously. It is not a demo repo; it’s the tool its maintainer’s business runs on, which is the strongest maintenance incentive a small OSS project can have. It’s Apache 2.0, so the worst-case scenario is a fork of a working tool, not a dead dependency: your recipes are YAML wrapping standard cloud commands, and --dry-run shows you exactly what they do.

Does Pilum replace Terraform or Pulumi?

No, and it doesn’t try to. Your infrastructure-as-code provisions resources (services, queues, databases, networking). Pilum handles the build → push → deploy loop that puts application code onto that infrastructure. They meet at the boundary: IaC defines that a Cloud Run service exists; Pilum ships new revisions to it.

Does Pilum replace GitHub Actions / GitLab CI?

No — it runs inside them (or on your laptop). CI provides triggers, secrets, approvals, and history; Pilum provides the deploy orchestration that would otherwise be glue scripts. It can post commit statuses back to GitHub from CI. See Pilum vs. CI/CD pipelines for the full boundary.

Am I locked in if I adopt Pilum?

About as little as possible. The configuration is plain YAML per service, recipes are readable workflows, the license is Apache 2.0, and --dry-run prints the literal commands Pilum runs — which doubles as your migration path: if you ever leave, you can lift those commands into any pipeline.

Is Pilum a good fit for a single-cloud GCP team?

Often not, honestly. If everything you ship is Cloud Run or GKE and you want progressive delivery, Google’s native chain (Cloud Build, Cloud Deploy, Skaffold) is excellent. Pilum earns its place when targets multiply — see When to Use Pilum and Pilum vs. GCP native tooling.

How does Pilum handle secrets?

It doesn’t store any. Credentials come from the same places your commands already use — gcloud auth, AWS profiles, environment variables, or your CI’s secret store. Pilum adds no credential layer of its own.

What providers are supported?

GCP Cloud Run and Cloud Run Jobs, AWS Lambda, Azure Container Apps, Cloudflare Pages, npm, Homebrew, and Docker registries — with a recipe system designed so adding a provider is YAML, not Go code.