Azure and AWS marketplace listings for barakoCMS, deployed through BaryoVM

**Updated 14 September 2026, after D23 (#800).** BaryoVM is the one deploy engine, so an Azure or AWS deploy runs through BaryoVM rather than a template of its own: the barako stack recipe (BaryoDev/BaryoVM#87) poured onto Azure or AWS container targets through the owner's signed-in CLIs (BaryoDev/BaryoVM#81, #82). What stays here is Route B, the marketplace listings, which can list that path once it exists. Route A below is superseded by #590 as rewritten.

---

The goal: tell a potential user they can spin barakoCMS up on their own cloud rather than reading a compose file first.

Both marketplaces support this and neither accepts a compose file. What they take is a deployment template plus images, and the work splits into two very different sizes.

## Two routes, and the cheap one gets most of the value

### Route A: launch buttons in the repo. Days, no account, no review.

A public ARM/Bicep template gives a **Deploy to Azure** button. A CloudFormation template gives an equivalent AWS quick-launch URL. Both are a link in the README that opens the cloud's own deployment form with the parameters filled in.

No Partner Center account, no AWS seller registration, no listing review, no tax or banking paperwork. The claim it supports is "one click to run this on your own cloud", which is the claim actually being made.

There is already `.agent/workflows/deploy-fly-io.md`, so this is extending a pattern rather than starting one.

### Route B: actual marketplace listings. Weeks, and paperwork.

**AWS** takes a container product: images plus one to four delivery options, each a deployment template for ECS or EKS. Free listings are allowed and still require a registered seller account with tax and banking details. Note that AWS discontinued Quick Launch for Helm chart deployments on EKS on 1 March 2026, so an ECS task definition or a plain container delivery is the lower-friction path now.

**Azure** takes an Azure Application offer with a solution template plan, which is an ARM template. Solution templates are not transactable, which suits a free MPL-2.0 product: the template deploys, and no billing runs through the marketplace. It needs a Partner Center account enrolled in the marketplace program.

Route B's real benefit is discovery, being found by someone browsing the marketplace, and procurement, since some organisations can buy through a marketplace far more easily than they can approve a new vendor. Neither benefit exists until there is something to find.

## What has to be true first, and two of them are already filed

**#333, the images are amd64 only.** Graviton on AWS and Ampere on Azure are the cheapest compute on both clouds and a large share of what reviewers and users run. Listing images that cannot run there is a bad first impression at best and a rejected listing at worst.

**#351, the API images run as root.** AWS's container product policy states images should run with non-root privileges by default and require least privilege. This is a stated listing requirement, not a preference.

**A 4.0.0 release exists.** Nothing can be listed that has not shipped. This is the honest reason Route B is not a today decision.

**No known vulnerabilities or end-of-life packages in the image.** AWS scans and rejects on this. The CI dependency gates cover the .NET and npm trees; nothing currently scans the built image's OS layer, which is a different surface. Worth adding a Trivy or Grype step to the release regardless of any listing.

**A managed database option.** The compose stack runs Postgres as a container with a local volume, which is right for a laptop and wrong for a cloud template. A user deploying from a marketplace expects RDS or Azure Database for PostgreSQL. The application needs no change, since it takes a connection string, but the template has to offer the choice and the docs have to say which is supported.

## What the compose file already gets right

Worth recording, because it is the part people usually fail: `quickstart/docker-compose.yml` uses `${DB_PASSWORD:?set DB_PASSWORD in .env}` rather than a default password, for the database, the JWT key and the initial admin password. Shipping default credentials is a standard review rejection and a standard breach, and this stack refuses to start instead. A generated-secret template inherits that.

## Recommendation

Route A now, Route B after 4.0 ships. Route A is small, reversible, needs no relationship with either vendor, and supports the claim being made. Route B is a distribution and procurement play worth making once there is a released thing to list and the two blockers above are closed.

## Done when

- A **Deploy to Azure** button and an AWS quick-launch link in the README, both deploying a working instance with generated secrets.
- Each template offers a managed database as well as a containerised one, and the docs say which is supported.
- An image vulnerability scan runs in the release, so the answer to "does it contain known vulnerabilities" is a job rather than an opinion.
- A decision recorded on whether to pursue Route B, with the account setup it needs.

Related: #333, #351, #302 for the support policy a listing has to state.