apx-dokploy

Dokploy for Action Platform: the dokploy deploy target, its overlay, readiness checks, and tools that read what runs on the instance. apx- is the prefix every Action Platform extension carries.

action-platform plugin install dokploy
export DOKPLOY_URL=… DOKPLOY_API_KEY=…      # or Plugins → Dokploy → Configure on the platform
action-platform cloud set dokploy               # Dockerfile, compose file, image workflow
action-platform deploy --dry-run                # readiness: settings, image, key, application
action-platform deploy                          # point Dokploy at <image>:<version>, follow to done
action-platform diagnose

How it works

The build never runs on the platform or on Dokploy. The overlay's workflow publishes ghcr.io/<owner>/<repo>:<version> on every published release; the target tells Dokploy which tag to run and waits for the deployment to end. Every deployment therefore references a release, and rolling back is pointing at the previous tag.

Configuration

platform.toml:

[deploy]
target = "dokploy"
# url = "https://dokploy.example.com"    # overrides the plugin option
# image = "ghcr.io/acme/shop"            # default: ghcr.io/<[source_host] repo>
# project = "shop"                       # default: [project] name
# application = "shop"                   # default: [project] name
# port = 8000
# health = "/health"                    # checked after the deploy; "" skips it

[deploy.domains]
prod = "shop.example.com"
dev = "shop-dev.example.com"

[deploy.env]                             # set on the application before each deploy,
LOG_LEVEL = "info"                       # over what it already has

Plugin options (Plugins → Dokploy → Configure on the platform; on a machine, the environment or ~/.action-platform/plugins/dokploy.json):

A deploy job carries the options as AP_DOKPLOY_<KEY>.

Requirements

• Dokploy 0.20 or newer (projects with environments; application.saveDockerProvider).
• An API key without a rate limit (Settings > API Keys): a deploy makes more calls than a limited key allows and gets 401 half-way.
• The image published before the deploy: on GitHub, the overlay's workflow does it on every release. Another CI publishes <image>:<version> itself; the image.published check waits for it.
• The container listens on $PORT (8000 in the overlay's Dockerfile).

Development

pip install -e ".[dev]"
ruff check . && ruff format --check . && pytest

Tests never reach the network: tests/fake.py is a Dokploy in memory.