Overview of Envault's email and in-app notification system and how to configure preferences.

Envault sends both in‑app and email notifications to keep users informed about activity and security events. This page explains the types of alerts available and how they can be customized.

Notification Categories

Preferences are grouped into seven matched categories for email and in‑app channels. Each flag corresponds to one or more notification types generated by the system:

Category	Email Types	In‑App Types
Access Requests	`access_request_received`	same
Access Granted / Role Changes	approvals, denials, invitations, membership changes	same
Device Activity	new device access, new location, unknown login	same
Security Alerts	password/email changes, 2FA events, encryption failures, security advisories	same
Project Activity	secrets added/updated/deleted, bulk ops, project CRUD, settings changes, members joining/leaving	same
CLI Activity	`secrets_pulled`, `secrets_pushed`	same
System Updates	system releases, maintenance notices, rate‑limit warnings, email failures	same

The digest frequency setting controls whether email notifications are sent individually (none), daily, or weekly. Digests bundle multiple alerts into a single message.

Default Settings

When a new account is created, the system initializes preferences with secure defaults:

Email: only access requests, access granted, and device activity are enabled by default.
In‑App: all seven categories are enabled.
Digest: none by default.

These defaults can be changed in the UI (see next section) or via the API.

Users can view and update their notification settings from Settings Notifications in the web application. The preferences page presents a series of toggles and a drop‑down for digest frequency.

// excerpt from /src/components/notifications/notification-preferences.tsx
const defaultPreferences: NotificationPreferences = {
  email_access_requests: true,
  email_access_granted: true,
  email_device_activity: true,
  email_security_alerts: false,
  email_project_activity: false,
  email_cli_activity: false,
  email_system_updates: false,
  app_access_requests: true,
  app_access_granted: true,
  app_device_activity: true,
  app_security_alerts: true,
  app_project_activity: true,
  app_cli_activity: true,
  app_system_updates: true,
  digest_frequency: "none",
};

Changes are persisted immediately through an API endpoint; users can also press ⌘ / Ctrl + S to save from the keyboard.

Programmatic Access

The /api/notification-preferences server action (see src/app/notification-actions.ts) allows the CLI or other clients to read and modify the current user’s preferences. This is particularly useful for automation or provisioning scripts.

Notifications in the App

In‑app alerts appear in the icon in the upper‑right corner of the dashboard. They are stored in the database (see notifications table) and can be marked read or archived. The same underlying types power both the UI badges and the email templates.

Developers extending Envault should consult src/lib/types/notifications.ts for the exhaustive list of types and associated icons.

Example Email Template

Envault uses Resend for delivery. Email content is rendered server‑side with a Handlebars template that includes a title, message body, and optional action button when appropriate. See src/lib/email.ts for the implementation details.

Troubleshooting

If users do not receive expected email notifications:

Confirm that RESEND_API_KEY is configured and the service is reachable.
Ensure the email_* flags in notification preferences are set correctly.
Check mail logs for bounces or rate‑limit errors (also surfaced as email_failed notifications in‑app).

For high‑volume installations, review the supabase/migrations/20260224000001_expand_notification_preferences.sql migration, which adds the granular preference columns and sets secure defaults.

For more details about how notifications integrate with other parts of the system, see the API overview or inspect the source code under src/lib/notifications.ts.

Notifications