Documentation

Configure email providers

Use your own SMTP server or provider account for outbound email on projects and stacks, including BYOS connected-node workloads.

Try StackShiftRead the overview

Projects

Configure email providers

Live

Use your own SMTP server or provider account for outbound email on projects and stacks, including BYOS connected-node workloads.

Goal

Set up outbound email correctly without confusing user-owned provider credentials with StackShift platform email.

Current status

Live

This area is documented as current, user-reliable behavior.

Workflow

  1. 1Open the email-provider panel on the project settings page or stack detail page.
  2. 2Choose SMTP, Resend, Mailgun, Postmark, Amazon SES, or MailerSend.
  3. 3Enter your own provider credentials and sender details.
  4. 4Save the config, then run connection test and test email.
  5. 5Deploy or redeploy the workload so the injected env vars are applied to runtime.

What this feature is and is not

  • This is for the user’s own email provider credentials, not a shared StackShift sending account.
  • It supports outbound email for workloads, not inbound mailbox hosting.
  • It does not switch StackShift platform emails such as auth or notifications onto the user’s provider.

Where it works today

  • Projects, including GitHub-backed, Docker-image, hosted, and connected-node / BYOS project deploys
  • Stacks, including raw Compose stacks and template-backed stacks
  • Hosted and BYOS runtime placement both use the same provider model

Supported providers

  • SMTP
  • Resend
  • Mailgun
  • Postmark
  • Amazon SES
  • MailerSend

How runtime injection behaves

  • StackShift injects provider env vars at deploy time.
  • User-defined env vars still override collisions.
  • Each project or stack currently has one managed provider config at a time.
  • If the app needs a second mail path, add the extra credentials manually as normal env vars.

Good SMTP test choices

  • Use a real provider account such as Resend SMTP, Mailgun SMTP, Postmark SMTP, or Amazon SES SMTP.
  • Avoid assuming Gmail SMTP is the best platform test path because it is often more restrictive and less predictable.

Expected result

The workload can send outbound email through the user’s own provider account on hosted or connected-node infrastructure.

Common failures

  • SMTP host, port, or auth details are incorrect
  • Provider-side sender identity or domain is not verified
  • The workload was not redeployed after config changes
  • The app expects provider-specific env vars but is only coded for SMTP, or vice versa