Dora NodaThe interesting part of Defang's new /defang:deploy command is not that an AI agent can run a deployment command. The important part is that the slash command does not contain the cloud implementation it operates.
Instead, Defang has exposed a three-layer system: an installable skill carries the workflow, a CLI and MCP server expose actions, and open per-cloud Pulumi providers translate a Compose-shaped declaration into resources in a customer's account. That separation is a useful blueprint for any agent-native PaaS—including one that targets owned machines rather than AWS, GCP, or Azure.
The result is a traceable path from prompt to infrastructure, with a place for workflow policy, bounded actions, and execution an operator can audit.
The pattern in one screen
Defang announced three agent skills in April 2026: deploy, estimate, and status. Its Codex plugin packages the skills beside an MCP server configuration, the same general composition OpenAI describes for plugins: reusable instructions plus MCP servers and optional interface components.
The deploy path can be reduced to three layers. Compose is the intent that crosses them rather than a fourth control plane.
| Layer | Defang artifact | What goes in | What comes out | Authority boundary |
|---|---|---|---|---|
| Workflow | Installable /defang:deploy skill for Claude Code or Codex | User intent, repository context, choices about stack and configuration | A seven-step runbook the agent follows, including questions it must ask | Reads project files and decides which bounded action to request; should not invent secrets or cloud support |
| Actions | Defang CLI plus local MCP server | Commands such as authentication, stack selection, config writes, deploy, status, and logs | Structured or human-readable operation results | Holds the authenticated session and mediates mutations; the Codex plugin starts MCP with defang mcp serve |
| Execution | Open AWS, GCP, and Azure Pulumi providers and the CD program | Compose-shaped services plus provider, region, mode, and customer credentials | Cloud resources, endpoints, deployment state, and Pulumi history | Provisions inside the customer's cloud account; provider code determines what is actually created |
Here is the checked-in deploy workflow as an end-to-end trace. The useful detail is not merely the happy path, but the evidence and secret boundary at every handoff.
| Step | Input and actor | Output or evidence | Credential and secret boundary |
|---|---|---|---|
| 1. Validate the CLI | Skill asks the agent to run defang --version and offers npm, Homebrew, or installer commands if missing | Installed CLI version or an explicit install failure | Software installation may mutate the workstation; it does not need application secrets |
| 2. Authenticate | CLI runs defang whoami, then defang login when required | Authenticated identity | Authentication belongs to the CLI flow, not text copied into the conversation |
| 3. Find or create Compose | Agent searches for compose.yaml, asks when several exist, or offers to generate one | A selected, reviewable service declaration | Repository contents are visible to the agent; runtime secret values should not be written into Compose |
| 4. Select a stack | Agent lists or creates a stack with provider, region, deployment mode, and name | A versionable .defang/<stack> file and active stack | Stack metadata is configuration; cloud access remains behind the authenticated execution path |
| 5. Resolve config | CLI lists configured keys; the skill asks for a value or random generation for each unset variable | Config keys become present without the article or Compose file containing their values | Defang can prompt securely or generate a value; the language model should not echo secret material |
| 6. Deploy | CLI runs defang compose up; provider/CD code translates and applies the project | Build and provisioning logs, resource changes, success or error | Customer-cloud credentials authorize the real mutation; Pulumi and the provider own execution semantics |
| 7. Verify | CLI runs defang compose ps, with logs available for follow-up | Service health, replicas, and endpoints | Read access remains sensitive but is narrower than permission to change infrastructure |
That table is the core pattern: the skill orchestrates, the action layer authenticates and executes, and the provider realizes declared intent. It is portable across agent hosts because the workflow is a readable file, not logic trapped in a vendor's chat product.
There is also a material gap visible in the current deploy skill itself: after configuration, it proceeds to defang compose up. There is no separate plan, diff, or final approval stage in the seven checked-in steps. That is not evidence that Defang applies changes recklessly—the CLI and Pulumi may add their own safeguards—but it is evidence that an agent-facing production contract needs to state where approval occurs instead of leaving readers to infer it.
The skill is a state machine, not a deploy button
An MCP tool can describe one operation with typed arguments: deploy this project, fetch these logs, or list these services. A deployment workflow has memory and branches: authentication, file selection, stack state, unresolved configuration, and partial provisioning.
Defang's seven-step runbook puts those decisions in instructions an agent can follow and a human can inspect. The complementary /defang:status skill checks the active stack, reads compose ps, fetches a 15-minute log window, and expands to an hour when necessary. Together they demonstrate why workflow and tools are different product surfaces: tools expose verbs; skills teach an agent when and in what order to use them.
A representative production workflow still needs explicit behavior for branches beyond the first successful deploy:
| Branch | What the current runbook establishes | What a hardened agent surface should return |
|---|---|---|
| Missing authentication | Run login and wait | A typed AUTH_REQUIRED state with a resumable operation after the human completes authentication |
| Several or zero Compose files | Ask the user to select or offer to generate one | Candidate paths, validation errors, and an immutable hash of the file approved for deployment |
| No stack or unset config | Create a stack; ask for or generate config values | Capability-validated choices and key-presence results that never serialize secret values into model context |
| Unsupported Compose feature | Not specified as a distinct branch | A machine-readable capability error naming the service, field, provider, and supported alternatives |
| Partial provider failure | Stream deployment logs | Stable operation ID, resources changed, current observed state, retry safety, and rollback or cleanup options |
| Repeat request | Run the command again | Idempotency key or desired-state comparison so a retry resumes or converges instead of duplicating resources |
| Destructive change | Not separated in the skill | Plan/diff, risk classification, explicit confirmation, and a record of who approved it |
This is the strongest reason not to collapse everything into a magical deploy() tool. A single tool can hide branching, but it cannot eliminate it. When the branch policy lives in an installable skill, teams can add their own default regions, approval rules, health checks, or incident escalation. When the mutations remain typed actions beneath that skill, customization does not require giving the model an unrestricted shell or embedding cloud credentials in prose.
Compose is portable intent; providers do the translation
The second half of Defang's design became visible in May 2026, when the company open-sourced its per-cloud Pulumi providers. The providers share a Compose-shaped Project API, but they deliberately create different native services.
| Declared need | AWS implementation | GCP implementation | Azure implementation | Portability caveat |
|---|---|---|---|---|
| Container compute | ECS Fargate | Cloud Run | Azure Container Apps | Scaling controls, networking, and runtime limits are not identical |
| PostgreSQL | RDS | Cloud SQL | Azure Database for PostgreSQL Flexible Server | Engine versions, extensions, maintenance, and HA choices differ; Azure was announced with pgvector enabled |
| Redis | ElastiCache | Memorystore | Azure Managed Redis | Product tiers and TLS/network behavior vary |
| Managed LLM | Amazon Bedrock | Vertex AI | Azure AI Foundry | Model availability, identity, quotas, and request semantics remain provider-specific |
| Identity and network | IAM roles, VPC resources | Service accounts, VPC resources | Managed identities, VNet resources | The same least-privilege goal compiles into three permission models |
| Image build | ECR and CodeBuild | Artifact Registry and Cloud Build | Azure Container Registry | Build caching, quotas, and regional availability differ |
The provider repository makes the boundary unusually concrete. Its CD program receives Compose, translates it into a Pulumi program, and runs pulumi up or destroy. A Project provisions shared networking, DNS, load balancing, build infrastructure, and services; the same declared services can target another supported cloud by swapping the provider import.
“Same Compose” therefore does not mean identical infrastructure, and “any customer's cloud” should be read as any supported provider and capability combination, not an unbounded multi-cloud promise. Azure support was announced as preview, and standalone provider components do not support every feature that the project-scoped path can provide. A good abstraction exposes those differences as capabilities before apply rather than surprising the operator halfway through provisioning.
The open-source boundary matters too. Defang licenses the provider engines and CD program under AGPL-3.0, while generated TypeScript, Python, Go, and .NET SDKs are Apache-2.0. Security teams can inspect the resource, IAM, and network code that will run against their accounts, while application teams can consume generated SDKs without forking the engine. That is more meaningful portability than offering one proprietary API from three regions.
The abstraction leaks—and that is useful evidence
Skills are markdown instructions. They are legible and forkable, but they are not transactions, authorization policy, or a live capability registry. That creates a new form of interface drift: the words an agent reads can age independently from the backend it calls.
Defang's public provider announcement and agent-skills documentation name AWS, GCP, and Azure. In the repository snapshot reviewed for this article, the deploy skill's stack instructions still list AWS, GCP, and DigitalOcean, while the Codex plugin manifest also describes AWS, GCP, or DigitalOcean. This may simply be a documentation rollout lag. It is nevertheless a perfect example of why an agent should query capabilities from the authenticated target instead of treating a prose list as truth.
Four controls turn that leak into a manageable contract:
- Capability discovery:
capabilities(provider, region)returns supported service fields, managed components, modes, and preview flags from the backend the agent will actually use. - Versioned plans: a plan identifies the skill version, API version, provider version, Compose hash, target account, and expected changes. Approval attaches to that exact artifact.
- Idempotent operations: mutations accept an idempotency key and return a stable operation ID. An interrupted agent can observe or resume the operation instead of guessing whether to rerun it.
- Auditable state: status separates desired state, observed state, last transition, and evidence. Logs help explain an error, but they are not a substitute for structured state.
Least-privilege credentials complete the model. The skill needs repository context and permission to request actions. The action layer needs a scoped user or service identity. The provider execution task needs only the cloud permissions necessary for the approved plan.
No layer should inherit every credential merely because all three participate in one conversation.
Cross-agent installability and backend portability are separate claims. A skill can run in Claude Code and Codex while targeting one proprietary backend; an open provider can still have a vendor-only workflow. Defang advances both dimensions, but platform teams should version them independently.
A concrete Bex blueprint: skill above MCP, state below it
Bex.co has a different infrastructure boundary. It is an open-source, AI-native Render alternative: a developer supplies a Git repository or image and gets a running HTTPS service on machines the operator owns. The control plane exposes a Render-compatible API and MCP, while Cluster API manages machine lifecycle.
Bex should not copy Defang's managed-service mappings or present itself as a multi-cloud abstraction. It should copy the layering discipline.
| Concern | Observed Defang pattern | Proposed Bex surface |
|---|---|---|
| Portable workflow | /defang:deploy, estimate, and status skills install into independent coding agents | An installable /bex:deploy skill that any compatible agent can read, fork, and version |
| Capability check | Skill describes providers and modes; CLI supplies runtime behavior | capabilities returns supported service types, plans, regions/node pools, build inputs, and current API version |
| Project inspection | Find or generate Compose | inspect reads a repo/image and returns a proposed Bex service declaration plus validation results |
| Pre-mutation artifact | Deploy skill proceeds from config to apply | plan returns service changes, build source hash, target cluster, policy checks, and risk classification |
| Approval | Human choices occur throughout the runbook | /bex:deploy asks for explicit confirmation of the immutable plan before invoking deploy |
| Mutation | CLI and provider run the deployment | deploy(planId, idempotencyKey) returns an operation ID; the core domain layer performs the same operation behind REST, GraphQL, or MCP |
| Observation | compose ps, status skill, and logs | operation, status, and logs expose structured progress, desired/observed replicas, endpoints, health, and evidence |
| Recovery | Diagnosis and CLI follow-up | rollback targets a known deploy revision; the skill explains the impact and asks for approval before mutation |
| Infrastructure boundary | Customer-owned cloud account and provider-native services | Operator-owned machines, Git-to-HTTPS app lifecycle, and Cluster API reconciliation—without claiming managed databases or a universal cloud mapper |
The crucial implementation rule is that MCP stays a thin adapter over the same application operations used by the dashboard and Render-compatible API. An agent should not get a privileged side door with unique semantics. If a deployment is idempotent, authorized, observable, and reversible through the core, it remains so whether the caller is a human in the dashboard, a CI job, or a coding agent following /bex:deploy.
Defang's launch makes the larger shift visible: the agent-facing workflow is becoming part of the platform product. But trust does not come from a clever prompt. It comes from keeping portable instructions above typed operations, and keeping authentication, desired state, reconciliation, and audit evidence below them.
Bex.co is the open-source, AI-native Render alternative—push a Git repository, get a running HTTPS service on machines you own, and operate it through a Render-compatible API designed for both people and agents. Star the repository on GitHub or explore the Bex API architecture.
