Dokploy API

Use for Dokploy-specific API operations (apps, deployments, databases, domains, backups, settings) when tasks explicitly involve Dokploy. Route requests to d...

Security Scan

The skill's files, instructions, and manifest consistently describe a Dokploy API client and require only an x-api-key; nothing in the package appears disproportionate or unrelated to its stated purpose.

Purpose & Capability

Name/description, manifest, openapi.json, and the modular docs all align: this is a documentation-driven, instruction-only skill for calling Dokploy API endpoints. The listed modules and endpoints are coherent with the stated Dokploy operations.

Instruction Scope

SKILL.md stays within the Dokploy domain and prescribes safe, inspect-first flows (classify intent, resolve identifiers, preflight checks, verify after mutation). Minor note: SKILL.md refers to an 'Auth/profile source: Dokploy user profile token + x-api-key' but does not instruct the agent to read any specific local files or environment variables; this is a small documentation ambiguity rather than unexpected behavior.

Install Mechanism

No install spec and no code files that would be executed; the skill is instruction-only and therefore does not install additional packages or write to disk.

Credentials

Manifest declares API auth via x-api-key (apiKey in header) and SKILL.md repeats that. However SKILL.md also mentions a 'Dokploy user profile token' alongside x-api-key while requires.env lists none — this is a minor inconsistency to clarify (the runtime may expect the agent/platform to supply credentials). No unrelated credentials or excessive environment access are requested.

Persistence & Privilege

always is false and the skill is user-invocable. It does not request persistent system privileges or attempt to modify other skills or system-wide settings.

Assessment

This package appears to be a coherent, read-and-call documentation bundle for the Dokploy API. Before installing/use: (1) confirm you will provide a valid x-api-key to the agent (and ask the author whether a separate 'user profile token' is also required, since SKILL.md mentions it but the manifest does not); (2) only enable the skill for tasks that explicitly involve your Dokploy instance — the skill can perform create/update/delete actions so require explicit intent for destructive operations; (3) avoid pasting raw API keys or tokens into chat — store them in the platform's secure credential store if possible and limit the key's permissions; (4) verify you trust the external base URL (https://dokploy.achals.me/api) and review the included openapi.json for the exact endpoints the agent will be able to call. If you want a stricter assessment, provide any runtime policy the platform uses for supplying the x-api-key/profile token (where those credentials will live and how they are scoped).

Dokploy API Skill

Use this skill to operate Dokploy through its API schema and generated domain modules.

Scope guardrails

• Use this skill only when the task is explicitly about Dokploy.
• Do not use this skill for generic Docker/Kubernetes guidance unless Dokploy endpoints are involved.
• Authenticate with x-api-key header.
• Prefer minimal, reversible changes.

Routing (module-first)

Start at modules/_index.md, then load only the smallest matching module.

Common routes:

• Applications/deployments: modules/application.md, modules/deployment.md, modules/rollback.md
• Databases: modules/mysql.md, modules/postgres.md, modules/redis.md, modules/mongo.md, modules/mariadb.md
• Networking/TLS: modules/domain.md, modules/redirects.md, modules/certificates.md, modules/port.md
• Platform settings/security/backups: modules/settings.md, modules/security.md, modules/backup.md
• Git providers: modules/github.md, modules/gitlab.md, modules/bitbucket.md, modules/gitea.md, modules/gitprovider.md

Standard execution flow (required)

1. Classify intent and choose module by operation family.
2. Resolve identifiers first using read/list/search endpoints.
3. Preflight checks: required fields, scope, target existence, dependency impact.
4. Mutate minimally with the smallest payload required.
5. Verify outcome using read/status/search endpoints.
6. Recover if needed using rollback/redeploy/restart operations where available.

Do not run destructive actions unless user intent is explicit.

Mutation safety policy

For create/update/delete/deploy/stop/restart actions, always enforce:

• inspect before mutate
• verify after mutate
• report exact operation IDs used
• include clear rollback/recovery next step on failure

If required fields are unknown, stop and fetch them from relevant read/list endpoints first.

Secret handling

• Never echo raw API keys or tokens in user-visible output.
• Redact secrets in logs and summaries.
• Prefer environment/secure config storage over inline literals.

References

• Domain index: modules/_index.md
• API snapshot: openapi.json
• Auth/profile source: Dokploy user profile token + x-api-key