Configuration
Set options in the config block of the dms-automation entry of antelope.config.ts. All of them are optional.
| Key | Type | Default | Description |
|---|---|---|---|
runs.retentionDays | number | 30 | Days a run is kept. Older runs are deleted every hour by the leader instance. 0 keeps every run. |
runs.sensitiveNames | string[] | [] | More header and query parameter names whose value is a credential, matched case-insensitively as part of the name. Added to the built-in list (Authorization, Cookie, *token*, *secret*, *signature*, *hmac*, *-key…). A run stores, shows and replays these values as [redacted]. |
httpRequest.blockPrivateNetwork | boolean | false | Refuse HTTP requests to this server's network. See below. |
cluster.driver | "auto" | "redis" | "memory" | "auto" | How instances coordinate. See Clustering. |
HTTP request: private network
The built-in HTTP request action can call any address the server can reach, its own network included. When procedures are built by people you do not fully trust, or when a URL can come from a webhook payload, turn on blockPrivateNetwork:
"dms-automation": {
config: {
httpRequest: { blockPrivateNetwork: true },
},
},
The step then fails when the host resolves to a loopback (127.0.0.0/8, ::1), private (10/8, 172.16/12, 192.168/16, fc00::/7), carrier-grade NAT (100.64/10), link-local (169.254/16, fe80::/10, cloud metadata endpoints included), multicast or reserved address, or to a NAT64 address embedding one of them. Each redirect is checked too. DNS rebinding between the check and the connection is not covered.
Every request also has a timeout (timeoutMs, 30 seconds by default, at most 5 minutes, set per step), and a response larger than 2 MB is refused.
Webhooks
Webhooks are served by the API server, under the path set on the trigger, never through the dashboard's frontend server. A path cannot overlap a route the server already serves, nor start with /api, /auth, /dms, /modules or /settings, and two enabled procedures cannot share the same method and path. The Library and the Builder show each webhook's full URL on the DMS apiBaseUrl: set it to the URL callers reach your API at.
Clustering
By default the module runs standalone: a single instance owns every trigger, and there is nothing to configure. To run several instances against shared state, wire @antelopejs/interface-redis in the project and start more than one instance; the module then coordinates them on its own.
cluster.driver | Behaviour |
|---|---|
auto | Redis when @antelopejs/interface-redis is provided, standalone otherwise. |
redis | Force clustered mode; falls back to standalone, with a warning, when the interface is absent. |
memory | Force standalone, even when Redis is wired. |
Each trigger type declares how it fires across a cluster:
singleton(cron, table watch): fires once cluster-wide. Only the elected leader activates it; leadership is a renewable Redis lock, so another instance takes over when the leader stops.replicated(webhook, manual): every instance activates it; the load balancer routes each event to one instance.
Procedure and template edits made on one instance reach the others over Redis pub/sub, so every instance reconciles its triggers without a restart.
activate and deactivate fast.