Skip to content
Pilum

FAQ

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

No. Pilum runs the same provider CLIs you would run yourself (docker, gcloud, az, sam, wrangler, npm, git) with your existing credentials. IAM policies apply exactly as they would by hand: Pilum can’t do anything your credentials can’t. Deploys show up in your provider’s logging and audit trails as if you had run the commands yourself. pilum dry-run prints every command before anything executes, so you can check.

Is Pilum maintained? What’s the bus factor?

SID Technologies deploys its own services with Pilum, every day: dozens of services across Cloud Run, Cloud Run Jobs, Cloudflare Pages, npm and Homebrew. It is the tool its maintainer’s business runs on, which is a strong maintenance incentive for a small OSS project. It is Apache 2.0, so the worst case is a fork of a working tool, not a dead dependency: your recipes are YAML wrapping standard cloud commands, and pilum dry-run shows exactly what they do.

Does Pilum replace Terraform or Pulumi?

No, and it doesn’t try to. Infrastructure-as-code provisions resources (services, queues, databases, networks, instance groups). 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 or managed instance group exists; Pilum ships new versions to it.

Does Pilum replace GitHub Actions / GitLab CI?

No. It runs inside them, or on your laptop. CI provides triggers, secrets, approvals and run history; Pilum provides the deploy orchestration that would otherwise be glue scripts. It can post commit statuses back to GitHub (--github-status) and send webhooks. See Pilum vs. CI/CD pipelines and Environments & CI.

Am I locked in if I adopt Pilum?

About as little as possible. Configuration is one plain YAML file per service, recipes are readable workflows, the license is Apache 2.0, and pilum dry-run prints the literal commands Pilum runs. That output is also your migration path: if you leave, you can lift those commands into any pipeline.

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

Often not. 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, when you have many services in one repository, or when you want one command for Cloud Run, jobs, VMs, static sites and packages. See When to Use Pilum and Pilum vs. GCP native tooling.

How does Pilum handle secrets?

It doesn’t store any. Deploy credentials come from where your commands already get them: gcloud auth, AWS profiles, az login, environment variables, or your CI’s secret store. Tokens for npm, Homebrew and Cloudflare are read from environment variables you name in pilum.yaml. For Cloud Run, secrets: maps environment variable names to Secret Manager references (DATABASE_URL: database-url:latest); Pilum passes the reference to gcloud, never the value. Write secrets as a map: a list is ignored, and the deploy then clears the service’s existing secrets.

What deployment targets are supported?

Ten built-in recipes:

GCP Cloud Run, Cloud Run Jobs, Cloudflare Pages, npm and Homebrew are used daily. AWS Lambda and Azure Container Apps are implemented and reviewed but less exercised. For anything else, write a recipe: adding a provider can be YAML only.

Can Pilum roll back a bad deploy?

Yes, on GCP. pilum rollback <service> returns a Cloud Run service to its previous healthy revision (traffic only, no rebuild), points a Cloud Run job at its previous execution’s image, or rolls a managed instance group back onto its previous instance template. The previous version is read from GCP, so it works from any machine. It asks for confirmation, and needs --yes in CI.

Terminal window
pilum rollback api --dry-run
pilum rollback api --yes

For other targets, deploy the previous tag again: pilum deploy web --tag v1.1.0. See Rollback, Status & History.

Can Pilum deploy to VMs?

Yes, to GCP managed instance groups running Container-Optimized OS, with the gcp-mig-container recipe. Pilum builds and pushes the image, creates a new instance template named <template_base>-<tag> by copying the group’s current template with only the image changed, starts a rolling update (extra instances limited by mig.max_surge, none taken down early by default), and waits until the group is stable.

Pilum doesn’t create the MIG, load balancer, health check, firewall rules or NAT; provision those with your IaC. Each release needs a unique --tag; latest is rejected. Plain VMs outside a MIG and other clouds’ VM services have no built-in recipe.

Does Pilum cache builds?

Pilum doesn’t keep a cache of its own. It relies on each toolchain’s cache (Go’s build cache, the pnpm store, Cargo, Gradle, Docker layers) and makes parallel builds share it. Before the first build step, it runs one warming command per group of services that share a toolchain and workspace, for example a single go build over every Go service’s packages, so that ten parallel builds don’t each compile the same dependencies.

Warming is automatic for groups of two or more services with a host build.cmd. You can set your own command with build.warm, or turn it off with build.warm: false or --no-warm. If warming fails, the builds still run, cold. See Build Cache Warming.

Which languages does Pilum support?

Any language that builds with a shell command. build.cmd is run through sh -c from the service directory, and container recipes then run docker build with your Dockerfile from _templates/. If build.cmd is empty, the host build is skipped and the Dockerfile does all the work.

build.language adds language-specific help:

  • pilum init templates for bun, c, cpp, dotnet, go, java, kotlin, node, php, python, ruby and rust, each with a default build command. For bun, dotnet, go, java, node, python and rust, init also writes a starter Dockerfile to _templates/.
  • Worker sizing: each language has a memory estimate used to decide how many builds run in parallel.
  • Automatic cache warming for Go, Node (pnpm, bun, yarn, npm), Python (uv, pip), Rust (Cargo), Java and Kotlin (Gradle, Maven), .NET and PHP (Composer).

Aliases are accepted, such as golang, typescript, csharp and c++. See Build Configuration.

Next Steps