Put it in a repository

Check what would be committed

The scaffold ships with this:

node_modules/
dist/
.env
.env.*
!.env.example
.DS_Store

# Vercel CLI project link (created by `npm run deploy`).
.vercel/

# Supabase CLI working directory.
.supabase/

# `.envrc` exists for one purpose — `export CHATFUEL_TOKEN=…` — and direnv users
# never think of it as a dotenv file, so the rules above do not cover it.
.envrc

# Keys, and the server log: with AUTH_RECOVERY_LINK_LOG on, the log is the only
# place a password recovery link is ever written.
*.pem
*.key
*.log

.env.example is the one .env* meant to be published — it holds the names of the variables and none of the values. Before the first push, read the index rather than the ignore file:

git add -A
git ls-files --cached |
  grep -E '(^|/)\.env|(^|/)\.vercel/|(^|/)\.aws/credentials$|(^|/)(\.npmrc|\.git-credentials|\.netrc|_netrc)$|\.(pem|key|p12|pfx|jks|keystore|ppk)$|(^|/)id_(rsa|ed25519)' |
  grep -vE '\.(example|sample|template)$'

Nothing back means nothing forbidden is staged. Then check by content as well as by name, because a token can be pasted into a file that is not called .env:

TOKEN=$(grep '^CHATFUEL_TOKEN=' .env | cut -d= -f2-)
[ -n "$TOKEN" ] && git grep --cached -l -F -e "$TOKEN"

That is the pair of checks the wizard runs itself. By name it refuses every file whose name starts with .env and does not end .example, .sample or .template — .envrc included — plus *.pem, *.key, *.p12, *.pfx, *.jks, *.keystore, *.ppk, id_rsa*, id_ed25519*, .npmrc, .git-credentials, .netrc, _netrc, an .aws/credentials, and anything under .vercel/.

By content it searches for the values the run itself holds, read out of the scaffold's own variable declarations rather than a list somebody has to remember to extend: the Chatfuel token, the Supabase secret key, the Supabase access token, and every module variable declared secret — ADMIN_PASSWORD and PUBLISHING_SECRET among them. Anything shorter than 16 characters is skipped. The Supabase URL, the anon key and the workspace id are declared not secret and are never searched for: all three are shipped to the browser by design, and a gate that cries wolf gets switched off.

The patterns go to git in a file rather than on a command line, which every process on the machine can read. And a scan that could not run stops the push instead of blessing it — a broken index and a clean tree both come back as no output, and reading the first as the second is how a live token gets published.

Push it

Make a push deploy

Once a repository exists, connecting it means git push and npm run deploy do the same thing and you can stop remembering which:

npm run connect-git

Two things must already be true, and the script checks both before it calls the Vercel CLI, because Vercel's own error for either is a menu you did not expect. The project must be linked — .vercel/project.json, written by npm run deploy — and there must be an origin remote. An SSH remote or one carrying a username names the same repository in a form the CLI does not accept, so the script rewrites it to a plain https://host/owner/repo first.

Re-running is safe: vercel git connect on an already-connected project is a no-op that says so.

The commonest failure is not this app's: a Vercel account with no GitHub connection at all, which only you can grant, in a browser. The script prints Vercel's own words first and then the two places to fix it.

The wizard offers this step itself, but only when the deploy step already linked a project — without one there is nothing to connect the repository to.

And only when Vercel's GitHub connection is there. Still missing at that point, and it does not ask whether a push should redeploy — vercel git connect would refuse on the first call — but says what is off, where to switch it on, and the same npm run connect-git to run once you have.

Verify

npm run connect-git prints Connected — pushing to the default branch now deploys to production. Prove it rather than believe it. Change something committed that you can see from the outside — a heading in one of your modules, a token in src/vendor/ui/styles/tokens.css, the logo file in public/ — then:

git add -A && git commit -m "A change I can see" && git push

Watch the deployment appear on Vercel and open the production URL. If nothing happens, the repository is not connected and npm run connect-git says why.

Then check the repository itself for the thing that matters most:

gh api repos/{owner}/{repo}/contents/.env --jq .name

A 404 is the answer you want. Anything else means .env is in the repository and you are on the callout below.