Notifications and email relay

Tasmanian Cloud separates an infrastructure event from the way that event is delivered. This lets one state change, including a patch finding, feed a notification service, an email message, a webhook, or your own application.

Providers

ntfy-compatible notifications

Use an ntfy-compatible provider for simple operational messages. Topics can represent a service, environment, or team. The workload does not need to know which operator devices are subscribed.

Email relay

Use the email relay for account messages, deployment summaries, reports, and application workflows that need normal mail delivery. The relay provides a platform boundary for sending without placing mail credentials inside every workload.

Webhooks

Use a webhook when the receiver should take an action. Read events and webhooks for message verification and reconciliation patterns.

Delivery model

flowchart LR
    EVENT[Platform event]
    POLICY[Delivery policy]
    NTFY[ntfy-compatible provider]
    MAIL[Email relay]
    HOOK[Webhook]
    EVENT --> POLICY
    POLICY --> NTFY
    POLICY --> MAIL
    POLICY --> HOOK

Delivery state is separate from resource state. A notification provider can fail without changing whether the workload is healthy. The failed delivery remains visible to the system that owns the policy.

Patch report delivery

Patch reporting is useful only when it reaches the workflow that owns remediation. Send a critical finding to a webhook or ntfy-compatible topic. Send a routine package report by email. Keep the full finding queryable through the API for a dashboard or reconciliation service.

Keep credentials out of workloads

Kleis can hold relay credentials and signing keys as encrypted references. A workflow receives a scoped capability when it is allowed to send. It does not need a reusable plaintext secret in its environment or in an AI-generated configuration file.