Skip to main content
Live. This area is documented as current, user-reliable behavior.

​
Goal

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

​
Prerequisites

  • An existing project or stack
  • A real provider account or SMTP server you control

​
Workflow

1
Open the email-provider panel on the project settings page or stack detail page.
2
Choose SMTP, Resend, Mailgun, Postmark, Amazon SES, or MailerSend.
3
Enter your own provider credentials and sender details.
4
Save the config, then run connection test and test email.
5
Deploy 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

Project environment, domains, and previews

Configure the project surfaces that most often decide whether a deployment works after it builds, including runtime shape, domains, previews, and storage.

Deploy a Docker image

Run a raw container image through the project flow when you already have an image and need runtime configuration, resource sizing, storage, domains, and placement.

Deploy a Compose stack

Bring a Compose-defined workload to StackShift with domains, placement, and persistent volumes.