Your cloud driver shouldn't be compiled into your deployment tool

There is a class of tool that accumulates weight in proportion to the number of clouds it supports. Every new provider means new dependencies, new SDK versions to track, new compilation units. The binary grows. The link step balloons. The release cadence of the whole tool becomes hostage to the release cadence of every cloud SDK inside it.

Simple Container crossed that threshold. The monolithic build was 920 MB, and the Go linker was peaking at 12.9 GB of memory to produce it. That is not a footnote — it is an argument for a different architecture.

That architecture shipped last week.

The seam that makes plugins possible

The new model separates a small sc core from cloud drivers that live in their own repositories, build independently, and are resolved at deploy time rather than compiled in at build time.

The mechanics: when sc needs a cloud driver, it looks up the driver’s GitHub Release, verifies the sha256 checksum, and executes the binary. The driver exposes a gRPC plugin bus over a local socket; sc talks to it the same way it would have talked to an in-tree driver. The state file, the Pulumi engine, the resource graph — all of it is shared through the same interface. From the perspective of your stack, nothing changed.

From the perspective of the driver itself, almost everything changed. A cloud driver now has its own repository, its own dependencies, its own release tag, its own contributors. Adding Cloud.ru support, or updating the Yandex Cloud SDK, no longer requires a sc release. The driver ships when it is ready; sc pins the version it trusts.

Three drivers are published under this model today: sc-plugin-cloudflare , sc-plugin-yandex , and sc-plugin-cloudru . Each carries multi-platform release binaries — linux-amd64, linux-arm64, darwin-arm64 — with sha256sums.

The back-compat constraint that shaped the design

Splitting a tool is easy. Splitting it correctly is the hard part.

The constraint the team held throughout was: the first sc deploy against a pre-existing stack, after the split, must produce zero replaces and zero deletes. If upgrading to the plugin-era sc causes Pulumi to re-create a resource — a database, a live service, a load balancer — the migration is broken regardless of the technical elegance of the design.

The mechanism that makes this work is URN stability. Pulumi identifies every managed resource by a URN constructed from the resource type, the provider, and the logical path through the stack. Changing how a driver is loaded cannot change the URN format it registers, or the diff will see the pre-plugin resource and the post-plugin resource as different things.

They proved byte-identical URNs across the boundary before writing the bus. The integration test for each driver runs an existing stack end-to-end and asserts no unexpected changes in the plan. That test is the release gate.

What the extension boundary buys in practice

This is the argument that applies beyond Simple Container specifically.

When a cloud driver is compiled into a deployment tool, several things become true by default: the driver’s release cadence is the tool’s release cadence; the driver’s dependency conflicts are the tool’s dependency conflicts; a security fix in one driver requires a full re-release of the tool; and every user of the tool carries every driver, whether they use it or not.

The plugin boundary inverts most of these. A driver ships when its maintainers ship it. A security update in the Yandex Cloud SDK does not require a sc release — the sc-plugin-yandex repository cuts its own release. A user running only Cloudflare does not need the Cloud.ru driver in their process. The trust boundary is explicit: sc verifies the driver binary before executing it, rather than trusting that whatever was compiled in at build time is still the right thing.

The broader conversation has been moving toward this pattern. Respan’s launch on Hacker News last week — an AI gateway built entirely around a plugin model — attracted comments exploring the exact same question: when should a feature be in the core versus an extension? One commenter’s framing was sharp: “Generally, when we use the term ‘plugin’ in industry, this means we do not have to run a compiler.” That is the expectation the sc plugin model now satisfies.

Where things stand

The plugin bus is in the released sc binary — release v2026.10.30 ships with cosign bundle, SLSA in-toto attestation, and CycloneDX SBOM attached. Three drivers are published. The compatibility test passes.

The part that is not yet shipped: the binary size reduction. Moving Cloudflare and Yandex out of the core will drop the sc binary by a meaningful amount once those in-tree copies are removed. That work is on an open branch, not merged. The post you are reading is about the seam, not the number — the number will come when it does.

The back-compat bar was set high deliberately. A deployment tool that silently re-creates resources during an upgrade is not a tool you can trust. The first thing the plugin era needed to prove was that the boundary is real and the contract holds.

It does.

Simple Container’s public release is tagged in the api repository . If you are running sc against an existing stack and want to understand what the plugin-era upgrade looks like in practice, reach out .