Custom Email Provider
The framework uses Resend for production emails and a console logger for local development. You can replace either with any email service — SendGrid, Mailgun, Postmark, Amazon SES, etc.
The NotificationService API stays the same. Only the underlying delivery mechanism changes.
How it works
NotificationModule registers an EMAIL_PROVIDER injection token that resolves to an EmailProvider implementation. By default, the framework selects the provider based on the EMAIL_PROVIDER secret:
To use a different provider, override the token in your AppModule.
Step 1: Implement the EmailProvider interface
The interface has two methods:
Step 2: Override the token in AppModule
EMAIL_PROVIDER is exported from @tsdevstack/nest-common. Your provider takes precedence over the built-in factory. All NotificationService.sendEmail() calls will use your provider.
You can also use useFactory instead of useClass if you need more control over initialization — for example, to conditionally select between providers based on environment.
Step 3: Add your secrets
Add your provider's API key to .secrets.user.json and assign it to the service that sends emails:
Then regenerate secrets:
For cloud environments, push the secret:
What stays the same
After switching providers, everything else works as before:
NotificationService.sendEmail()API is unchanged- Local development still logs to console (unless you override that too)
- Email rate limiting (
EmailRateLimitGuard) still works - No changes needed in any service code that sends emails
Testing locally
To test your custom provider in local development, set EMAIL_PROVIDER to a value that triggers your factory logic. Or use useFactory to check the environment:
For Resend-specific setup (account creation, domain verification, DNS records), see Resend Integration.