Use custom smtp relay for email transport

[Calanas]

What does this PR do?

Alternatively, it is now possible to use a custom (SMTP) mail server for email transport. The goal is to connect this application to an already existing infrastructure and to reduce the number of external (meaning outside the company boundaries) dependencies.

Resend will still be the default. But for companies who cannot use online services that easily, the SMTP relay might be a proper alternative.

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox.
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

Prerequisites

Remove / comment the RESEND_API_KEY from your environment since it would be taken as the default otherwise.

Steps to reproduce

Configure a custom SMTP relay with those environment variables (use your own SMTP server):

RELAY_SMTP_HOST="smtp-relay.example.com"
RELAY_SMTP_PORT="587"
RELAY_SMTP_USER="username"
RELAY_SMTP_PASS="password"

Start the application and use the continue with email option:

In the app logs, you will recognize an information text
[next] Using SMTP-Relay as mail service.

as well as the correct mail service provider

[next] [email] send start {
[next]   requestId: '8384622c-7921-4924-9e2a-2cbc5b09d9bd',
[next]   provider: 'relay',
[next]   from: '***',
[next]   to: '***',
[next]   subject: 'Login to Comp AI',
[next]   scheduledAt: undefined,
[next]   flags: { marketing: false, system: false, test: false }
[next] }

And of course, the mail will be delivered.

[vercel]

@Calanas is attempting to deploy a commit to the Comp AI Team on Vercel.

A member of the Team first needs to authorize it.

[cursor]

PR Summary

Medium Risk
Changes the email transport layer and runtime configuration validation; misconfiguration or SMTP differences (e.g., no scheduling support) could break or alter email delivery in production.

Overview
Email sending now supports a custom SMTP relay as an alternative to Resend. A new MailService abstraction selects resend when RESEND_API_KEY is set, otherwise uses a Nodemailer-based relay when all RELAY_SMTP_* vars are provided (and errors if neither is configured).

Email senders in packages/email and apps/api were updated to call getMailService().send() and log the active provider; docs and env validation in apps/app and apps/portal were updated so RESEND_API_KEY is optional but requires a complete relay config when omitted.

^{Written by Cursor Bugbot for commit 99b67c9. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[cursor]

Invalid Zod issue code breaks env validation contract

Medium Severity

The code: 'mail-config' passed to ctx.addIssue() is not a valid ZodIssueCode. Zod's addIssue in superRefine expects one of the predefined issue codes (e.g., 'custom', 'invalid_type'). For custom validation errors, the correct value is z.ZodIssueCode.custom (the string 'custom'). Because these are .mjs files, TypeScript won't catch this, and while current Zod v3 happens to be lenient at runtime, this is incorrect API usage that will likely break on upgrade to Zod 4.

Additional Locations (1)

• apps/portal/src/env.mjs#L69-L74