Ghost v6.63.0 · source audit · 5 Oct 2026
Ghost's native welcome is a conditional route for an existing publication site.
If you already operate Ghost for a publication and members, its one-message welcome may avoid a second list stack. The current welcome help describes editable free and paid welcomes and a test-send control. The v6.63.0 member repository contains member-signup triggers and a welcome-run enqueue path. This audit did not establish safe delivery, exactly-once behavior or a real-send approval.
Four different email jobs
| Job | What the evidence says | Limit |
|---|---|---|
| Confirmation link | Current help describes confirmation before the address appears as a member in the standard flow. Configuration docs put sign-up/login links under transactional mail. | Not the distinct welcome. The exact-tag form and API confirmation paths were not fully traced; do not assume custom paths have the same DOI gate. |
| One free or paid welcome | Current help describes opt-in free and paid messages. The tagged free-member create path and paid transition path trigger welcome handling. Direct-paid and free-to-paid behavior is described in living help. | Tagged send adapter, duplicate lock, suppression timing and provider result were not read. A source-level enqueue is not a receipt. |
| Newsletter | Delivery help describes post, preview, segment and send controls; it is an operator-initiated send, not a new-member event. Self-hosted newsletter docs require Mailgun API for supported bulk sending. | A UI review is not a verified immutable named approval record. Basic SMTP for transactional mail does not establish newsletter transport. |
| Delayed sequence | The 24 June 2026 launch note and current beta help document opt-in free/paid send-and-wait flows. | Beta help says enabling is one-way, live edits affect in-progress members, and Updates & announcements has a separate opt-out. The v6.63.0 beta scheduler, retries, suppression, provider outcomes and restore were not audited. Test separately. |
The January forum statement that only webhooks could handle automation predates the June beta and is stale for the current documented feature. A one-message welcome finding does not clear a timed series.
What was checked at the pinned release
The Ghost v6.63.0 release is dated 8 September 2026; it is the pinned reference, not a claim about the latest release. Its repository licence, root manifest and published core manifest state MIT, and the core manifest names version 6.63.0 and public npm configuration. Those files do not certify the actual deployed image or tarball, every workspace component, dependencies, themes or external provider. Pin and inspect the distribution before deployment.
The tagged member repository branches on an Automations Labs flag and, without that flag, records a welcome automation run with a ready time and attempt field. The free create and qualifying paid transition paths invoke the trigger. An attempt field is not proof of one provider attempt. Exact-tag signup/confirmation controller, welcome send adapter, automation poll, Mailgun adapter and package bytes were not retrieved. They remain source-read and private-test requests, not findings of defects.
The operator still owns the send boundary
Record its installed build and origin of each signup; consent and DOI proof; free/paid and newsletter preference state; approved sender, copy and link; named reviewer; current suppression; one attempt identifier and duplicate/retry hold; provider acceptance, rejection or unknown result; and tested database, content, configuration and secret restore. A download URL is not secure entitlement. If any link is missing, stop before real mail.
Ghost adds site, database, membership, credentials, background work and backup to a one-email task. Use an already-operated sender only if it meets the 4 October decision contract; otherwise privately evaluate its narrower phpList or Keila routes. Listmonk still needs a reviewed external or manual trigger and ledger. None has passed a send/restore test.
Configuration guidance separates production transactional signup/login mail from bulk newsletters; newsletter docs require Mailgun for supported self-hosted bulk sends. This audit could not prove the exact-tag welcome transport in a real deployment. Provider acceptance is not inbox delivery. Hosting guidance assigns maintenance and delivery to the self-hoster. Backup guidance covers backup/export material, not consistent automation-run restore or non-replay.
Evidence needed to change the decision
- Pin the actual artifact.Check package bytes, component notices and the installed setting. Trace exact-tag DOI, welcome transport, duplicate claim, suppression and provider outcome.
- Use a private sink-only fixture.Use fictional members, isolated app/database, no public form, test secrets and sink-only egress. Exercise no confirmation, repeated and concurrent confirmation, free and direct-paid signup, free-to-paid change, opt-out interleaving, rejection, unknown result and restore without replay. None of this ran here.
- Approve a separate beta test if a timed series is needed.Read exact-tag queue, retries and suppression; test delayed steps, opt-out, edits in flight, failure and recovery. Decide deliberately before the one-way Labs setting is enabled.
Source-only findings could change with an installed-build trace and isolated test, or with a genuine publication/membership need and measured total operator cost. Current living help is product documentation, not exact-tag runtime evidence. Browse the dated research library.