Dokploy · Rate Limits

Dokploy Rate Limits

Rate limit definitions for the Dokploy API. Dokploy is a self-hostable platform and the upstream open-source distribution does not document per-key rate limits — operators are responsible for sizing the host and applying their own reverse-proxy / API-gateway throttling. Dokploy Cloud applies operational fair-use throttling but does not publish per-tier numeric limits at the time of profiling. Values below are scaffold defaults consistent with a self-hosted PaaS control plane.

Dokploy Rate Limits is the machine-readable rate-limit profile for Dokploy on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 4 rate-limit definitions, across the self-hosted, cloud-hobby, cloud-startup, and cloud-enterprise tiers, measuring requests_per_second and requests_per_minute.

The profile also includes 4 backoff/retry policies defined and response codes documented for throttled, quotaExceeded, and serviceUnavailable.

Tagged areas include PaaS, Self-Hosted, Docker, Rate Limiting, and Quotas.

4 Limits Throttle: 429 Quota: 429
PaaSSelf-HostedDockerRate LimitingQuotasThrottling

Limits

Self-Hosted (Operator-Defined) operator
requests_per_second · second
-1
The upstream open-source distribution does not enforce a documented per-key request limit. Operators should configure Traefik, an upstream reverse proxy, or an API gateway to apply limits appropriate to their hardware and tenant model.
Cloud Hobby Fair Use api-key
requests_per_minute · minute
60
Scaffold value. Dokploy Cloud applies operational fair-use throttling but does not publish a numeric per-minute ceiling for the Hobby tier.
Cloud Startup Fair Use api-key
requests_per_minute · minute
300
Scaffold value reflecting higher fair-use headroom for the Startup tier.
Cloud Enterprise Negotiated contract
requests_per_minute · minute
-1
Negotiated as part of the MSA / SLA. Effectively uncapped subject to fair use and shared-infrastructure protections.

Policies

Backoff Strategy
Clients should implement exponential backoff with jitter and honor `Retry-After` when a 429 or 503 response is received.
Long-Running Operations
Deploys, builds, and database backups are long-running. Clients should poll deployment status endpoints rather than retrying the trigger operation.
Webhook and Schedule Loops
Avoid configuring webhook receivers or schedules that re-trigger the same deployment faster than the build can complete; this can cascade into platform-level throttling.
Self-Hosted Sizing
For self-hosted deployments, throughput is bounded by the host's CPU, memory, disk I/O, and Docker daemon throughput rather than by application-level rate limits.