# Isekai Backend

> Ship a sellable full-stack app, not a frontend mockup. Use whenever a build needs real data, accounts, payments, or a live URL — auth, database schema, Row Level Security, file storage, or deploying to production. Stack is Next.js + Supabase (Postgres/Auth/Storage) + Vercel, all on free tiers. Pair with the isekai skill for the UI and the shadcn skill for components.

- **Type:** Skill
- **Install:** `agentstack add skill-starchybomb-isekai-isekai-backend`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [StarchyBomb](https://agentstack.voostack.com/s/starchybomb)
- **Installs:** 0
- **Category:** [Databases](https://agentstack.voostack.com/c/databases)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [StarchyBomb](https://github.com/StarchyBomb)
- **Source:** https://github.com/StarchyBomb/isekai/tree/main/skills/isekai-backend

## Install

```sh
agentstack add skill-starchybomb-isekai-isekai-backend
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Isekai Backend — the other half of a $10k build

A beautiful frontend with no real backend is a mockup, not a product. This skill is what turns an isekai build into something a client could actually log into, pay for, and trust with their data. Use it any time a build needs accounts, a database, uploads, or a real deploy — not just "add a backend" requests.

## Stack (free, production-grade)

- **Database + Auth + Storage**: Supabase (hosted Postgres, free tier: 500MB DB, 1GB storage, 50k monthly active users)
- **Framework**: Next.js App Router, deployed on Vercel's free Hobby tier
- **Client**: `@supabase/ssr` — the current official package for cookie-based sessions in Next.js. The old `auth-helpers-nextjs` is deprecated; never scaffold it.
- **Components**: use the `shadcn` skill for forms, tables, and auth screens instead of hand-rolling markup.

## BANNED (the default AI-backend look — never ship any of these)

- Row Level Security left **off** "for now" — the #1 way Supabase side-projects leak every row to anyone with the anon key
- `service_role` key referenced anywhere in a Client Component or a `NEXT_PUBLIC_*` env var
- Secrets committed to the repo with no `.env.example` for the next person
- One Supabase project shared between local dev and production
- Forms that write straight to the client SDK with no server-side validation
- Tables with no `created_at`/`updated_at`, no primary key strategy, or naming that mixes `camelCase` and `snake_case`
- Auth screens built from scratch when a shadcn block already exists for it
- "It works on my machine" — nothing pushed to Vercel, no live URL to hand the client

## Process

1. **Design the schema first.** List entities and relationships before writing SQL. `snake_case` tables and columns, `id uuid primary key default gen_random_uuid()`, `created_at timestamptz default now()`, `updated_at` maintained by a trigger. Foreign keys with an explicit `on delete` policy — don't leave it to default.
2. **Turn on RLS the moment you create the table.** `alter table public. enable row level security;` is not optional and not a later step. Write one policy per operation (`select`/`insert`/`update`/`delete`) scoped to `auth.uid()`, not one broad `for all` policy that overshares.
3. **Wire auth with `@supabase/ssr`.** Server client for Server Components/Route Handlers, browser client for Client Components, middleware to refresh the session on every request. See [references/supabase-nextjs.md](references/supabase-nextjs.md) for the exact client setup.
4. **Mutations go through Server Actions or Route Handlers**, never a client-side `.insert()` on a form submit with no server check. Validate input server-side even if the client already validated it.
5. **Storage buckets get policies too** — mirror the same `auth.uid()` logic as table RLS. Public buckets only for genuinely public assets (avatars, product images); everything else gets signed URLs.
6. **Generate types, don't hand-write them.** `supabase gen types typescript --project-id  > types/database.ts` after every schema change, so the app is type-safe against the real schema.
7. **Two Supabase projects minimum** — one for local/preview, one for production. Never point a Vercel Preview deployment at the production database.
8. **Deploy to Vercel.** Import the GitHub repo, set env vars per environment (Production/Preview/Development get different Supabase projects), confirm the build succeeds, then click through the live URL like a client would — signup, login, the core flow — before calling it done.

## Env vars (know which side of the fence each one is on)

| Variable | Exposed to browser? | Where it lives |
|---|---|---|
| `NEXT_PUBLIC_SUPABASE_URL` | Yes | Fine client-side |
| `NEXT_PUBLIC_SUPABASE_ANON_KEY` | Yes | Fine client-side — RLS is what actually protects data, not hiding this key |
| `SUPABASE_SERVICE_ROLE_KEY` | **Never** | Server only: Route Handlers, Server Actions, cron/edge functions. Bypasses RLS entirely. |

## The "sellable" checklist (before calling it done)

- [ ] RLS enabled on every table in `public`, policies tested with a non-owner account
- [ ] Auth flow works end-to-end: signup, login, logout, session persists across refresh
- [ ] Loading, empty, and error states exist for every data-fetching view — not just the happy path
- [ ] Form validation happens server-side, not just in the browser
- [ ] `.env.example` committed, real `.env.local` gitignored
- [ ] Production and preview point at separate Supabase projects
- [ ] Deployed to Vercel with a working live URL, custom domain connected if the client has one
- [ ] Spam/abuse protection on public forms (contact, signup) — pair with the `turnstile-spin` skill if bot traffic is a concern
- [ ] Basic SEO: page titles, meta description, OG image — a link shared in Slack should look intentional

## References
- [references/supabase-nextjs.md](references/supabase-nextjs.md) — exact `@supabase/ssr` client/middleware setup for App Router
- [references/schema-and-rls.md](references/schema-and-rls.md) — schema conventions and RLS policy patterns with copy-pasteable SQL
- [references/vercel-deploy.md](references/vercel-deploy.md) — connecting the repo, env var scoping, preview vs production, free-tier limits

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [StarchyBomb](https://github.com/StarchyBomb)
- **Source:** [StarchyBomb/isekai](https://github.com/StarchyBomb/isekai)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** yes
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-starchybomb-isekai-isekai-backend
- Seller: https://agentstack.voostack.com/s/starchybomb
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.