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.
A `dokploy_mount` with `type = "volume"` and no `volume_name` was accepted
by both this provider and Dokploy. Dokploy renders the mount as
`{Source: volumeName || "", Target: mountPath}`, and Docker reads an empty
source as an anonymous volume: every deploy created a fresh one and orphaned
the last, so the data never survived a redeploy while disk usage climbed.
Nothing errored at any point, which is what made it worth catching here.
The pairing is now checked at plan time, before anything is created, and the
error explains the consequence rather than only the rule. The same validator
covers `bind` without `host_path` and `file` without `file_path`, and rejects
a field set against the wrong type, which Dokploy would otherwise ignore.
Verified against a live v0.30.2 instance: the offending config plans cleanly
before the change and is refused after it.
Two things ResourceSpec could not express: plan-time checks that span
several attributes, and create bodies that need a key Dokploy insists on
receiving but the model cannot produce. Both are used by the commits that
follow.
setup-go caches by default. act_runner's built-in cache server binds to
an address job containers cannot route to, so every restore and save
blocks until it times out:
Failed to restore: getCacheEntry failed: connect ETIMEDOUT 10.0.2.12:40789
Failed to save: reserveCache failed: connect ETIMEDOUT 10.0.2.12:40789
That was 634s of a 946s build. Disable caching until the runner's
cache.host points somewhere reachable, then turn it back on.
Gitea lists "Terraform" among its package registries, which reads as if
the provider could be published there. It stores remote state for the
http backend -- not modules, not providers.
Gitea implements no Terraform provider registry, so distribution goes
through release archives plus a filesystem mirror. GoReleaser targets
the Gitea release API; the archive names follow HashiCorp's convention
because that is the only shape a filesystem mirror recognises.
No GPG signing: signatures are a registry-protocol requirement and a
filesystem mirror never checks them.
Cross-repo links point at Gitea; Go module paths deliberately do not.
Plugin-framework provider covering projects, environments, applications,
Compose stacks, managed databases, domains, mounts, ports, redirects,
basic auth, registries, SSH keys, certificates and backup destinations,
over Dokploy's tRPC-over-REST API.
The shim package exposes the provider to other Go modules, which is how
pulumi-dokploy bridges it.
max-voitcov
usr_unknown