max-voitcov
2d1caf6e73
Six new resources, all backed by endpoints that did not exist before v0.30.0
and verified end-to-end against a live v0.30.2 instance:
dokploy_network Docker networks, now first-class. Services attach
through network_ids, which is what deprecates
Compose's isolated_deployment upstream.
dokploy_dns_provider Cloudflare or Route53, so adding a domain creates
its DNS record.
dokploy_vault_provider Env values resolved from HashiCorp Vault, Infisical,
AWS, Doppler, Azure or Scaleway at deploy time, so
the secret never lands in Dokploy or in state.
dokploy_schedule Cron jobs in a container, a stack, or on a server.
dokploy_volume_backup Scheduled backups of a named volume — the companion
to a mount that persists.
dokploy_libsql The sixth managed database engine.
libsql.create is the strictest endpoint in the API: eleven keys required to
be present, several only meaningfully null, no generated service name, and it
returns `true` rather than the row. CreateDefaults and ListIDs absorb all
three so the resource behaves like every other database.
Also filled the gaps a field-by-field diff against the live schema turned up:
domain gains `enabled` (the v0.30.0 park-a-domain toggle), compose gains
create_env_file, icon and service_networks, application gains icon and
preview_require_collaborator_permissions, and mounts accept libsql.
DNS and vault credentials are masked by Dokploy on read, so `config` is
tagged noread and keeps the configured value, as the basic-auth password
already does.
2.4 KiB
2.4 KiB
page_title, subcategory, description
| page_title | subcategory | description |
|---|---|---|
| dokploy_schedule Resource - dokploy | A cron job Dokploy runs on a schedule. schedule_type selects where the command runs: application — inside a running application container; set application_id.compose — inside one service of a Compose stack; set compose_id and service_name.server — on a remote server; set server_id.dokploy-server — on the Dokploy host itself. ~> A schedule targeting an application runs inside its container, so the container has to be running when the cron fires. |
dokploy_schedule (Resource)
A cron job Dokploy runs on a schedule.
schedule_type selects where the command runs:
application— inside a running application container; setapplication_id.compose— inside one service of a Compose stack; setcompose_idandservice_name.server— on a remote server; setserver_id.dokploy-server— on the Dokploy host itself.
~> A schedule targeting an application runs inside its container, so the container has to be running when the cron fires.
Schema
Required
command(String) Command to run.cron_expression(String) Standard five-field cron expression, for example0 3 * * *.name(String) Display name of the schedule.
Optional
app_name(String) Docker service name the schedule targets. Derived by Dokploy when omitted.application_id(String) Application this schedule belongs to.compose_id(String) Compose stack this schedule belongs to.description(String) Free-form description.enabled(Boolean) Whether the schedule is active.schedule_type(String) Where the command runs. Valid values:application,compose,server,dokploy-server. Defaults toapplication.script(String) Multi-line script to run instead of a single command.server_id(String) Server this schedule runs on.service_name(String) Service inside a Compose stack to run the command in.shell_type(String) Shell used to interpret the command. Valid values:bash,sh. Defaults tobash.timezone(String) IANA timezone the cron expression is evaluated in, for exampleEurope/Berlin.
Read-Only
created_at(String) RFC 3339 timestamp of when the schedule was created.id(String) Unique schedule identifier.