Back to articles

One event, the delivery path you choose

Route infrastructure events to an ntfy-compatible provider, an email relay, a webhook, or your own application.

Infrastructure event routed to notification, email, and webhook delivery providersTasmanian Cloud infrastructure event routed to notification, email, and webhook delivery providers.[DELIVERY]EVENTone messageNTFY / EMAILproviderTEAMdeliveredKeep the boundary explicit. Let each system do the work it is good at.

Delivery is a provider boundary

An infrastructure event records what happened. A delivery provider decides how a person or another system receives it. Keeping those concerns separate prevents a mail outage from changing the state of a running workload.

The same event can be delivered through more than one path when the customer needs both automation and human awareness.

ntfy-compatible notifications

An ntfy-compatible provider is useful for fast operational signals. Topics can represent a service, environment, or team. The workload does not need to know which devices are subscribed.

This keeps notification configuration outside application code and makes a new consumer a provider configuration change rather than a redeploy.

Email relay

The email relay is for account messages, deployment summaries, patch reports, and application workflows that need normal mail delivery. It gives the platform a controlled sending boundary without putting mail credentials in every workload.

Inbound email actions can also be routed to an encrypted store, a webhook, or a forwarding destination according to the action configuration.

Webhooks for machines

Use a webhook when the receiver should take an action. The receiver can start a workflow, update a record, or request current state from the API.

Delivery retry and idempotency belong to the delivery service. Resource state remains owned by the API and runtime.

Patch reports without alert noise

A customer may want a weekly package report, an immediate critical finding, or a webhook for every scan. These are delivery policies over patch findings, not three different scanners.

The report can show what is installed, what is missing, when the host was last scanned, and whether a remediation run has been requested.

Credentials stay behind the provider

Kleis can hold relay credentials, webhook signing material, and mail configuration as encrypted references. A delivery worker uses the capability it needs and does not distribute a reusable secret through workload configuration.

Need the implementation details?

Read the Tasmanian Cloud documentation ↗