feat: DigitalOcean Marketplace 1-Click Droplet listing for Trinity (vendor application + Packer snapshot, AI Agents category)

[vybe]

Summary

List Trinity as a DigitalOcean Marketplace 1-Click Droplet — vendor application, Packer-built snapshot via DigitalOcean's marketplace-partners tooling, listing copy, and a referral link — placed in the Marketplace's AI Agents category.

Context

DigitalOcean is the only major cloud with an open, documented vendor path for OSS projects (vendor form → Vendor Portal → snapshot review), it is free to list, and it already carries Docker-socket-mounting 1-clicks (Coolify, CapRover, Dokku, Cloudron, Easypanel) plus OpenClaw as a Staff Pick in a new "AI Agents" category — so Trinity's runtime shape (sibling agent containers over the host Docker socket) is a known quantity there. Ghost's arrangement (DigitalOcean named "official hosting partner", $100-credit signup link in the docs) is the co-marketing model to ask for.

Depends on the pull-only images / unattended first-boot work (#2280) — a snapshot that builds the agent base image on first boot does not meet the one-click bar.

Acceptance Criteria

Revised 2026-09-10 against digitalocean/marketplace-partners@b708788 and
droplet-1-clicks@master — see the audit comment. Items marked ✅ are verified in #2522.

Image

• Packer template (per github.com/digitalocean/marketplace-partners) builds an Ubuntu 24.04 snapshot, passes cleanup.sh + img_check.sh with 0 FAILED, with a first-boot script that starts Trinity unattended — verified on trinity-v0-9-5-rc2-20260903 (fix(packer): make the DigitalOcean 1-Click bundle actually buildable (#2281) #2522).
• Built on the $6 build droplet (s-1vcpu-1gb), per DO's "will ensure that all Droplet types will be available" guidance — currently s-2vcpu-4gb, which excludes every plan under 80 GB disk. Record the measured snapshot size here; if it does not fit 25 GB, use the smallest size that does and say which. Measured (2026-09-11): the v0.9.5-rc3 snapshot built on s-1vcpu-1gb is 9.3 GB with a 25 GB minimum disk, so it fits every plan.
• The build installs security updates (apt full-upgrade, as DO's reference template does). img_check scores pending security updates as FAIL, so without this a rebuild fails on any day Ubuntu has published one that unattended-upgrades has not yet applied.
• The first-boot Caddyfile carries header X-DO-MARKETPLACE "trinity" (build standard rule 10).

Listing

• packer/digitalocean/listing.md exists (build standard rule 11): system components, sizing table, getting started, and how to start/stop/restart/update. This is the source text for the Vendor Portal listing — needs no snapshot.
• Listing recommends ≥8 GB droplets; first-login MOTD prints how to get in and the next steps: the URL to claim the instance on a browser-claim install (no password is generated, abilityai/trinity-enterprise#580), or that the password is the one supplied through user-data. Live listing: "At least 4 GB RAM and 2 vCPUs; 8 GB and 4 vCPUs recommended"; the v0.9.5 MOTD (99-trinity) handles the unclaimed case.
• Listing states support contact + that DigitalOcean does not support the software (vendor-terms requirement).
• Ruling recorded on Managed Database (DBaaS) integration — a Vendor Portal checkbox, and Trinity supports PostgreSQL. Default is v1 without it, filed separately. Ruled 2026-09-11 (@obasilakis): not needed now. v1 ships without it.

Submission and updates

• Vendor application submitted at marketplace.digitalocean.com/vendors and approved (contact: one-clicks-team@) — tracked in abilityai/trinity-enterprise#464. Submitted 2026-09-02; Vendor Portal access granted 2026-09-09 on MAR-7657.
• Another team member has QA'd a droplet built from the exact snapshot being submitted. DigitalOcean's manual test passed and the listing is approved. A green img_check validates DigitalOcean's image requirements, not that Trinity works — and once submitted, the listing is locked in pending/in review and cannot be updated (400) until the review clears.
• Snapshot submitted through the Vendor Portal; app_id captured from the listing URL and recorded here: f98091c25f82a9ccc0f5e53d. Listing: https://marketplace.digitalocean.com/apps/trinity
• Update runbook carries the real PATCH /api/v1/vendor-portal/apps/<app_id> payload (imageId required, reasonForUpdate, osVersion, softwareIncluded[]), the Packer manifest + shell-local post-processor automation, and the fact that an app in pending/in review cannot be updated (400).
• Requested: "AI Agents" category placement, a Trinity referral link ($ credit) for the README, and co-marketing (blog/newsletter). Category: the listing is in AI Agents. Referral link: self-serve in the Vendor Portal. Co-marketing: not yet requested; moved to abilityai/trinity-enterprise#464.
• "Deploy on DigitalOcean" badge added to the Trinity README once live. Moved to abilityai/trinity-enterprise#464; PR docs(readme): link the DigitalOcean 1-Click with a Deploy to DigitalOcean button #2932 is open for review.

Technical Notes

• Reuse the Packer work from One-click VM image for Trinity deployment (GCP + Hetzner) #835; the DO snapshot is a second builder target, not a second image definition.
• Vendor terms: non-exclusive, free, DO may pull a listing at will; vendor supports the app "no less stringently" than for its own users.

[obasilakis]

Scoping note from #2280 work: DigitalOcean 1-Click Droplets have no vendor-defined input form at deploy time. Verified against digitalocean/marketplace-partners — the only configurable prompt is the optional Managed Database checkbox. There is no field for a domain or any app variable, so anything the user must supply has to be collected after first login, from inside Trinity.

TLS is settled and needs no user input: Let's Encrypt IP-address certificates are GA (2026-01-15, shortlived ACME profile, ~6-day validity), and DO's own build standard mandates the pattern — droplet-1-clicks/.github/agents/1-click-agent.md rule 10 requires Caddy + issuer acme + profile shortlived for any app with an HTTP interface. So the snapshot's first-boot script should stand up Caddy with an IP cert; a domain becomes a post-login upgrade.

Two follow-ons for the Packer first-boot script (AC 2): it is where the install-provenance marker for #2380 gets written, and it should pull the agent base image from GHCR and retag it trinity-agent-base:latest (that name is hardcoded in 6+ backend locations). See #2280 for the full scoping notes.

[obasilakis]

Decision: how the user gets the admin password on a 1-Click install

DO 1-Click Droplets have no deploy-time input form (confirmed against
digitalocean/marketplace-partners — only the optional Managed Database checkbox), so the
admin credential has to come from somewhere else. Three shapes were considered.

Shipping: MOTD, read from the DO browser Console. First boot generates the admin
password, start.sh --unattended prints it, and the MOTD carries it plus the URL and next
steps. The user reads it from Droplet → Console in the DO control panel — a browser
terminal, one click, no SSH client and no key. AC3 on this issue already specifies the MOTD;
this records why it is the right one rather than a fallback.

Optional override: user-data. If the user pasted an ADMIN_PASSWORD into DO's
Advanced options → Add Initialization scripts at create time, first boot uses it and never
generates one — zero console, no race, because the password exists before the droplet has an
IP. start.sh --unattended already generates only when the value is blank (#2385), so the
Packer first-boot script just has to pass user-data through rather than always generating.

Open question, must be answered before the snapshot is cut: whether the init-scripts
field is still offered on Marketplace images. If it is not, the override silently does
nothing and only the MOTD path exists.

Rejected: open setup window with no admin at boot

Superficially the best journey — browse to the IP, the setup wizard renders, the user picks
their own password, they never open a console. It is out because on a public marketplace IP
it is a race the legitimate user loses: scanning DO's IP blocks is automated and the human is
still reading the control panel. That is #2381 exactly, which #2385 just closed by making
POST /api/setup/admin-password refuse whenever a usable admin exists. Reopening the window
here would reintroduce it on the one install channel where the operator-responsibility
premise from trinity-enterprise#49 (deploy behind a tunnel until setup completes) does not
hold.

Binding the window was considered and does not rescue it: a time bound plus first-claimer
still loses to a scanner, and a one-time token printed in the MOTD is the shipping option
above with an extra step.

Rejected: password derived from droplet metadata

Droplet IDs are sequential integers, so anyone who creates their own droplet knows the
current range, can scan for Trinity on 443, and try a few thousand derived passwords. Landing
as admin on Trinity means credential injection plus containers on the host Docker socket —
root on someone else's box, with their API keys — and the derived password stays valid until
the owner happens to change it, so it is not a first-boot-only exposure.

Follow-on for the Packer first-boot script

• Read user-data for ADMIN_PASSWORD; generate only when absent.
• MOTD prints the password (or, when user-data supplied it, says so and does not echo it),
  the https://<ip> URL, and the next step.
• Prompt a password change at first login.

[obasilakis]

Open question resolved: user-data is offered on Marketplace images

Verified against the live Create Droplet page with the Docker 1-Click selected
(cloud.digitalocean.com/droplets/new?appId=…&image=docker-20-04). The field exists, under
Additional Options → "Startup scripts (Free)" — "Add scripts to run on initial Droplet
boot up - great for repetitive or initialization tasks."

Note the naming for anyone writing the listing docs: it is not labelled "Advanced
Options" or "Add Initialization scripts", which is how DO's own user-data documentation and
older guides describe it. Documentation for our users must say Additional Options →
Startup scripts, or they will look for a section that no longer exists by that name.

DO's docs never state whether the field applies to Marketplace images
(docs.digitalocean.com/products/droplets/how-to/provide-user-data/ does not mention them,
and droplet-1-clicks/DEVELOPER-GUIDE.md does not mention user-supplied user-data at all),
so this was settled by inspection rather than by documentation.

The override must be #cloud-config + write_files, not a shell script

1-Click per-instance code lives at /var/lib/cloud/scripts/per-instance/, i.e. cloud-init's
scripts-per-instance module. In cloud-init's default cloud_final_modules ordering,
scripts-per-instance runs before scripts-user. So a user-data shell script executes
after our first-boot script has already generated a password and started Trinity — the
override would silently do nothing.

write_files runs in the earlier cloud_config stage, before final, so it lands in time.
Documented form for the listing:

#cloud-config
write_files:
  - path: /etc/trinity/admin-password
    permissions: '0600'
    content: "<your-password>"

First boot reads that path and prefers it; generates only when it is absent — which is
already start.sh --unattended's behaviour since #2385.

Still to confirm empirically (cheap, one droplet, ~$0.01): that write_files actually
lands on a Marketplace image before the per-instance script runs. The ordering above is from
cloud-init's documented module order, not from an observed run on DO.