{"id":48239954,"title":"Show HN: Compose-to-Cloud Pulumi Providers for AWS, GCP, and Azure","points":4,"user":"lionello","time":1779476357,"time_ago":"10 hours ago","type":"link","content":"

Hi HN,

These are three FOSS Pulumi providers (defang-aws, defang-gcp, defang-azure) that take a Docker Compose-like project and provision it as real infrastructure to the respective cloud: VPC, subnets, load balancers, serverless containers (ECS Fargate, Cloud Run, Container App), builds, managed PostgreSQL, Redis, LLMs, and public/private DNS.

Develop once, deploy anywhere: all three providers expose the same Compose-shaped surface. They contain the same Pulumi resources: Project, Build, Service, Postgres, Redis, LLM. Each service in the Compose services map gets provisioned as one of those resources. Moving between clouds should be as simple as changing the import and nothing else. The Project resource sets up private DNS for service discovery, so Compose services can connect using their Compose service names.

These providers have been rewritten from scratch in Go and are based on the (internal) TypeScript Pulumi code we've been working on for the last 2 years. We haven't reached parity quite yet, but we encourage everybody to use them and share your feedback.

The Pulumi tooling generates SDKs for TypeScript, Python, Go, and C#. The repo has examples for all clouds in all those languages, eg.:

  const app = new defang_aws.Project("demo", {\n    services: {\n      web: {\n        image: "nginx:latest",\n        ports: [{ target: 80, mode: "ingress", appProtocol: "http" }],\n      },\n    },\n  });\n  export const endpoints = app.endpoints;\n

\nA few notes:

- The Compose surfaces is opinionated. We check the service requirements and map it to a concrete cloud resource. For example, on GCP a service without exposed ports would run on Compose Engine, not Cloud Run.

- Portability is at the Compose level. Each cloud's behaviour differs: IAM, native containers, etc. The API is the same, but the materialization isn't.

- The Project resource owns the shared infra (VPC, build pipeline, DNS, LB). The standalone Service, Postgres, Redis resources skip that, so the Service needs a built image.

- Licensing is dual: the provider engine is AGPL-3.0, because we want forks to contribute back to the community. The generated SDKs are Apache-2.0, so no copyleft in your own Pulumi code.

- We're waiting for Pulumi devs to merge our registry PR, so the registry still reflects the old v1 provider docs.

- There's support for runtime "config", ie. parameters, using a ConfigProvider interface, which also support interpolation.

Repo: https://github.com/DefangLabs/pulumi-defang

Happy to dig into how the Compose translation works, where the API diverges between clouds (and why), why Pulumi over CDK/Terraform, or the cloud-specific tradeoffs (AWS uses ECS+ALB, GCP uses Cloud Run with optional CE fallback, Azure uses Container Apps).

- Lio","url":"https://github.com/DefangLabs/pulumi-defang","domain":"github.com","comments":[{"id":48241657,"level":0,"user":"edwardrf2","time":1779483852,"time_ago":"8 hours ago","content":"

Is there any more examples, like deploying an ai agent?","comments":[{"id":48243645,"level":1,"user":"lionello","time":1779499892,"time_ago":"3 hours ago","content":"

There's a PR in that repo to add a crewai sample: frontend, worker, postgres, redis, and chat, embedding models.

https://github.com/DefangLabs/pulumi-defang/pull/270","comments":[]}]}],"comments_count":2}