Digitalocean Port

Purpose

This is the reference integration for Harbor http_api Action Model authoring for DigitalOcean.

Use it when:

• building DigitalOcean actions in Harbor
• extending the Dock / Hub DigitalOcean entry
• teaching Codex or OpenClaw how to map an infrastructure API into Harbor Ports and Harbor Actions

Harbor Port worksheet

Product

• Product: DigitalOcean API
• Publisher slug: digitalocean
• Publisher name: DigitalOcean
• Category: Infrastructure
• Tags: digitalocean, cloud, droplets, tags, regions

Safe Harbor Port metadata

• Kind: http_api
• Label: DigitalOcean API
• Description: DigitalOcean API connection managed locally through Harbor.
• Base URL: https://api.digitalocean.com
• Auth mode: header_token
• Auth header name: Authorization
• Auth token prefix: Bearer

Hidden local config

• authToken

Harbor stores the token locally only. Dock / Hub manifests must never contain it.

Harbor action design notes

DigitalOcean is a good Harbor fit when we stay on fixed v2 infrastructure inventory routes and keep low-risk organizational writes narrow.

Good Harbor DigitalOcean actions:

• fixed GET routes like /v2/droplets and /v2/regions
• typed path reads like /v2/droplets/{droplet_id}
• simple POST routes like /v2/tags
• requestBodyMode: "none" for reads
• requestBodyMode: "json" for tag creation
• resultMode: "json_summary" for all starter actions

Avoid for now:

• destructive droplet actions
• broader compute lifecycle automation
• firewall, networking, database, and billing administration surfaces
• dangerous multi-resource destroy flows

Starter DigitalOcean actions

Automatic read actions

• list-droplets -> GET /v2/droplets
• get-droplet -> GET /v2/droplets/{droplet_id}
• list-regions -> GET /v2/regions

Approval-friendly write actions

• create-tag -> POST /v2/tags

Why these actions

These routes fit Harbor's Action Model well because they:

• stay under one fixed DigitalOcean API origin
• use stable REST paths with explicit typed identifiers
• keep reads low risk and easy to validate
• use a narrow, low-blast-radius write for operator review
• keep hidden auth entirely local to Harbor Node

Suggested operator workflow

1. Import the DigitalOcean Dock entry from Dock / Hub.
2. Configure the local DigitalOcean personal access token in Harbor Node.
3. Validate list-droplets first to confirm local auth and scope coverage.
4. Use get-droplet and list-regions to inspect available inventory and placement options.
5. Keep create-tag on require_approval unless your Harbor Guard policy deliberately allows controlled tag creation.

Suggested agent workflow

1. Inspect the existing DigitalOcean Harbor Port.
2. Inspect live actions and drafts.
3. Propose additional fixed-route inventory actions only.
4. Validate and test drafts.
5. Request publish instead of self-publishing unless Harbor explicitly allows it.

Agents should never:

• ask Harbor for the stored API token
• widen DigitalOcean into a generic arbitrary HTTP proxy
• bypass review for infrastructure-changing actions

Current update strategy

For now, DigitalOcean updates are manual:

• update the Dock / Hub integration document in apps/hub/catalog/integrations/digitalocean/digitalocean-api.json
• bump the manifest version when the action set changes materially
• re-import into Harbor or create new drafts from the updated Dock entry

Official reference starting points

• DigitalOcean API overview: https://docs.digitalocean.com/reference/api/
• DigitalOcean droplets reference: https://docs.digitalocean.com/reference/api/reference/droplets/
• DigitalOcean regions reference: https://docs.digitalocean.com/reference/api/reference/regions/
• DigitalOcean tags reference: https://docs.digitalocean.com/reference/api/reference/tags/