Release history

Fixes

• A valid anon key reaching a table whose anon grant had been revoked was reported as a rejected key, with advice to regenerate the secret. PostgREST answers 401 for both, so the workflow now reads the body: a 401 carrying Postgres code 42501 (permission denied for table …) says the key works and the endpoint needs a table the anon role can read.

Template

• New diagnosis for the revoked-grant 401. Other 401s are reported as before.

Fixes

• The workflow reported Supalive 1.1.0 in its job summary after 1.1.1 shipped. The version is stated inside the workflow — it has to be, since the file stands alone in a user's repository — which made it a fourth place recording it, and the first one to drift.

Template

• No behavioural change; the version string in the job summary is now correct.

Release

• scripts/build-release.sh now refuses to build unless the workflow's own VERSION matches the release too, alongside the tag, package.json and the CHANGELOG heading. Every place that records the version is now checked against every other.

Template

• supalive.yml opens with a header explaining what it does, that projects are added in projects.json rather than by editing the file, and that the job summary is what to read when a run fails. All three were documented only on the site, which is not where somebody looks when they already have the file open.

Nothing else in the download changed. The repository's own automation moved considerably in this window — the kit now opens pull requests against both the instance and the portal when either drifts — but none of it ships to users.

Failed runs now explain themselves. Previously a failure reported only a status code and the word failed, which reads the same whether a key was rotated, a table was dropped, a project was paused, or Supabase was mid-outage — four situations needing four different responses, none of them distinguishable without opening the Supabase dashboard.

Template

• Every failure is classified as action required (something you own needs changing) or outage (Supabase isn't answering, nothing here is misconfigured), stated in one line at the top of the job summary. Both still fail the run; the verdict says whether to act.
• Action-required failures annotate as errors and outages as warnings, so GitHub's annotations panel separates them without opening the summary.
• Each failed project gets a section with the cause, Supabase's own error message, the remedy, and a per-attempt log. The response body is read rather than discarded to /dev/null, so PostgREST naming a missing relation reaches the reader verbatim.
• Supabase's platform status codes are decoded in place: 540 paused, 402 restricted under the Fair Use Policy, 544 gateway timeout.
• Transport failures carry curl's exit code and its meaning. A DNS failure now reads as a deleted or mistyped project rather than a bare 000.
• Retries apply only to conditions that can clear on their own — three attempts across about a minute for a 5xx, none at all for a rejected key or a missing table.
• Documented that Supalive cannot revive an already-paused project: a paused project is refused at the gateway, so no ping reaches Postgres.

Fixes

• curl … || echo "000" concatenated curl's own 000 with the fallback, producing 000000 as a reported status on any transport failure.
• Actions runs the step as bash -e {0}, which set -uo pipefail does not clear. Reading curl's exit code deliberately, rather than masking it behind || echo, meant the first unreachable project would kill the step before any summary was written and skip every project after it. errexit is now disabled explicitly, which per-project error handling requires.

First release of supalive-kit — the distributable Supalive product, split out of a personal instance into a template, a setup application, and packaging anyone can use.

Template

• .github/workflows/supalive.yml resolves project secrets dynamically from ${{ toJSON(secrets) }}, keyed by name — adding or removing a project never requires editing the workflow file.
• Secret names are constrained to SUPABASE_ANON_KEY_*; any other secret referenced by projects.json is rejected before a request is made.
• Unused repository secrets are reported in the job summary, never treated as fatal.
• projects.example.json ships as the reference config; projects.json itself is meant to be committed to your own repository.

Setup app

• Real ping test before a project is accepted, using the exact request the workflow will make — warns rather than hard-blocks on a statusless network/CORS failure, since that's indistinguishable from a client-side condition rather than a broken project.
• Table to ping is any table you type, not one you have to find. The ping only needs to reach Postgres, not fetch meaningful data, so the setup app says that plainly instead of presenting table choice as a lookup problem — including that a table with RLS on and no anon policy still passes (200 + empty list, not an error; only a nonexistent table fails). A link beside the field opens the project's table editor for a copy-paste check.
• Table discovery runs silently in the background rather than as a user-facing step: no toast on success or failure, no button to click. It populates autocomplete suggestions when a project still allows it — most current Supabase projects don't — and otherwise says nothing at all, since a background convenience that didn't fire isn't a problem worth surfacing (earlier copy read as a bad key and sent someone to regenerate a fine one). Fixed across OpenAPI 2 and 3 response shapes for the projects that do allow it.
• Supports both legacy JWT and publishable (sb_publishable_…) anon keys.
• Secret suffix is derived from the project name automatically (editable) and validated at input time against the workflow's naming rule — the invalid-character case is prevented by construction, not just caught after the fact.
• Guided path (Add Project → Download) reads as a linear sequence in the main column; Projects detaches into a sticky sidebar past 900px wide, since it's a persistent view of what's configured, not another step. Manual tools (projects.json output, the GitHub Secrets guide, JSON import, reset) collapse under "Manual setup".
• Resume link (encode/restore project state via a URL fragment) alongside the existing import-from-projects.json flow.
• No hardcoded repository — the secrets-settings link is driven by a repo field you fill in, not a fixed address, with copy that spells out the username/repo format and says plainly that leaving it blank is fine.
• Built-in help: a ? button opens a short overview of what the tool does and how the four steps fit together, shown automatically on first visit and reachable anytime after.
• The "finish later" link (formerly "Copy resume link") says what it actually does and that it never includes your key, rather than assuming the reader already knows.

Packaging

• "Download ZIP" assembles a personalized archive client-side: the workflow, your projects.json, a per-user README, and a personalized AI-SETUP.md — a self-contained prompt for handing GitHub setup off to an AI assistant.
• Everything is generated in the browser. The setup app has no backend, so nothing you enter is transmitted anywhere except to your own Supabase project.

Docs

• docs/ — installation, features, and FAQ, written as product documentation rather than repository instructions.
• LICENSE — a short proprietary-but-freely-usable grant, replacing the MIT framing that would have contradicted a closed-source distribution.