Skip to content

docs: Document the Serverpod Cloud email identity provider default#707

Open
marcelomendoncasoares wants to merge 5 commits into
serverpod:mainfrom
marcelomendoncasoares:docs/cloud-email-idp
Open

docs: Document the Serverpod Cloud email identity provider default#707
marcelomendoncasoares wants to merge 5 commits into
serverpod:mainfrom
marcelomendoncasoares:docs/cloud-email-idp

Conversation

@marcelomendoncasoares

Copy link
Copy Markdown
Collaborator

Summary

Newly generated projects register ServerpodCloudEmailIdpConfig, not the EmailIdpConfig the setup page described. A reader following the page saw a configuration that does not match their server.dart and had nothing explaining where the emails actually come from.

Changes

  • Rewrite "Server-side configuration" around the two delivery options, with the generated default first.
  • Document ServerpodCloudEmailIdpConfig: appDisplayName, codes logged in development and test, and email sent in staging and production.
  • Explain the automatic scloudAuthEmailKey injection on deploy, and the lazy lookup that lets a self-hosted server start without it.
  • Describe the best-effort delivery behavior, where failures are logged, and why registration and password-reset responses do not change when delivery fails.
  • Keep the custom provider path as EmailIdpConfigFromPasswords with the mailer example, and move the pepper into the parameter list where it now comes from.
  • Move the endpoint and migration step into its own subsection. It applies to both configurations, but was previously nested inside the custom provider branch.
  • Add a paragraph to the Cloud passwords page describing scloudAuthEmailKey, linked to the setup page.

Reference

🤖 Generated with Claude Code

Move the endpoint and migration step out of the custom provider branch,
where a reader following the Serverpod Cloud path would never see it, and
fold the parameter list back into the section it documents. Split the
dense Cloud delivery paragraphs and drop the appDisplayName length limit,
which the API already enforces.
The page read as if ServerpodCloudEmailIdpConfig pointed at a transactional
email service that any server could use. It does not: the delivery is part
of the Serverpod Cloud platform, and the key it authenticates with is
injected into the deployed instance and is not obtainable anywhere else.
Say so where a self-hosted reader would otherwise pick the wrong
configuration and find out in production.
Cut the explanation block that had grown at the top of the page and the
one under Server-side configuration. The generated configuration is now
the single path through the page, followed by the endpoint and migration
step, with the Cloud-only scope and the delivery failure behavior as
short hooks where a reader runs into them. Move the custom provider to a
variant section at the end, and leave the Cloud passwords page alone.
@marcelomendoncasoares
marcelomendoncasoares marked this pull request as ready for review July 21, 2026 21:47
@marcelomendoncasoares
marcelomendoncasoares requested a review from a team July 21, 2026 21:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant