getaura 0.0.0-stage → 0.1.0

package/templates/guides/github-security.md

@@ -0,0 +1,63 @@
+---
+title: Secure your GitHub repository
+summary: Turn on branch protection, secret scanning, Dependabot and private vulnerability reporting for your repository.
+services: [github]
+---
+
+# Secure your GitHub repository
+
+These settings stop broken or unsafe code from reaching `main`, catch secrets before they're pushed, and warn you about vulnerable packages. They take about ten minutes. You need admin access to the repository.
+
+Some features on private repositories need a paid GitHub plan. Where that applies, it's noted below.
+
+## 1. Protect the main branch
+
+Every change to `main` should go through a pull request with passing checks.
+
+1. Open the repository → **Settings → Rules → Rulesets**.
+2. Click **New ruleset → New branch ruleset**. Name it `Protect main`.
+3. Set **Enforcement status** to **Active**.
+4. Under **Target branches**, click **Add target → Include default branch**.
+5. Turn on:
+   - **Restrict deletions**
+   - **Require a pull request before merging** (set required approvals to 0 if you work alone, so you can still merge your own PRs)
+   - **Require status checks to pass**, then **Add checks** and pick your CI checks (for example `Lint, test, build` and `Aura score`). They appear after they've run once.
+   - **Block force pushes**
+6. Click **Create**.
+
+Rulesets on private repositories need GitHub Pro, Team or Enterprise. On the free plan they only work on public repositories.
+
+## 2. Secret scanning and push protection
+
+Push protection blocks a push that contains a known secret, before it reaches GitHub.
+
+1. Open **Settings → Advanced Security** (called **Code security** on some accounts).
+2. Under **Secret Protection**, click **Enable** for **Secret scanning** and **Push protection**.
+
+These are free on public repositories. Private repositories need GitHub Secret Protection (paid). The Aura pre-commit hook (`aura apply add-pre-commit`) gives similar protection on your own machine for free.
+
+## 3. Dependabot
+
+1. On the same **Advanced Security** page, under **Dependabot**, enable **Dependabot alerts** and **Dependabot security updates**.
+2. For regular version updates, merge the pull request from `aura apply enable-dependency-updates`.
+
+These are free on all repositories.
+
+## 4. Private vulnerability reporting
+
+Lets security researchers report problems privately instead of in a public issue.
+
+1. On the **Advanced Security** page, enable **Private vulnerability reporting**.
+
+Available on public repositories.
+
+## 5. Your account
+
+- Turn on two-factor authentication: profile picture → **Settings → Password and authentication**. Use an authenticator app or a passkey, and save your recovery codes in a password manager.
+- Review who has access: repository **Settings → Collaborators and teams**. Remove anyone who no longer needs it.
+
+## Check it worked
+
+- Try pushing directly to `main` (`git push origin main` with a small change). GitHub rejects it.
+- **Settings → Advanced Security** shows secret scanning, push protection, Dependabot alerts and security updates as enabled (where your plan allows).
+- Run `aura scan`; the GitHub settings findings are gone.

package/templates/guides/install-github-cli.md

@@ -0,0 +1,50 @@
+---
+title: Install the GitHub CLI
+summary: Install the gh command and sign in, so Aura and your coding agent can open pull requests for you.
+services: [github]
+---
+
+# Install the GitHub CLI
+
+Aura opens pull requests with the GitHub CLI (`gh`). You install it once per computer.
+
+## Install
+
+**Mac**: install Homebrew from https://brew.sh if you don't have it, then in Terminal run:
+
+```bash
+brew install gh
+```
+
+**Windows**: in PowerShell or Windows Terminal, run:
+
+```bash
+winget install --id GitHub.cli
+```
+
+Then close and reopen the terminal.
+
+**Linux**: follow the instructions for your distribution at https://github.com/cli/cli/blob/trunk/docs/install_linux.md.
+
+## Sign in
+
+1. Run:
+   ```bash
+   gh auth login
+   ```
+2. Answer the questions:
+   - Where do you use GitHub? **GitHub.com**
+   - Preferred protocol for Git operations? **HTTPS**
+   - Authenticate Git with your GitHub credentials? **Yes**
+   - How would you like to authenticate? **Login with a web browser**
+3. Copy the one-time code shown, press Enter, paste the code in the browser that opens, and approve.
+
+## Check it worked
+
+Run:
+
+```bash
+gh auth status
+```
+
+It shows "Logged in to github.com" with your username. Then run `aura scan` again.

package/templates/guides/rotate-anthropic-key.md

@@ -0,0 +1,33 @@
+---
+title: Rotate an Anthropic key
+summary: Replace a leaked Anthropic (Claude API) key so nobody else can run up usage on your account.
+services: [anthropic, vercel]
+---
+
+# Rotate an Anthropic key
+
+A leaked Anthropic key (`sk-ant-...`) lets anyone use the Claude API on your bill.
+
+## Steps
+
+1. Sign in to the Claude Console at https://console.anthropic.com (it may redirect to platform.claude.com) and open **Settings → API keys**.
+2. Click **Create key**, pick the right workspace, name it (for example `production-2026`), and copy it. It's only shown once.
+3. Update your app with the new key, usually `ANTHROPIC_API_KEY` (see "Update your app").
+4. Back in **API keys**, click the **⋯** menu next to the leaked key and **Delete** it (or **Disable** it first if you want to be able to undo).
+
+## Update your app
+
+1. In Vercel, open your project → **Settings → Environment Variables**, edit the variable, paste the new key, and save for every environment.
+2. Redeploy: **Deployments**, **⋯** on the latest production deployment, **Redeploy**.
+3. Update your local `.env.local`.
+4. Update any other place that used the key.
+
+## Check it worked
+
+- The old key is deleted or shows as disabled.
+- Use the AI feature in your live app. It works.
+- Check **Usage** and **Cost** for unusual activity while the key was exposed. Set spend limits under **Settings → Limits**.
+
+## About git history
+
+Once the key is deleted, it's useless, so it doesn't matter that it's still in your git history. Rewriting history is optional, risky, and not needed.

package/templates/guides/rotate-aws-key.md

@@ -0,0 +1,39 @@
+---
+title: Rotate an AWS access key
+summary: Replace a leaked AWS access key, delete the old one and check your account for misuse.
+services: [aws, vercel]
+---
+
+# Rotate an AWS access key
+
+A leaked AWS access key (`AKIA...`) can let someone start expensive servers in your account, often within minutes, or read your files. Act now.
+
+## Steps
+
+1. Sign in to the AWS console and open **IAM → Users**. Click the user the key belongs to, then the **Security credentials** tab.
+2. Under **Access keys**, click **Create access key**, pick the use case, and copy the new key and secret. The secret is only shown once.
+3. Update your app with the new key (see "Update your app"), usually `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`.
+4. Back under **Access keys**, find the leaked key. Choose **Actions → Deactivate**, check the app still works, then **Actions → Delete**.
+5. Give the user only the permissions the app needs (for example access to one S3 bucket), not administrator access.
+
+## Check for misuse
+
+1. Open **Billing and Cost Management** and look for unexpected charges.
+2. Check **EC2** in every region (use the region menu at the top) for servers you didn't start, and delete them.
+3. Open **CloudTrail → Event history** and filter by the leaked access key ID to see what it did.
+4. If AWS emailed you about an exposed key or attached a quarantine policy to the user, follow the steps in that email and open a support case if you find misuse.
+
+## Update your app
+
+1. In Vercel, open your project → **Settings → Environment Variables**, update both values, and save for every environment. Then **Deployments → ⋯ → Redeploy** on the latest production deployment.
+2. Update your local `.env.local` and any GitHub Actions secrets.
+
+## Check it worked
+
+- The leaked key is deleted from the user's access keys.
+- The feature that uses AWS (uploads, email, etc.) works in your live app.
+- No unexpected resources or charges remain.
+
+## About git history
+
+Once the key is deleted, it's useless, so it doesn't matter that it's still in your git history. Rewriting history is optional, risky, and not needed.

package/templates/guides/rotate-database-key.md

@@ -0,0 +1,39 @@
+---
+title: Rotate a database password
+summary: Reset a leaked database password or connection string so the old one stops working.
+services: [supabase, vercel]
+---
+
+# Rotate a database password
+
+A database connection string (`postgresql://user:password@host/...`) or database password gives direct access to your data, bypassing every security rule in your app. Reset it now.
+
+## Supabase database
+
+1. Open https://supabase.com/dashboard, pick the project, then **Project Settings → Database**.
+2. Click **Reset database password**. Generate a strong password and copy it.
+3. Click **Connect** at the top of the project page to copy the new connection strings (they include the new password).
+4. Update your app (see below), usually `DATABASE_URL`, `POSTGRES_URL` or `SUPABASE_DB_URL`.
+
+Resetting the password doesn't affect your Supabase API keys or signed-in users. Only tools that connect directly to the database need the new password.
+
+## Other Postgres providers
+
+- **Neon**: open the project → **Branches**, pick the branch → **Roles**, then **Reset password** for the role. Copy the new connection string from **Connect**.
+- **Any other provider**: find the database user or role in its dashboard and reset the password, or create a new user, switch the app to it, then delete the old one.
+
+## Update your app
+
+1. In Vercel, open your project → **Settings → Environment Variables**, update every variable that holds the connection string or password, and save for every environment. If a Vercel integration manages these variables, check they updated.
+2. Redeploy: **Deployments**, **⋯** on the latest production deployment, **Redeploy**.
+3. Update your local `.env.local`, GitHub Actions secrets, and any other tool that connects to the database (admin tools, scripts, backups).
+
+## Check it worked
+
+- The old connection string no longer connects.
+- Your live app reads and writes data normally.
+- If your provider has database logs, check for connections you don't recognize while the password was exposed.
+
+## About git history
+
+Once the password is reset, the old one is useless, so it doesn't matter that it's still in your git history. Rewriting history is optional, risky, and not needed.

package/templates/guides/rotate-generic-key.md

@@ -0,0 +1,37 @@
+---
+title: Rotate a secret
+summary: The general steps to replace any leaked key, token or password and switch off the old one.
+services: [vercel]
+---
+
+# Rotate a secret
+
+Use this for any key, token or password that doesn't have its own guide. Rotating means creating a new secret, switching your app to it, and switching off the old one so whoever has it can't use it.
+
+## Steps
+
+1. **Find where it came from.** The variable name or the start of the value usually names the service (for example `TWILIO_...`). Sign in to that service's dashboard.
+2. **Find its keys page.** Look under **Settings**, **Developers**, **API keys**, **Tokens** or **Credentials**.
+3. **Create a new key.** Give it a clear name and only the permissions your app needs. Copy it; most services only show it once.
+4. **Update your app** (see below) and confirm it works with the new key.
+5. **Delete or revoke the old key** in the same dashboard. If the service only lets you "regenerate" a key, doing that replaces the old one in one step; update your app right after.
+6. **Check for misuse.** Look at the service's usage, billing and logs for activity you don't recognize while the key was exposed.
+
+For a private key (`-----BEGIN PRIVATE KEY-----`), generate a new key pair where it's used (a server, a signing service, an SSH host), install the new public key, and remove the old one.
+
+## Update your app
+
+1. In Vercel, open your project → **Settings → Environment Variables**, update the variable, and save for every environment.
+2. Redeploy: **Deployments**, **⋯** on the latest production deployment, **Redeploy**. New values only apply to new deployments.
+3. Update your local `.env.local`.
+4. Update any other place that stores the secret: GitHub Actions secrets, other services, teammates' machines.
+
+## Check it worked
+
+- The old key no longer appears in the service's dashboard, or shows as revoked.
+- The feature that uses it works in your live app.
+- Run `aura scan` to confirm Aura no longer finds the secret in your code.
+
+## About git history
+
+Once the secret is rotated, the old one is useless, so it doesn't matter that it's still in your git history. Rewriting history to remove it is optional, risky (it can break other people's copies of the repo), and not needed.

package/templates/guides/rotate-github-token.md

@@ -0,0 +1,36 @@
+---
+title: Rotate a GitHub token
+summary: Revoke a leaked GitHub personal access token and replace it with a new, narrowly scoped one.
+services: [github, vercel]
+---
+
+# Rotate a GitHub token
+
+A leaked GitHub token (`ghp_...`, `github_pat_...`, `gho_...`) can let someone read or change your code, depending on its permissions. Revoke it now.
+
+## Steps
+
+1. On GitHub, click your profile picture → **Settings → Developer settings → Personal access tokens** (direct link: https://github.com/settings/tokens).
+2. Find the leaked token under **Fine-grained tokens** or **Tokens (classic)**. Click it and choose **Delete** (fine-grained) or **Delete** next to it (classic). It stops working immediately.
+3. If your app or a workflow needs a token, click **Generate new token → Fine-grained token**. Choose only the repositories it needs, only the permissions it needs, and an expiration date. Copy it; it's only shown once.
+4. Update the places that used the old token (see "Update your app").
+
+If the token belonged to a GitHub App or OAuth app instead, open **Developer settings → GitHub Apps** (or **OAuth Apps**), pick the app, and generate a new private key or client secret, then delete the old one.
+
+Inside GitHub Actions, prefer the built-in `GITHUB_TOKEN` over a personal token. It's created for each run and expires automatically.
+
+## Update your app
+
+1. In Vercel, open your project → **Settings → Environment Variables**, update the variable (often `GITHUB_TOKEN`), and save for every environment. Then **Deployments → ⋯ → Redeploy** on the latest production deployment.
+2. Update repository secrets in GitHub: **Settings → Secrets and variables → Actions**.
+3. Update your local `.env.local`.
+
+## Check it worked
+
+- The old token is gone from the list.
+- Check the security log (**Settings → Security log**) and your repositories for actions you don't recognize while the token was exposed.
+- Whatever used the token (deploys, scripts) still works with the new one.
+
+## About git history
+
+Once the token is deleted, it's useless, so it doesn't matter that it's still in your git history. Rewriting history is optional, risky, and not needed.

package/templates/guides/rotate-google-key.md

@@ -0,0 +1,45 @@
+---
+title: Rotate a Google API key
+summary: Replace a leaked Google Cloud or Gemini API key, or service account key, and restrict the new one.
+services: [google, vercel]
+---
+
+# Rotate a Google API key
+
+Google API keys start with `AIza`. Some are meant to be public (Firebase web config, Maps in the browser) and only need restricting. Keys for paid APIs such as Gemini, or service account JSON keys, must stay secret and need rotating if leaked.
+
+## Gemini API key (Google AI Studio)
+
+1. Open https://aistudio.google.com/apikey.
+2. Click **Create API key**, pick the same Google Cloud project, and copy it.
+3. Update your app (see "Update your app"), usually `GEMINI_API_KEY` or `GOOGLE_GENERATIVE_AI_API_KEY`.
+4. Delete the leaked key from the same page. If there's no delete option, open the project in the Google Cloud console, go to **APIs & Services → Credentials**, and delete it there.
+
+## Google Cloud API key
+
+1. Open https://console.cloud.google.com, pick the project, then **APIs & Services → Credentials**.
+2. Click **Create credentials → API key** and copy the new key.
+3. Click the new key and add restrictions: under **API restrictions**, allow only the APIs your app uses. For keys used in the browser, add **Website restrictions** with your domain.
+4. Update your app (see below).
+5. Back in **Credentials**, delete the leaked key.
+
+## Service account key (JSON file)
+
+1. In the Cloud console, open **IAM & Admin → Service Accounts**, click the account, then the **Keys** tab.
+2. Click **Add key → Create new key → JSON**. The file downloads. Store its contents as an environment variable, never in the repo.
+3. Update your app (see below), then delete the leaked key from the same **Keys** tab.
+
+## Update your app
+
+1. In Vercel, open your project → **Settings → Environment Variables**, update the variable, and save for every environment. Then **Deployments → ⋯ → Redeploy** on the latest production deployment.
+2. Update your local `.env.local` and any GitHub Actions secrets.
+
+## Check it worked
+
+- The leaked key is gone from **Credentials** or **Keys**.
+- The feature that uses Google works in your live app.
+- Check **Billing** for unexpected usage while the key was exposed, and set a budget alert under **Billing → Budgets & alerts**.
+
+## About git history
+
+Once the key is deleted, it's useless, so it doesn't matter that it's still in your git history. Rewriting history is optional, risky, and not needed.

package/templates/guides/rotate-openai-key.md

@@ -0,0 +1,33 @@
+---
+title: Rotate an OpenAI key
+summary: Replace a leaked OpenAI API key so nobody else can run up usage on your account.
+services: [openai, vercel]
+---
+
+# Rotate an OpenAI key
+
+A leaked OpenAI key lets anyone use the API on your bill. Leaked keys are often abused within minutes.
+
+## Steps
+
+1. Sign in at https://platform.openai.com and open **API keys** (direct link: https://platform.openai.com/api-keys). If you use projects, pick the right project at the top first.
+2. Click **Create new secret key**. Name it (for example `production-2026`), choose the same project, and set permissions as narrow as your app allows. Copy the key; it's only shown once.
+3. Update your app with the new key, usually `OPENAI_API_KEY` (see "Update your app").
+4. Back in **API keys**, find the leaked key and click the trash icon to **Revoke** it.
+
+## Update your app
+
+1. In Vercel, open your project → **Settings → Environment Variables**, edit the variable, paste the new key, and save for every environment.
+2. Redeploy: **Deployments**, **⋯** on the latest production deployment, **Redeploy**.
+3. Update your local `.env.local`.
+4. Update any other place that used the key (GitHub Actions secrets, other services).
+
+## Check it worked
+
+- The old key no longer appears in the list.
+- Use the AI feature in your live app. It works.
+- Open **Usage** and look for unusual spikes while the key was exposed. Set a monthly budget under **Settings → Limits** if you haven't.
+
+## About git history
+
+Once the key is revoked, it's useless, so it doesn't matter that it's still in your git history. Rewriting history is optional, risky, and not needed.

package/templates/guides/rotate-resend-key.md

@@ -0,0 +1,32 @@
+---
+title: Rotate a Resend key
+summary: Replace a leaked Resend API key so nobody can send email from your domain.
+services: [resend, vercel]
+---
+
+# Rotate a Resend key
+
+A leaked Resend key (`re_...`) lets someone send email that looks like it comes from your domain, which can hurt your reputation and get your emails marked as spam.
+
+## Steps
+
+1. Sign in at https://resend.com and open **API Keys** (direct link: https://resend.com/api-keys).
+2. Click **Create API Key**. Give it a name, choose **Sending access** (not full access) and, if you can, limit it to your sending domain. Copy the key; it's only shown once.
+3. Update your app (see "Update your app"), usually `RESEND_API_KEY`.
+4. Back in **API Keys**, click the **⋯** menu next to the leaked key and remove it.
+
+## Update your app
+
+1. In Vercel, open your project → **Settings → Environment Variables**, update the variable, and save for every environment.
+2. Redeploy: **Deployments**, **⋯** on the latest production deployment, **Redeploy**.
+3. Update your local `.env.local`. If Supabase sends auth emails through Resend SMTP, update the password in Supabase too (**Authentication → Emails → SMTP Settings**).
+
+## Check it worked
+
+- The leaked key is gone from the list.
+- Trigger an email from your live app (for example a password reset). It arrives.
+- Check **Emails** and **Logs** in Resend for messages you didn't send while the key was exposed.
+
+## About git history
+
+Once the key is removed, it's useless, so it doesn't matter that it's still in your git history. Rewriting history is optional, risky, and not needed.

package/templates/guides/rotate-sendgrid-key.md

@@ -0,0 +1,32 @@
+---
+title: Rotate a SendGrid key
+summary: Replace a leaked SendGrid API key so nobody can send email from your account.
+services: [sendgrid, vercel]
+---
+
+# Rotate a SendGrid key
+
+A leaked SendGrid key (`SG.` followed by a long value) lets someone send email from your account, which can get it suspended and your domain marked as spam.
+
+## Steps
+
+1. Sign in at https://app.sendgrid.com and open **Settings → API Keys**.
+2. Click **Create API Key**. Choose **Restricted Access** and turn on only **Mail Send** (plus anything else your app really uses). Copy the key; it's only shown once.
+3. Update your app (see "Update your app"), usually `SENDGRID_API_KEY`.
+4. Back in **API Keys**, click the gear or **⋯** menu next to the leaked key and **Delete** it.
+
+## Update your app
+
+1. In Vercel, open your project → **Settings → Environment Variables**, update the variable, and save for every environment.
+2. Redeploy: **Deployments**, **⋯** on the latest production deployment, **Redeploy**.
+3. Update your local `.env.local`, and the SMTP password anywhere else that uses this key.
+
+## Check it worked
+
+- The leaked key is gone from the list.
+- Trigger an email from your live app. It arrives.
+- Check **Activity** for emails you didn't send while the key was exposed.
+
+## About git history
+
+Once the key is deleted, it's useless, so it doesn't matter that it's still in your git history. Rewriting history is optional, risky, and not needed.

package/templates/guides/rotate-slack-key.md

@@ -0,0 +1,48 @@
+---
+title: Rotate a Slack token or webhook
+summary: Revoke a leaked Slack bot token, signing secret or incoming webhook URL and replace it.
+services: [slack, vercel]
+---
+
+# Rotate a Slack token or webhook
+
+Slack secrets come in a few kinds. Find which one leaked:
+- **Bot or user token** (`xoxb-...`, `xoxp-...`): can read and post messages as your app.
+- **Incoming webhook URL** (`https://hooks.slack.com/services/...`): can post messages to a channel.
+- **Signing secret**: lets someone fake requests from Slack to your app.
+
+All of them are managed at https://api.slack.com/apps. Pick your app first.
+
+## Bot or user token
+
+1. Open **OAuth & Permissions**. If you see a **Revoke** option for tokens, use it. Otherwise ask your coding agent to call Slack's `auth.revoke` method with the leaked token; that switches it off immediately.
+2. Click **Reinstall to Workspace** (on **OAuth & Permissions** or **Install App**) and approve. Slack issues a new token.
+3. Copy the new token and update your app (see below), usually `SLACK_BOT_TOKEN`.
+
+## Incoming webhook URL
+
+1. Open **Incoming Webhooks**.
+2. Click **Add New Webhook to Workspace**, pick the same channel, and copy the new URL.
+3. Update your app (see below), usually `SLACK_WEBHOOK_URL`.
+4. Back on **Incoming Webhooks**, remove the leaked webhook from the list.
+
+## Signing secret
+
+1. Open **Basic Information → App Credentials**.
+2. Next to **Signing Secret**, click **Regenerate** and copy the new value.
+3. Update your app (see below), usually `SLACK_SIGNING_SECRET`.
+
+## Update your app
+
+1. In Vercel, open your project → **Settings → Environment Variables**, update the variable, and save for every environment.
+2. Redeploy: **Deployments**, **⋯** on the latest production deployment, **Redeploy**.
+3. Update your local `.env.local`.
+
+## Check it worked
+
+- The Slack feature in your live app works with the new value.
+- Check the channel for messages you didn't send while the secret was exposed.
+
+## About git history
+
+Once the secret is revoked, it's useless, so it doesn't matter that it's still in your git history. Rewriting history is optional, risky, and not needed.

package/templates/guides/rotate-stripe-key.md

@@ -0,0 +1,41 @@
+---
+title: Rotate a Stripe key
+summary: Replace a leaked Stripe secret, restricted or webhook key with a new one and switch off the old one.
+services: [stripe, vercel]
+---
+
+# Rotate a Stripe key
+
+A leaked Stripe secret key (`sk_live_...`) lets someone create charges, issue refunds and read your customers' data. Rotate it now, even if you've already deleted it from the code.
+
+## Secret or restricted key (`sk_...` or `rk_...`)
+
+1. Sign in at https://dashboard.stripe.com and open **Developers → API keys** (direct link: https://dashboard.stripe.com/apikeys).
+2. Check the mode: use the **Test mode** switch to match the leaked key. `sk_live_` is live mode, `sk_test_` is test mode.
+3. Find the leaked key. Click the **⋯** menu next to it and choose **Rotate key** (called **Roll key** on some accounts).
+4. Set the expiration to **Now** so the old key stops working immediately. If you can't update your app within minutes, pick 1 hour instead.
+5. Click **Rotate API key**, then copy the new key. Stripe only shows it once.
+6. Update the key everywhere it's used (see "Update your app" below), usually `STRIPE_SECRET_KEY`.
+
+## Webhook signing secret (`whsec_...`)
+
+1. Open **Developers → Webhooks** (https://dashboard.stripe.com/webhooks) and click the endpoint.
+2. Click **⋯ → Roll secret**, choose to expire the old one **Now**, and copy the new secret.
+3. Update `STRIPE_WEBHOOK_SECRET` (see below).
+
+## Update your app
+
+1. In Vercel, open your project → **Settings → Environment Variables**. Edit the variable, paste the new value, and save for every environment that used the old key.
+2. Redeploy: **Deployments**, click **⋯** on the latest production deployment, then **Redeploy**. New values only apply to new deployments.
+3. Update your local `.env.local` with the new value.
+4. If the key is also stored in GitHub Actions secrets or another service, update it there too.
+
+## Check it worked
+
+- In Stripe, the old key shows as expired or is gone from the list.
+- In your live app, try a payment flow (or a test payment in test mode). It works with the new key.
+- In **Developers → Logs** (or **Workbench → Logs**), look for requests from IP addresses you don't recognize during the time the key was exposed. If you see any, contact Stripe support.
+
+## About git history
+
+Once the key is rotated, the old key is useless, so it doesn't matter that it's still in your git history. Rewriting history to remove it is optional, risky (it can break other people's copies of the repo), and not needed.

package/templates/guides/rotate-supabase-key.md

@@ -0,0 +1,46 @@
+---
+title: Rotate a Supabase key
+summary: Replace a leaked Supabase secret or service_role key so the old one can no longer bypass your database security.
+services: [supabase, vercel]
+---
+
+# Rotate a Supabase key
+
+Supabase secret keys (`sb_secret_...`) and the legacy `service_role` key bypass row level security. Anyone who has one can read, change and delete everything in your database. Rotate a leaked one now.
+
+The publishable key (`sb_publishable_...`) and legacy `anon` key are meant to be public. They don't need rotating, as long as every table has row level security.
+
+## If the leaked key starts with `sb_secret_`
+
+1. Open https://supabase.com/dashboard, pick the project, then **Project Settings → API Keys**.
+2. In **Secret keys**, click **New secret key**, give it a name (for example `production-2026`), and copy it.
+3. Update your app with the new key (see "Update your app" below). Wait for the redeploy to finish.
+4. Back in **Secret keys**, click **⋯** next to the leaked key and **Delete** it. It stops working immediately.
+
+## If the leaked key is the legacy `service_role` key (a long `eyJ...` value)
+
+The legacy key can't be rotated on its own. The safest path is to switch to the new keys and turn the legacy ones off:
+
+1. In **Project Settings → API Keys**, create a publishable key and a secret key if they don't exist yet.
+2. Ask your coding agent to replace the legacy keys in the app: the publishable key replaces the `anon` key, the secret key replaces the `service_role` key. The Supabase client libraries accept them as drop-in replacements.
+3. Update your app's environment variables (see below) and redeploy. Check the app still works.
+4. Back in **Project Settings → API Keys**, open **Legacy API Keys** and click **Disable JWT-based API keys**. The leaked `service_role` key and the old `anon` key stop working.
+
+Alternative: rotating the project's legacy JWT secret (**Project Settings → JWT Keys**) also invalidates both legacy keys, but it signs out every user and changes the `anon` key too. Prefer the steps above.
+
+## Update your app
+
+1. In Vercel, open your project → **Settings → Environment Variables**. Update the variable that held the key (often `SUPABASE_SECRET_KEY` or `SUPABASE_SERVICE_ROLE_KEY`, and `NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY` or `NEXT_PUBLIC_SUPABASE_ANON_KEY` if you switched keys). Save for every environment.
+2. Redeploy: **Deployments**, **⋯** on the latest production deployment, **Redeploy**.
+3. Update your local `.env.local`.
+4. If GitHub Actions or another service uses the key, update it there too.
+
+## Check it worked
+
+- The leaked key is deleted, or legacy keys show as disabled.
+- Sign in to your live app and use a feature that reads and writes data. It works.
+- In **Logs** (API logs), look for unexpected requests during the time the key was exposed. If data may have been accessed, tell your coding agent so it can help you check what was touched.
+
+## About git history
+
+Once the key is rotated, the old key is useless, so it doesn't matter that it's still in your git history. Rewriting history is optional, risky, and not needed.

package/templates/guides/rotate-vercel-key.md

@@ -0,0 +1,44 @@
+---
+title: Rotate a Vercel key or token
+summary: Replace a leaked Vercel AI Gateway key or Vercel access token and delete the old one.
+services: [vercel]
+---
+
+# Rotate a Vercel key or token
+
+There are two kinds of Vercel secret:
+- **AI Gateway API keys** (`vck_...`) let someone use AI models on your Vercel bill.
+- **Access tokens** let someone deploy, change settings and read environment variables in your Vercel account. These are the more dangerous ones.
+
+## AI Gateway API key
+
+1. In the Vercel dashboard, open **AI Gateway** in the sidebar, then **API Keys**.
+2. Click **Create key**, name it, and copy it.
+3. Update your app (see "Update your app"), usually `AI_GATEWAY_API_KEY`.
+4. Back in **API Keys**, delete the leaked key.
+
+Apps deployed on Vercel can use AI Gateway without a stored key: Vercel provides a short-lived OIDC token automatically. Ask your coding agent whether your app can drop the key entirely. You'll still need a key for local development (or run `vercel env pull` to get a temporary token).
+
+## Access token
+
+1. Open **Account Settings → Tokens** (direct link: https://vercel.com/account/settings/tokens).
+2. Find the leaked token and click **Delete**. It stops working immediately.
+3. If something needs a token (for example a deploy script), click **Create Token**, limit its scope to one team, set an expiration, and copy it.
+4. Update the places that used the old token, such as GitHub Actions secrets (`VERCEL_TOKEN`).
+5. Check **Team Settings → Activity** (or your account's activity log) for deployments or changes you don't recognize, and review environment variables: a leaked token could have been used to read them. If so, rotate those secrets too.
+
+## Update your app
+
+1. In your Vercel project → **Settings → Environment Variables**, update the variable and save for every environment.
+2. Redeploy: **Deployments**, **⋯** on the latest production deployment, **Redeploy**.
+3. Update your local `.env.local`.
+
+## Check it worked
+
+- The leaked key or token no longer appears in the list.
+- The AI feature (or deploy script) works with the new one.
+- Check AI Gateway usage for unusual spend while the key was exposed.
+
+## About git history
+
+Once the key or token is deleted, it's useless, so it doesn't matter that it's still in your git history. Rewriting history is optional, risky, and not needed.