Notification triggers for domain lifecycle events (added / updated / removed) #4938

What problem will this feature address?

There is currently no way to learn from outside Dokploy that a domain was added, changed or removed.

I run Uptime Kuma on a separate server so I get alerted when one of my domains goes down. Every time
I add a domain in Dokploy I have to remember to create the monitor by hand, and every time I remove
one I have to remember to delete it. The second half is what actually causes damage: a removed domain
leaves a monitor alerting forever, and once you start ignoring false alarms you stop trusting the
alerting altogether.

This is not specific to Uptime Kuma. Anything that needs to react to the set of domains Dokploy
serves has the same gap — external uptime checkers, DNS automation, CDN cache warming, inventory,
n8n flows.

The notification system already covers deployment and maintenance events (appDeploy,
appBuildError, databaseBackup, volumeBackup, dockerCleanup, dokployRestart,
dokployBackup, serverThreshold), and the custom provider already POSTs an arbitrary JSON
payload with user-defined headers. Domains are simply not part of that surface.

The only workaround today is polling, and it is a poor one: the domain router is not exposed
through the OpenAPI/REST surface (11 of the 51 routers in root.ts are), so the options are reading
Dokploy's Postgres schema directly or calling the tRPC HTTP endpoints. Both couple external tooling
to internals that are free to change at any time.

Describe the solution you'd like

Add domain lifecycle events to the existing notification system, following the pattern every other
event already uses.

• Schema: one new boolean on the notification table (domainChanged), so users opt in per
  notification target exactly like the existing triggers.
• Dispatcher: packages/server/src/utils/notifications/domain-changed.ts, structurally the same
  as docker-cleanup.ts — find the notifications with the flag set for the organization, fan out to
  the configured providers.
• Call sites: createDomain, updateDomainById and removeDomainById in
  packages/server/src/services/domain.ts.

Payload for the custom (webhook) provider — no secrets, no PII:

{
  "event": "domain.created",
  "domainId": "…",
  "host": "app.example.com",
  "path": "/",
  "https": true,
  "domainType": "application",
  "serviceName": "my-api",
  "projectName": "my-project",
  "environmentName": "production",
  "organizationId": "…",
  "timestamp": "2026-07-30T12:00:00.000Z"
}

For the chat providers the same event renders as a short message, which is useful on its own — "a new
domain was added to project X" is something teams want to see regardless of any automation.

One implementation detail worth flagging up front: createDomain wraps the insert and the Traefik
manageDomain call in db.transaction, so the dispatch has to happen after the transaction
commits — otherwise a rolled-back domain would still emit an event.

Two things I would rather agree on with you before writing it:

1. One flag or three? I lean towards a single domainChanged flag with the action in the
   payload's event field — less schema surface, less UI — but three booleans
   (domainCreated / domainUpdated / domainDeleted) are just as easy if you prefer the finer
   control.
2. Preview domains. domainType already distinguishes preview, and preview deployments create
   domains automatically. My instinct is to emit them but label them via domainType so consumers
   can filter, rather than having Dokploy decide the policy — happy to exclude them instead.

Scope would be a single focused PR: schema + migration, dispatcher, three call sites, the settings
UI checkbox and an email template.

Describe alternatives you've considered

A built-in Uptime Kuma integration. I looked at this first and decided against proposing it.
Uptime Kuma has no write REST API — its REST surface is read-only and API keys only authenticate
/metrics and push monitors — so monitors can only be created over its undocumented Socket.IO API,
using the account's username and password. Putting that in Dokploy would mean a new
socket.io-client dependency, storing third-party credentials, and inheriting breakage on every Kuma
upgrade, plus the same request would follow for Gatus, Zabbix, Healthchecks.io and others. A
vendor-neutral event covers all of them and keeps the fragile part outside Dokploy, where I am happy
to maintain it myself.

Native uptime monitoring in Dokploy. This is closer to what #2487 is asking for and is a much
larger product decision — the current monitoring service collects CPU/memory/container metrics, not
HTTP availability. I am not proposing it here. This feature is useful either way, and it lets people
keep using the tool they already run.

Polling. Reading Postgres directly or calling tRPC endpoints. Works, but couples external tooling
to internals and reacts a full poll interval late.

Exposing the domain router through the OpenAPI/REST surface. Complementary rather than an
alternative — useful for reconciliation regardless of this feature. Happy to send it as a separate
small PR if you want it.

Additional context

Related to #2487 but deliberately much smaller: that issue asks for observability inside Dokploy,
this one only makes the domain set observable from outside so existing tools can be used.

#2099 asks for a trigger on a different event, which suggests the notification trigger list is a
natural place to extend rather than something to work around.

Will you send a PR to implement it?

Yes