create-meith 0.18.0 → 0.20.0

package/dist/bin.mjs

@@ -25,7 +25,7 @@ var MATERIALIZED_AT_ROOT = [
 ];
 var VERCEL_BUILD_COMMAND = `community migrate && forum-web build ${AT_ROOT_FLAG}`;
 var TICK_PATH = "/api/system/tick";
-var TICK_SCHEDULE = "* * * * *";
+var TICK_SCHEDULE = "0 3 * * *";
 var MATERIALIZED_PUBLIC = [
   "placeholder-logo.png",
   "placeholder-logo.svg",
@@ -176,25 +176,24 @@ function vercelEnvExample(name) {
 # no other instance can read and that is discarded with the instance \u2014 on Vercel
 # the board refuses it outright rather than losing uploads quietly.
 #
-# CACHE_DRIVER and FILESTORE_DRIVER are asked for at deploy time. The other
-# three derive themselves: a DATABASE_URL means postgres for the data source and
-# the queue, and a RESEND_API_KEY with a MAIL_FROM beside it means mail over the
-# provider's HTTPS API. Setting one here overrides the derivation, which is what
-# this file is for when you copy it to .env.local.
+# The deploy form asks for none of them. On Vercel the board works each one out
+# from what the linked stores publish: a DATABASE_URL means postgres for the
+# data source and the queue, a Redis connection string means CACHE_DRIVER=redis,
+# a Blob store's read-write token means FILESTORE_DRIVER=blob, and a
+# RESEND_API_KEY with a MAIL_FROM beside it means mail over the provider's HTTPS
+# API. Setting one here overrides the derivation, which is what this file is for
+# when you copy it to .env.local.
 #
-# The two that stay explicit stay that way on purpose: each turns on an external
-# service the board then depends on for every request, and neither is switched on
-# by a variable that merely happens to be present. The board caches in Redis and
-# puts uploads in an object store because you said so.
+# Every one of those derivations is scoped to Vercel, and each fires only from a
+# value that is unambiguously the thing itself \u2014 a redis:// or rediss:// URL, a
+# read-write token. A board you run anywhere else is untouched by all of it and
+# still takes these values from this file, exactly as it did before.
 #
-# What happens if you leave one blank differs, and the difference is the reason
-# the form asks for both. Leave FILESTORE_DRIVER blank and the board refuses to
-# boot at all: the default is local, and local on this platform means uploads
-# written to a disk that is about to disappear. Leave CACHE_DRIVER blank and
-# nothing complains \u2014 the board falls back to caching inside each instance and
-# serves whatever that instance last saw, for up to a minute, however many
-# instances there are. That one degrades quietly, which is exactly why it is
-# worth typing rather than leaving to a default.
+# A derivation that cannot resolve is a configuration error, not an invitation
+# to pick something safe-looking. On Vercel, with the cache or the object store
+# missing, the board refuses to boot and names every variable it looked at. It
+# will not quietly cache inside the instance, and it will not quietly write
+# uploads to a disk that is about to disappear.
 DATA_SOURCE=postgres
 QUEUE_DRIVER=postgres
 CACHE_DRIVER=redis
@@ -208,16 +207,20 @@ DATABASE_URL=
 
 ${ENV_DIRECT_DATABASE_URL_PROSE}
 #
-# On Vercel this is not optional. DATABASE_URL here is the pooler string, the
-# build runs \`community migrate\` against it, and /install takes the second of
-# those two session locks on first run. Neon publishes the direct string as
-# DATABASE_URL_UNPOOLED; copy that value into this variable.
+# On Vercel this is not optional, and it is no longer yours to copy. DATABASE_URL
+# here is the pooler string, the build runs \`community migrate\` against it, and
+# /install takes the second of those two session locks on first run. Left blank,
+# the board reads Neon's own direct string \u2014 \`DATABASE_URL_UNPOOLED\` first, then
+# \`POSTGRES_URL_NON_POOLING\` \u2014 and refuses to boot if neither is there, naming
+# both. Never \`POSTGRES_URL\`: that one is pooled.
 DIRECT_DATABASE_URL=
 
 # The shared cache \u2014 a Redis or Valkey endpoint, \`rediss://\` for TLS. Redis
 # holds cache entries and nothing else: losing it costs the board a warm cache,
-# not data, and signs nobody out. A store provisioned with the board publishes
-# its own connection variable; copy that value into this one.
+# not data, and signs nobody out. Left blank on Vercel, the board reads the
+# Upstash store's own \`KV_URL\`, which is the one variable it publishes that
+# speaks the Redis protocol \u2014 \`KV_REST_API_URL\` is an HTTPS endpoint and is
+# never used for this. A name we do not know goes here by hand.
 REDIS_URL=
 
 ${ENV_AUTH_SECRET_PROSE}
@@ -233,15 +236,26 @@ ${ENV_TICK_SECRET_PROSE}
 CRON_SECRET=
 # TICK_SECRET=
 
-# Uploads, in the Vercel Blob store the Deploy Button provisions. The store
-# publishes this variable into the project by itself, so there is nothing to
-# type and nothing to mistype \u2014 but the board still needs FILESTORE_DRIVER=blob
-# above before it will use it. Every object is written with private access: an
-# object URL is not a public link, and member content is served by the board,
-# which is where permissions are checked.
+# Uploads, in the Vercel Blob store the Deploy Button provisions. A store
+# attached to the project publishes BLOB_STORE_ID and nothing else \u2014 no token \u2014
+# because the SDK authenticates with the deployment's own OIDC identity: the
+# board hands it the store id and lets it fetch the credential. There is nothing
+# to type and nothing to mistype, and FILESTORE_DRIVER=blob derives from this
+# variable being present.
 #
-# An upload is held whole in the instance's memory on the way in and on the way
-# out, so the function's memory limit, not the store, is what caps a file.
+# BLOB_READ_WRITE_TOKEN is the other way in, and you make it yourself on the
+# store. Set it when something has to reach the store from OUTSIDE a Vercel
+# deployment \u2014 \`community backup\` run on your own machine is the case that
+# matters \u2014 because there is no OIDC identity there to borrow. Set both and the
+# board prefers the store id, unless the token names a different store, in which
+# case the token wins: naming another store is a deliberate act.
+#
+# Every object is written with private access: an object URL is not a public
+# link, and member content is served by the board, which is where permissions
+# are checked. An upload is held whole in the instance's memory on the way in
+# and on the way out, so the function's memory limit, not the store, is what
+# caps a file.
+BLOB_STORE_ID=
 BLOB_READ_WRITE_TOKEN=
 
 # Uploads in an S3-compatible bucket instead \u2014 AWS, R2, MinIO, Spaces. This is
@@ -264,10 +278,10 @@ BLOB_READ_WRITE_TOKEN=
 # board refuses it on Vercel; 587 with STARTTLS may work, but an API does not
 # depend on the platform's egress rules staying as they are.
 #
-# MAIL_FROM is yours to decide and the one mail value the button asks for: it
-# must be an address at a domain the provider has verified for you, and no
-# default is right. Send from an unverified sender and the provider rejects
-# every message.
+# MAIL_FROM is yours to decide, and it belongs to the step that adds Resend
+# rather than to the deploy: it must be an address at a domain the provider has
+# verified for you, no default is right, and until a provider is added the board
+# cannot send from any address at all. Set it alongside the integration.
 MAIL_FROM=
 
 # Add the Resend integration to the project from Vercel's marketplace and it
@@ -308,22 +322,15 @@ var SELF_HOST_DEPLOY_KIT = [
   "docker-entrypoint.sh",
   "docker-healthcheck.sh"
 ];
-var VERCEL_TYPED_DRIVERS = ["CACHE_DRIVER=redis", "FILESTORE_DRIVER=blob"];
 var VERCEL_DERIVED_DRIVERS = [
   "DATA_SOURCE=postgres",
   "QUEUE_DRIVER=postgres",
+  "CACHE_DRIVER=redis",
+  "FILESTORE_DRIVER=blob",
   "MAIL_DRIVER=http"
 ];
-var VERCEL_PROMPTED_ENV = [
-  "CACHE_DRIVER",
-  "FILESTORE_DRIVER",
-  "DIRECT_DATABASE_URL",
-  "REDIS_URL",
-  "AUTH_SECRET",
-  "CRON_SECRET",
-  "MAIL_FROM"
-];
-var VERCEL_MARKETPLACE_STORES = [
+var VERCEL_PROMPTED_ENV = ["AUTH_SECRET", "CRON_SECRET"];
+var VERCEL_MARKETPLACE_PRODUCTS = [
   { type: "integration", integrationSlug: "neon", productSlug: "neon", protocol: "storage" },
   {
     type: "integration",
@@ -331,7 +338,13 @@ var VERCEL_MARKETPLACE_STORES = [
     productSlug: "upstash-kv",
     protocol: "storage"
   },
-  { type: "blob" }
+  { type: "blob" },
+  {
+    type: "integration",
+    integrationSlug: "resend",
+    productSlug: "resend-email",
+    protocol: "messaging"
+  }
 ];
 function deployButtonUrl(templateRepositoryUrl) {
   const params = new URLSearchParams([
@@ -341,10 +354,10 @@ function deployButtonUrl(templateRepositoryUrl) {
     ["env", VERCEL_PROMPTED_ENV.join(",")],
     [
       "envDescription",
-      "Two driver values, two secrets to generate, the direct database URL, the cache URL, and the verified address the board sends from."
+      "Two secrets, generated rather than chosen \u2014 32 characters or more each. Everything else the board reads from the database, cache, blob store and mail provider this form links."
     ],
     ["envLink", `${templateRepositoryUrl}/blob/main/.env.example`],
-    ["stores", JSON.stringify(VERCEL_MARKETPLACE_STORES)],
+    ["products", JSON.stringify(VERCEL_MARKETPLACE_PRODUCTS)],
     ["skippable-integrations", "1"]
   ]);
   return `https://vercel.com/new/clone?${params.toString()}`;
@@ -992,20 +1005,27 @@ A forum, built on [Meith](${repositoryUrl}), running as Vercel functions.
 - **A Neon Postgres database**, attached to the project. Neon publishes the
   pooled connection string as \`DATABASE_URL\` and the direct one as
   \`DATABASE_URL_UNPOOLED\`.
-- **An Upstash Redis store**, attached the same way, for the shared cache.
-  It publishes its own connection variable.
-- **A Vercel Blob store** for uploads, which publishes \`BLOB_READ_WRITE_TOKEN\`
-  into the project by itself. This is the one value that used to be four hand-
-  typed \`S3_*\` secrets.
+- **An Upstash Redis store**, attached the same way, for the shared cache. It
+  publishes \`KV_URL\`, which the board reads as \`REDIS_URL\` \u2014 \`KV_REST_API_URL\`
+  beside it is an HTTPS endpoint and is not used for this.
+- **A Vercel Blob store** for uploads, which publishes \`BLOB_STORE_ID\` into the
+  project by itself. That is the whole credential: the board hands the id to
+  Vercel's SDK, which authenticates with the deployment's own OIDC identity, so
+  there is no token to copy. This is what used to be four hand-typed \`S3_*\`
+  secrets.
+- **A Resend mail account**, attached the same way, which publishes
+  \`RESEND_API_KEY\`. The board reads that name directly: its mail driver already
+  speaks Resend's request shape, so there is nothing to adapt.
 - **A Vercel project** carrying \`vercel.json\` \u2014 the build command
   \`${VERCEL_BUILD_COMMAND}\`,
   which applies the schema before it builds, materializes the board's app at
   the project root so the artefact lands where Vercel reads it, and the cron
   entry that drives the tick.
 
-**Mail is the one thing the button does not set up**, and it takes one click
-after the deploy \u2014 see *Mail, in one click* below. The board boots and runs
-without it, and delivers nothing, silently, until it is done.
+**Mail needs one thing after the deploy**: the address the board sends from.
+It has to be at a domain Resend has verified, and no form can ask for that
+before the account exists \u2014 see *Mail, after the deploy* below. The board boots
+and runs without it, and delivers nothing, silently, until it is done.
 
 ## What to type into the deploy form
 
@@ -1018,71 +1038,60 @@ openssl rand -hex 32   # CRON_SECRET
 \`\`\`
 
 \`CRON_SECRET\` is the name Vercel Cron sends, as \`Authorization: Bearer\`, and it
-cannot be told to send another. Note that this floor is stricter than the 16
+cannot be told to send another \u2014 the caller is the platform, so this one has to
+be an environment variable both ends can read, and cannot be something the
+board makes up for itself. Note that this floor is stricter than the 16
 characters Vercel's own cron documentation suggests \u2014 a value generated by
 following those instructions is refused here, and the fix is a longer secret.
 
-**Two driver values**, and they are the two that turn on an external service
-the board then needs for every request:
-
-\`\`\`ini
-${VERCEL_TYPED_DRIVERS.join("\n")}
-\`\`\`
-
-Neither is inferred, deliberately: the board caches in Redis and puts uploads
-in an object store because you said so, never because a connection string or a
-token happened to be present.
+\`AUTH_SECRET\` seals members' two-factor secrets and signs the unsubscribe links
+in outgoing mail. It stays in the environment deliberately: a copy of the
+database is then not enough to forge either.
 
-Leaving them blank fails differently, which is why the form asks for both.
-Blank \`FILESTORE_DRIVER\` means \`local\`, and the board **refuses to boot** on
-this platform rather than write uploads to a disk that is about to disappear.
-Blank \`CACHE_DRIVER\` complains about nothing: the board falls back to caching
-inside each instance, and every instance then serves whatever it last saw for
-up to a minute. That one degrades quietly, so type it.
-
-The remaining three drivers do derive themselves, and the form does not ask:
-a \`DATABASE_URL\` means \`DATA_SOURCE=postgres\` and \`QUEUE_DRIVER=postgres\`, and
-a \`RESEND_API_KEY\` with a \`MAIL_FROM\` beside it means \`MAIL_DRIVER=http\`:
+**That is the whole form.** Everything else the board works out from the stores
+this button just linked to the project:
 
 \`\`\`ini
 ${VERCEL_DERIVED_DRIVERS.join("\n")}
 \`\`\`
 
-**Two connection strings copied from the stores the button just created.**
-\`DIRECT_DATABASE_URL\` takes Neon's \`DATABASE_URL_UNPOOLED\` \u2014 migrations and the
-first-run installer each hold a session-level advisory lock, which a
-transaction-mode pooler cannot hold. \`REDIS_URL\` takes whatever variable the
-Upstash store published.
-
-**The address the board sends from**: \`MAIL_FROM\`. This is the only mail value
-you ever type. It has to be an address at a domain your mail provider has
-verified for you, so no default is right and the board cannot guess it \u2014 see
-*Mail, in one click* below. If you do not have one yet, put in the address you
-intend to use and finish verifying it afterwards; nothing else waits on it.
-
-That is seven fields. If you would rather keep uploads somewhere you hold
-yourself \u2014 see *Leaving Vercel* below for why that matters \u2014 set
-\`FILESTORE_DRIVER=s3\` instead and add \`S3_BUCKET\`, \`S3_REGION\`,
-\`S3_ACCESS_KEY_ID\` and \`S3_SECRET_ACCESS_KEY\` in the project's environment
-settings, with \`S3_ENDPOINT\` for a bucket that is not AWS (\`S3_REGION=auto\` for
-R2). The same board runs either way.
-
-## Mail, in one click
+\`DIRECT_DATABASE_URL\` comes from Neon's own \`DATABASE_URL_UNPOOLED\`, or
+\`POSTGRES_URL_NON_POOLING\` if that one is absent \u2014 migrations and the first-run
+installer each hold a session-level advisory lock, which the pooled
+\`DATABASE_URL\` cannot hold. \`REDIS_URL\` comes from Upstash's \`KV_URL\`, the one
+variable it publishes that speaks the Redis protocol.
+
+Every one of those derivations is scoped to this platform, fires only where you
+have not set the variable yourself, and **refuses to boot rather than guess**.
+If a store is missing, or publishes a name this board does not know, the deploy
+stops with a message naming every variable it looked at \u2014 it will not fall back
+to caching inside each instance, or to uploads on a disk that is discarded with
+the instance. When the name is one we do not know, set \`REDIS_URL\` or
+\`DIRECT_DATABASE_URL\` in the project's environment settings and the derivation
+stands aside.
+
+If you would rather keep uploads somewhere you hold yourself \u2014 see *Leaving
+Vercel* below for why that matters \u2014 set \`FILESTORE_DRIVER=s3\` and add
+\`S3_BUCKET\`, \`S3_REGION\`, \`S3_ACCESS_KEY_ID\` and \`S3_SECRET_ACCESS_KEY\` in the
+project's environment settings, with \`S3_ENDPOINT\` for a bucket that is not AWS
+(\`S3_REGION=auto\` for R2). The same board runs either way.
+
+## Mail, after the deploy
 
 A board that cannot send mail cannot reset a password, so do this before you
-invite anybody.
+invite anybody. The deploy form already added Resend and published its key; two
+steps remain, and neither could have been answered on the form.
 
-1. Open your project on Vercel, go to **Storage \u2192 Marketplace** (or
-   **Integrations**), and add **Resend**. It creates a Resend account linked to
-   the project and connects your sending domain.
-2. Verify that domain in the Resend dashboard if you have not already. Resend
-   refuses to send from an address at a domain it has not verified.
+1. Verify your sending domain in the Resend dashboard if you have not already.
+   Resend refuses to send from an address at a domain it has not verified.
+2. Add \`MAIL_FROM\` to the project's environment settings \u2014 an address at that
+   verified domain, and the only mail value you ever type.
 3. Redeploy, or let the next push redeploy.
 
-That is all. The integration publishes its key into the project as
-\`RESEND_API_KEY\`, and the board reads that name: with it set, and \`MAIL_FROM\`
-already in place, mail sends over Resend's HTTPS API with nothing further to
-configure.
+That is all. The integration published its key into the project as
+\`RESEND_API_KEY\` when you deployed, and the board reads that name: with it set,
+and \`MAIL_FROM\` beside it, mail sends over Resend's HTTPS API with nothing
+further to configure.
 
 The board is not tied to Resend. Its mail driver is a plain JSON-over-HTTPS
 sender that posts \`{from, to, subject, text, html, reply_to}\` with a bearer
@@ -1116,15 +1125,23 @@ drains; nothing here runs it on its own, because there is no worker process on
 a function platform. Two things about it are worth knowing **before** you
 deploy rather than after:
 
-- **A per-minute schedule needs a paid plan.** Hobby allows a couple of cron
-  jobs and runs each of them roughly once a day, at an hour Vercel chooses;
-  only paid plans accept an arbitrary cron expression. A board ticking daily
-  still loses nothing \u2014 tasks are written so a missed run delays work rather
-  than dropping it \u2014 but "as it happens" notifications become a daily digest in
-  all but name. To keep a minute-by-minute tick on Hobby, drive
-  \`${TICK_PATH}\` from something else that can call a URL on a schedule \u2014 a
-  GitHub Actions workflow, a systemd timer, an uptime pinger \u2014 presenting
-  \`TICK_SECRET\` instead.
+- **This ships a daily schedule, because Hobby refuses anything faster.** A
+  Hobby plan rejects a cron expression that would run more than once a day \u2014
+  the deployment fails outright rather than being slowed down \u2014 so
+  \`vercel.json\` carries \`${TICK_SCHEDULE}\` and deploys anywhere. On a
+  paid plan, edit it to \`* * * * *\` and the board ticks every minute.
+
+  A daily tick loses nothing permanently: tasks are written so a missed run
+  delays work rather than dropping it, and a password reset is sent as the
+  request is handled rather than waiting for a tick. What it does delay is
+  everything the tick drives \u2014 a new post is not findable in search, and a
+  notification is not sent, until the next run.
+
+  **To keep a fast tick without paying**, drive \`${TICK_PATH}\` from anything
+  that can call a URL on a schedule \u2014 a GitHub Actions workflow, a systemd
+  timer, an uptime pinger \u2014 presenting \`TICK_SECRET\` instead of
+  \`CRON_SECRET\`. The endpoint accepts either, so the Vercel cron and an
+  outside scheduler can both drive it.
 - **\`maxDuration = 300\` is validated when the project builds, not when the
   function runs.** A plan that does not allow 300 seconds therefore **fails the
   deployment** rather than clamping the request. With Fluid Compute \u2014 the
@@ -1178,13 +1195,19 @@ a Blob store does not:
 DATABASE_URL=\u2026            # Neon's pooled string
 DIRECT_DATABASE_URL=\u2026     # Neon's DATABASE_URL_UNPOOLED
 FILESTORE_DRIVER=blob
-BLOB_READ_WRITE_TOKEN=\u2026   # copy it out of the project's environment settings
+BLOB_READ_WRITE_TOKEN=\u2026   # create one on the store; see below
 npm run community -- backup
 \`\`\`
 
 Run that from a checkout of this repository, with those four values in the
 environment \u2014 the CLI talks to Neon and to the Blob store over the network, so
-it does not have to run on Vercel. The bundle it writes holds the dump *and*
+it does not have to run on Vercel.
+
+That last one is the one value this route asks you to make by hand, and only
+here. On the deployment the board reaches the store with \`BLOB_STORE_ID\` and
+the deployment's OIDC identity, which a command on your own machine does not
+have. Open the store under **Storage**, create a read-write token, and use it
+for the backup; the board itself never needs it. The bundle it writes holds the dump *and*
 every object. Check the last line it prints: if it says *no uploads*, the
 uploads are not in the bundle and restoring it gives a board whose posts have
 broken images.
@@ -1317,7 +1340,7 @@ async function run(argv, version) {
 }
 
 // src/bin.ts
-var result = await run(process.argv.slice(2), "0.18.0");
+var result = await run(process.argv.slice(2), "0.20.0");
 for (const line of result.lines) {
   if (result.code === 0) console.log(line);
   else console.error(line);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-meith",
-  "version": "0.18.0",
+  "version": "0.20.0",
   "description": "Scaffold a Meith board — npx create-meith <name> writes a workspace that depends on @meith/web and @meith/cli.",
   "license": "MIT",
   "repository": {

package/src/bin.ts

@@ -1,7 +1,7 @@
 #!/usr/bin/env node
 import { run } from './cli'
 
-const result = await run(process.argv.slice(2), '0.18.0')
+const result = await run(process.argv.slice(2), '0.20.0')
 for (const line of result.lines) {
   if (result.code === 0) console.log(line)
   else console.error(line)

package/src/index.ts

@@ -10,7 +10,7 @@ export {
   TICK_PATH,
   TICK_SCHEDULE,
   VERCEL_BUILD_COMMAND,
-  VERCEL_MARKETPLACE_STORES,
+  VERCEL_MARKETPLACE_PRODUCTS,
   VERCEL_PROMPTED_ENV,
   validateName,
 } from './scaffold'

package/src/scaffold.ts

@@ -33,7 +33,7 @@ export const VERCEL_BUILD_COMMAND = `community migrate && forum-web build ${AT_R
 
 export const TICK_PATH = '/api/system/tick'
 
-export const TICK_SCHEDULE = '* * * * *'
+export const TICK_SCHEDULE = '0 3 * * *'
 
 export const MATERIALIZED_PUBLIC = [
   'placeholder-logo.png',
@@ -200,25 +200,24 @@ function vercelEnvExample(name: string): string {
 # no other instance can read and that is discarded with the instance — on Vercel
 # the board refuses it outright rather than losing uploads quietly.
 #
-# CACHE_DRIVER and FILESTORE_DRIVER are asked for at deploy time. The other
-# three derive themselves: a DATABASE_URL means postgres for the data source and
-# the queue, and a RESEND_API_KEY with a MAIL_FROM beside it means mail over the
-# provider's HTTPS API. Setting one here overrides the derivation, which is what
-# this file is for when you copy it to .env.local.
+# The deploy form asks for none of them. On Vercel the board works each one out
+# from what the linked stores publish: a DATABASE_URL means postgres for the
+# data source and the queue, a Redis connection string means CACHE_DRIVER=redis,
+# a Blob store's read-write token means FILESTORE_DRIVER=blob, and a
+# RESEND_API_KEY with a MAIL_FROM beside it means mail over the provider's HTTPS
+# API. Setting one here overrides the derivation, which is what this file is for
+# when you copy it to .env.local.
 #
-# The two that stay explicit stay that way on purpose: each turns on an external
-# service the board then depends on for every request, and neither is switched on
-# by a variable that merely happens to be present. The board caches in Redis and
-# puts uploads in an object store because you said so.
+# Every one of those derivations is scoped to Vercel, and each fires only from a
+# value that is unambiguously the thing itself — a redis:// or rediss:// URL, a
+# read-write token. A board you run anywhere else is untouched by all of it and
+# still takes these values from this file, exactly as it did before.
 #
-# What happens if you leave one blank differs, and the difference is the reason
-# the form asks for both. Leave FILESTORE_DRIVER blank and the board refuses to
-# boot at all: the default is local, and local on this platform means uploads
-# written to a disk that is about to disappear. Leave CACHE_DRIVER blank and
-# nothing complains — the board falls back to caching inside each instance and
-# serves whatever that instance last saw, for up to a minute, however many
-# instances there are. That one degrades quietly, which is exactly why it is
-# worth typing rather than leaving to a default.
+# A derivation that cannot resolve is a configuration error, not an invitation
+# to pick something safe-looking. On Vercel, with the cache or the object store
+# missing, the board refuses to boot and names every variable it looked at. It
+# will not quietly cache inside the instance, and it will not quietly write
+# uploads to a disk that is about to disappear.
 DATA_SOURCE=postgres
 QUEUE_DRIVER=postgres
 CACHE_DRIVER=redis
@@ -232,16 +231,20 @@ DATABASE_URL=
 
 ${ENV_DIRECT_DATABASE_URL_PROSE}
 #
-# On Vercel this is not optional. DATABASE_URL here is the pooler string, the
-# build runs \`community migrate\` against it, and /install takes the second of
-# those two session locks on first run. Neon publishes the direct string as
-# DATABASE_URL_UNPOOLED; copy that value into this variable.
+# On Vercel this is not optional, and it is no longer yours to copy. DATABASE_URL
+# here is the pooler string, the build runs \`community migrate\` against it, and
+# /install takes the second of those two session locks on first run. Left blank,
+# the board reads Neon's own direct string — \`DATABASE_URL_UNPOOLED\` first, then
+# \`POSTGRES_URL_NON_POOLING\` — and refuses to boot if neither is there, naming
+# both. Never \`POSTGRES_URL\`: that one is pooled.
 DIRECT_DATABASE_URL=
 
 # The shared cache — a Redis or Valkey endpoint, \`rediss://\` for TLS. Redis
 # holds cache entries and nothing else: losing it costs the board a warm cache,
-# not data, and signs nobody out. A store provisioned with the board publishes
-# its own connection variable; copy that value into this one.
+# not data, and signs nobody out. Left blank on Vercel, the board reads the
+# Upstash store's own \`KV_URL\`, which is the one variable it publishes that
+# speaks the Redis protocol — \`KV_REST_API_URL\` is an HTTPS endpoint and is
+# never used for this. A name we do not know goes here by hand.
 REDIS_URL=
 
 ${ENV_AUTH_SECRET_PROSE}
@@ -257,15 +260,26 @@ ${ENV_TICK_SECRET_PROSE}
 CRON_SECRET=
 # TICK_SECRET=
 
-# Uploads, in the Vercel Blob store the Deploy Button provisions. The store
-# publishes this variable into the project by itself, so there is nothing to
-# type and nothing to mistype — but the board still needs FILESTORE_DRIVER=blob
-# above before it will use it. Every object is written with private access: an
-# object URL is not a public link, and member content is served by the board,
-# which is where permissions are checked.
+# Uploads, in the Vercel Blob store the Deploy Button provisions. A store
+# attached to the project publishes BLOB_STORE_ID and nothing else — no token —
+# because the SDK authenticates with the deployment's own OIDC identity: the
+# board hands it the store id and lets it fetch the credential. There is nothing
+# to type and nothing to mistype, and FILESTORE_DRIVER=blob derives from this
+# variable being present.
 #
-# An upload is held whole in the instance's memory on the way in and on the way
-# out, so the function's memory limit, not the store, is what caps a file.
+# BLOB_READ_WRITE_TOKEN is the other way in, and you make it yourself on the
+# store. Set it when something has to reach the store from OUTSIDE a Vercel
+# deployment — \`community backup\` run on your own machine is the case that
+# matters — because there is no OIDC identity there to borrow. Set both and the
+# board prefers the store id, unless the token names a different store, in which
+# case the token wins: naming another store is a deliberate act.
+#
+# Every object is written with private access: an object URL is not a public
+# link, and member content is served by the board, which is where permissions
+# are checked. An upload is held whole in the instance's memory on the way in
+# and on the way out, so the function's memory limit, not the store, is what
+# caps a file.
+BLOB_STORE_ID=
 BLOB_READ_WRITE_TOKEN=
 
 # Uploads in an S3-compatible bucket instead — AWS, R2, MinIO, Spaces. This is
@@ -288,10 +302,10 @@ BLOB_READ_WRITE_TOKEN=
 # board refuses it on Vercel; 587 with STARTTLS may work, but an API does not
 # depend on the platform's egress rules staying as they are.
 #
-# MAIL_FROM is yours to decide and the one mail value the button asks for: it
-# must be an address at a domain the provider has verified for you, and no
-# default is right. Send from an unverified sender and the provider rejects
-# every message.
+# MAIL_FROM is yours to decide, and it belongs to the step that adds Resend
+# rather than to the deploy: it must be an address at a domain the provider has
+# verified for you, no default is right, and until a provider is added the board
+# cannot send from any address at all. Set it alongside the integration.
 MAIL_FROM=
 
 # Add the Resend integration to the project from Vercel's marketplace and it
@@ -335,25 +349,17 @@ const SELF_HOST_DEPLOY_KIT = [
   'docker-healthcheck.sh',
 ] as const
 
-const VERCEL_TYPED_DRIVERS = ['CACHE_DRIVER=redis', 'FILESTORE_DRIVER=blob'] as const
-
 const VERCEL_DERIVED_DRIVERS = [
   'DATA_SOURCE=postgres',
   'QUEUE_DRIVER=postgres',
+  'CACHE_DRIVER=redis',
+  'FILESTORE_DRIVER=blob',
   'MAIL_DRIVER=http',
 ] as const
 
-export const VERCEL_PROMPTED_ENV = [
-  'CACHE_DRIVER',
-  'FILESTORE_DRIVER',
-  'DIRECT_DATABASE_URL',
-  'REDIS_URL',
-  'AUTH_SECRET',
-  'CRON_SECRET',
-  'MAIL_FROM',
-] as const
+export const VERCEL_PROMPTED_ENV = ['AUTH_SECRET', 'CRON_SECRET'] as const
 
-export const VERCEL_MARKETPLACE_STORES = [
+export const VERCEL_MARKETPLACE_PRODUCTS = [
   { type: 'integration', integrationSlug: 'neon', productSlug: 'neon', protocol: 'storage' },
   {
     type: 'integration',
@@ -362,6 +368,12 @@ export const VERCEL_MARKETPLACE_STORES = [
     protocol: 'storage',
   },
   { type: 'blob' },
+  {
+    type: 'integration',
+    integrationSlug: 'resend',
+    productSlug: 'resend-email',
+    protocol: 'messaging',
+  },
 ] as const
 
 export function deployButtonUrl(templateRepositoryUrl: string): string {
@@ -372,10 +384,10 @@ export function deployButtonUrl(templateRepositoryUrl: string): string {
     ['env', VERCEL_PROMPTED_ENV.join(',')],
     [
       'envDescription',
-      'Two driver values, two secrets to generate, the direct database URL, the cache URL, and the verified address the board sends from.',
+      'Two secrets, generated rather than chosen — 32 characters or more each. Everything else the board reads from the database, cache, blob store and mail provider this form links.',
     ],
     ['envLink', `${templateRepositoryUrl}/blob/main/.env.example`],
-    ['stores', JSON.stringify(VERCEL_MARKETPLACE_STORES)],
+    ['products', JSON.stringify(VERCEL_MARKETPLACE_PRODUCTS)],
     ['skippable-integrations', '1'],
   ])
 
@@ -1054,20 +1066,27 @@ A forum, built on [Meith](${repositoryUrl}), running as Vercel functions.
 - **A Neon Postgres database**, attached to the project. Neon publishes the
   pooled connection string as \`DATABASE_URL\` and the direct one as
   \`DATABASE_URL_UNPOOLED\`.
-- **An Upstash Redis store**, attached the same way, for the shared cache.
-  It publishes its own connection variable.
-- **A Vercel Blob store** for uploads, which publishes \`BLOB_READ_WRITE_TOKEN\`
-  into the project by itself. This is the one value that used to be four hand-
-  typed \`S3_*\` secrets.
+- **An Upstash Redis store**, attached the same way, for the shared cache. It
+  publishes \`KV_URL\`, which the board reads as \`REDIS_URL\` — \`KV_REST_API_URL\`
+  beside it is an HTTPS endpoint and is not used for this.
+- **A Vercel Blob store** for uploads, which publishes \`BLOB_STORE_ID\` into the
+  project by itself. That is the whole credential: the board hands the id to
+  Vercel's SDK, which authenticates with the deployment's own OIDC identity, so
+  there is no token to copy. This is what used to be four hand-typed \`S3_*\`
+  secrets.
+- **A Resend mail account**, attached the same way, which publishes
+  \`RESEND_API_KEY\`. The board reads that name directly: its mail driver already
+  speaks Resend's request shape, so there is nothing to adapt.
 - **A Vercel project** carrying \`vercel.json\` — the build command
   \`${VERCEL_BUILD_COMMAND}\`,
   which applies the schema before it builds, materializes the board's app at
   the project root so the artefact lands where Vercel reads it, and the cron
   entry that drives the tick.
 
-**Mail is the one thing the button does not set up**, and it takes one click
-after the deploy — see *Mail, in one click* below. The board boots and runs
-without it, and delivers nothing, silently, until it is done.
+**Mail needs one thing after the deploy**: the address the board sends from.
+It has to be at a domain Resend has verified, and no form can ask for that
+before the account exists — see *Mail, after the deploy* below. The board boots
+and runs without it, and delivers nothing, silently, until it is done.
 
 ## What to type into the deploy form
 
@@ -1080,71 +1099,60 @@ openssl rand -hex 32   # CRON_SECRET
 \`\`\`
 
 \`CRON_SECRET\` is the name Vercel Cron sends, as \`Authorization: Bearer\`, and it
-cannot be told to send another. Note that this floor is stricter than the 16
+cannot be told to send another — the caller is the platform, so this one has to
+be an environment variable both ends can read, and cannot be something the
+board makes up for itself. Note that this floor is stricter than the 16
 characters Vercel's own cron documentation suggests — a value generated by
 following those instructions is refused here, and the fix is a longer secret.
 
-**Two driver values**, and they are the two that turn on an external service
-the board then needs for every request:
+\`AUTH_SECRET\` seals members' two-factor secrets and signs the unsubscribe links
+in outgoing mail. It stays in the environment deliberately: a copy of the
+database is then not enough to forge either.
 
-\`\`\`ini
-${VERCEL_TYPED_DRIVERS.join('\n')}
-\`\`\`
-
-Neither is inferred, deliberately: the board caches in Redis and puts uploads
-in an object store because you said so, never because a connection string or a
-token happened to be present.
-
-Leaving them blank fails differently, which is why the form asks for both.
-Blank \`FILESTORE_DRIVER\` means \`local\`, and the board **refuses to boot** on
-this platform rather than write uploads to a disk that is about to disappear.
-Blank \`CACHE_DRIVER\` complains about nothing: the board falls back to caching
-inside each instance, and every instance then serves whatever it last saw for
-up to a minute. That one degrades quietly, so type it.
-
-The remaining three drivers do derive themselves, and the form does not ask:
-a \`DATABASE_URL\` means \`DATA_SOURCE=postgres\` and \`QUEUE_DRIVER=postgres\`, and
-a \`RESEND_API_KEY\` with a \`MAIL_FROM\` beside it means \`MAIL_DRIVER=http\`:
+**That is the whole form.** Everything else the board works out from the stores
+this button just linked to the project:
 
 \`\`\`ini
 ${VERCEL_DERIVED_DRIVERS.join('\n')}
 \`\`\`
 
-**Two connection strings copied from the stores the button just created.**
-\`DIRECT_DATABASE_URL\` takes Neon's \`DATABASE_URL_UNPOOLED\` — migrations and the
-first-run installer each hold a session-level advisory lock, which a
-transaction-mode pooler cannot hold. \`REDIS_URL\` takes whatever variable the
-Upstash store published.
-
-**The address the board sends from**: \`MAIL_FROM\`. This is the only mail value
-you ever type. It has to be an address at a domain your mail provider has
-verified for you, so no default is right and the board cannot guess it — see
-*Mail, in one click* below. If you do not have one yet, put in the address you
-intend to use and finish verifying it afterwards; nothing else waits on it.
-
-That is seven fields. If you would rather keep uploads somewhere you hold
-yourself — see *Leaving Vercel* below for why that matters — set
-\`FILESTORE_DRIVER=s3\` instead and add \`S3_BUCKET\`, \`S3_REGION\`,
-\`S3_ACCESS_KEY_ID\` and \`S3_SECRET_ACCESS_KEY\` in the project's environment
-settings, with \`S3_ENDPOINT\` for a bucket that is not AWS (\`S3_REGION=auto\` for
-R2). The same board runs either way.
-
-## Mail, in one click
+\`DIRECT_DATABASE_URL\` comes from Neon's own \`DATABASE_URL_UNPOOLED\`, or
+\`POSTGRES_URL_NON_POOLING\` if that one is absent — migrations and the first-run
+installer each hold a session-level advisory lock, which the pooled
+\`DATABASE_URL\` cannot hold. \`REDIS_URL\` comes from Upstash's \`KV_URL\`, the one
+variable it publishes that speaks the Redis protocol.
+
+Every one of those derivations is scoped to this platform, fires only where you
+have not set the variable yourself, and **refuses to boot rather than guess**.
+If a store is missing, or publishes a name this board does not know, the deploy
+stops with a message naming every variable it looked at — it will not fall back
+to caching inside each instance, or to uploads on a disk that is discarded with
+the instance. When the name is one we do not know, set \`REDIS_URL\` or
+\`DIRECT_DATABASE_URL\` in the project's environment settings and the derivation
+stands aside.
+
+If you would rather keep uploads somewhere you hold yourself — see *Leaving
+Vercel* below for why that matters — set \`FILESTORE_DRIVER=s3\` and add
+\`S3_BUCKET\`, \`S3_REGION\`, \`S3_ACCESS_KEY_ID\` and \`S3_SECRET_ACCESS_KEY\` in the
+project's environment settings, with \`S3_ENDPOINT\` for a bucket that is not AWS
+(\`S3_REGION=auto\` for R2). The same board runs either way.
+
+## Mail, after the deploy
 
 A board that cannot send mail cannot reset a password, so do this before you
-invite anybody.
+invite anybody. The deploy form already added Resend and published its key; two
+steps remain, and neither could have been answered on the form.
 
-1. Open your project on Vercel, go to **Storage → Marketplace** (or
-   **Integrations**), and add **Resend**. It creates a Resend account linked to
-   the project and connects your sending domain.
-2. Verify that domain in the Resend dashboard if you have not already. Resend
-   refuses to send from an address at a domain it has not verified.
+1. Verify your sending domain in the Resend dashboard if you have not already.
+   Resend refuses to send from an address at a domain it has not verified.
+2. Add \`MAIL_FROM\` to the project's environment settings — an address at that
+   verified domain, and the only mail value you ever type.
 3. Redeploy, or let the next push redeploy.
 
-That is all. The integration publishes its key into the project as
-\`RESEND_API_KEY\`, and the board reads that name: with it set, and \`MAIL_FROM\`
-already in place, mail sends over Resend's HTTPS API with nothing further to
-configure.
+That is all. The integration published its key into the project as
+\`RESEND_API_KEY\` when you deployed, and the board reads that name: with it set,
+and \`MAIL_FROM\` beside it, mail sends over Resend's HTTPS API with nothing
+further to configure.
 
 The board is not tied to Resend. Its mail driver is a plain JSON-over-HTTPS
 sender that posts \`{from, to, subject, text, html, reply_to}\` with a bearer
@@ -1178,15 +1186,23 @@ drains; nothing here runs it on its own, because there is no worker process on
 a function platform. Two things about it are worth knowing **before** you
 deploy rather than after:
 
-- **A per-minute schedule needs a paid plan.** Hobby allows a couple of cron
-  jobs and runs each of them roughly once a day, at an hour Vercel chooses;
-  only paid plans accept an arbitrary cron expression. A board ticking daily
-  still loses nothing — tasks are written so a missed run delays work rather
-  than dropping it — but "as it happens" notifications become a daily digest in
-  all but name. To keep a minute-by-minute tick on Hobby, drive
-  \`${TICK_PATH}\` from something else that can call a URL on a schedule — a
-  GitHub Actions workflow, a systemd timer, an uptime pinger — presenting
-  \`TICK_SECRET\` instead.
+- **This ships a daily schedule, because Hobby refuses anything faster.** A
+  Hobby plan rejects a cron expression that would run more than once a day —
+  the deployment fails outright rather than being slowed down — so
+  \`vercel.json\` carries \`${TICK_SCHEDULE}\` and deploys anywhere. On a
+  paid plan, edit it to \`* * * * *\` and the board ticks every minute.
+
+  A daily tick loses nothing permanently: tasks are written so a missed run
+  delays work rather than dropping it, and a password reset is sent as the
+  request is handled rather than waiting for a tick. What it does delay is
+  everything the tick drives — a new post is not findable in search, and a
+  notification is not sent, until the next run.
+
+  **To keep a fast tick without paying**, drive \`${TICK_PATH}\` from anything
+  that can call a URL on a schedule — a GitHub Actions workflow, a systemd
+  timer, an uptime pinger — presenting \`TICK_SECRET\` instead of
+  \`CRON_SECRET\`. The endpoint accepts either, so the Vercel cron and an
+  outside scheduler can both drive it.
 - **\`maxDuration = 300\` is validated when the project builds, not when the
   function runs.** A plan that does not allow 300 seconds therefore **fails the
   deployment** rather than clamping the request. With Fluid Compute — the
@@ -1240,13 +1256,19 @@ a Blob store does not:
 DATABASE_URL=…            # Neon's pooled string
 DIRECT_DATABASE_URL=…     # Neon's DATABASE_URL_UNPOOLED
 FILESTORE_DRIVER=blob
-BLOB_READ_WRITE_TOKEN=…   # copy it out of the project's environment settings
+BLOB_READ_WRITE_TOKEN=…   # create one on the store; see below
 npm run community -- backup
 \`\`\`
 
 Run that from a checkout of this repository, with those four values in the
 environment — the CLI talks to Neon and to the Blob store over the network, so
-it does not have to run on Vercel. The bundle it writes holds the dump *and*
+it does not have to run on Vercel.
+
+That last one is the one value this route asks you to make by hand, and only
+here. On the deployment the board reaches the store with \`BLOB_STORE_ID\` and
+the deployment's OIDC identity, which a command on your own machine does not
+have. Open the store under **Storage**, create a read-write token, and use it
+for the backup; the board itself never needs it. The bundle it writes holds the dump *and*
 every object. Check the last line it prints: if it says *no uploads*, the
 uploads are not in the bundle and restoring it gives a board whose posts have
 broken images.