instancez skill
A skill that teaches an agent to define a Supabase-compatible backend in one YAML file and run it with the instancez CLI.
- 62 ★ on the repository
- Last commit
- Apache-2.0
Extended access
Why this level
- The agent edits the schema and access policies and `inz dev` applies them to the local database at once.
- The secret key bypasses RLS and must never reach client code.
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/instancezDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- The agent edits the schema and access policies and `inz dev` applies them to the local database at once.
- The secret key bypasses RLS and must never reach client code.
This is third-party code. Review the repository files before installing.
What it does
The `instancez` skill lives in the repository's `skills/instancez` folder and teaches an agent how to build a backend on instancez. The product itself is one binary that turns `instancez.yaml` into Postgres CRUD, auth, storage, SQL RPC and Node.js functions. `@supabase/supabase-js` and other clients work with it unchanged. The skill covers YAML syntax for tables, RLS rules, auth, storage and functions. The working loop: `inz init` creates the file, `inz validate` checks references and types without a database, and `inz dev --embedded-pg` starts a server with a built-in Postgres 16. There are no hand-written migrations: on each run the schema is diffed against the live database and only the delta is applied. When a query is denied, the skill points to where in the RLS policies to look.
Who it is for. Developers who back an app built on a Supabase client and want the agent to maintain the schema in a single YAML file.
Good fit when
- A new app must work with `supabase-js` and the backend should be a single local binary.
- An agent adds a table and RLS policies and the changes must reach the database without migration files.
- A query returns an empty result and you need to find which policy cuts it off.
- A TypeScript frontend needs types produced by `inz gen types`.
Not a fit when
- The project stays on hosted Supabase and does not plan to move.
- You need the full Supabase feature set: the README feature parity table has gaps.
- Migrations must be stored as files in the repository: instancez applies the delta automatically, including drops.
Example request
Define a notes table in `instancez.yaml` with an RLS policy so each user sees only their own rows, then run `inz validate`.Limitations
The skill only works with instancez, and the `inz` CLI must be installed separately: with `curl -fsSL https://get.instancez.ai | sh` or built from source with Go and Node. The CLI sends anonymous telemetry, turned off with `inz telemetry disable`. Without `--embedded-pg`, `inz dev` needs a superuser database URL in `INSTANCEZ_DATABASE_URL`. Dropping tables and columns under `inz serve` needs `--allow-destructive`, while `inz dev` applies the schema immediately. The secret key bypasses RLS and stays server-side.
How to disable. Remove the skill from the agent directory, or through `/plugin` in Claude Code if you installed the plugin. The installed `inz` binary and local database data are removed separately.
FAQ
How do I install the instancez skill?
Run `npx skills add instancez/instancez` and the CLI detects your agents. Add a flag for one agent, for example `-a codex`. In Claude Code a plugin also works: `/plugin marketplace add instancez/instancez`, then `/plugin install instancez@instancez`.
Does the skill work for an agent without skills support?
Yes. The skill is a single `SKILL.md` file: put it in the project and reference it from `AGENTS.md`.
How is instancez compatible with Supabase?
The `@supabase/supabase-js` client and other Supabase client libraries work unchanged: auth, PostgREST-style REST, RPC and storage. The README feature parity table has the full list.
How do I get TypeScript types?
Run `inz gen types --out database.types.ts` and pass the result to `createClient<Database>()`. The command reads only the YAML, so run it again after a schema change.
Where are the API keys stored?
On the first `inz dev` run the keys are written to `.development.env` as `INSTANCEZ_PUBLISHABLE_KEY` and `INSTANCEZ_SECRET_KEY`. The secret key acts as `service_role` and bypasses RLS.
Discussion
No questions or reviews yet.
Related
SkillsSupabase's official skills: help an agent work with the database, Auth, Edge Functions and Postgres best practices
Supabase's official CLI: local stack, database migrations, Edge Functions deploys and type generation from the terminal
Three backend skills for agents that guard access, data and schema migrations: 2 of 150 runs had critical mistakes instead of 25.
A set of 14 skills for Java Spring Boot, from requirements analysis and code generation to tests, review and Docker deployment.
Thirty-two Tencent CloudBase skills: serverless functions, auth, AI models, storage and backend deployment in the cloud.
The Elysia v2 skill teaches an agent to build, debug and migrate Elysia backends: validation, plugins, typed clients, deploy
README in short
The product is presented as a single-binary Supabase replacement: the schema lives in one YAML file and it runs locally, in Docker, on a server or on AWS Lambda. A separate section covers the agent skill and three ways to install it.
README badge
Original SKILL.md
---
name: instancez
description: Use when building, changing, or deploying an instancez backend - editing instancez.yaml (tables, RLS, auth, storage, rpc, functions), running the inz CLI, or debugging why a query is denied. instancez is a single-binary Supabase-compatible backend defined by one YAML file.
---
# Building with instancez
instancez turns one file, `instancez.yaml`, into a full backend: Postgres CRUD, auth, storage, SQL RPC, and Node.js functions. Clients talk to it with `@supabase/supabase-js` (or any Supabase client library) unchanged. There are no migration files: on every run the migrator diffs the YAML against the live database and applies the delta, including drops.
## Workflow
If `inz` is not installed: `curl -fsSL https://get.instancez.ai | sh` (macOS/Linux) or `irm https://get.instancez.ai/windows | iex` (PowerShell).
```sh
inz init # scaffold instancez.yaml + .development.env.example
inz validate # check YAML syntax and references, no DB needed
inz dev --embedded-pg # dev server on :8080 with a built-in Postgres 16
```
`instancez.yaml` starts with `# yaml-language-server: $schema=https://docs.instancez.ai/schema/instancez.json`; keep it for editor completion.
Edit `instancez.yaml`, save, and `inz dev` re-applies the schema automatically. Always run `inz validate` after editing the YAML; it catches bad types, bad references, and missing function files without touching a database.
Without `--embedded-pg`, `inz dev` needs `INSTANCEZ_DATABASE_URL` set to a superuser DSN. API keys land in `.development.env` on first run (`INSTANCEZ_PUBLISHABLE_KEY`, `INSTANCEZ_SECRET_KEY`). `inz doctor` diagnoses a dev setup that won't boot. The banner prints the embedded DB URL.
For typed queries, run `inz gen types --out database.types.ts` and pass the result to `createClient<Database>()`. It reads only the YAML; regenerate after schema changes.
Client-side, the app is a normal Supabase app. Point any Supabase client library at the server and the whole surface works: PostgREST-style queries with filters and embeds, auth, storage, RPC, functions.
```js
import { createClient } from '@supabase/supabase-js'
const supabase = createClient('http://localhost:8080', process.env.INSTANCEZ_PUBLISHABLE_KEY)
const { data, error } = await supabase.from('todos').select('*').eq('status', 'pending')
```
The secret key takes the `service_role` path (bypasses RLS); keep it server-side only.
Other commands: `inz serve` (production, no hot reload, dashboard off by default), `inz bundle` (build a tar.gz of config + functions for deploys), `inz cloud deploy` (push to a managed project; `--new` creates one), `inz db reset` (wipe the local DB; `--embedded-pg` for ./pgdata).
## instancez.yaml at a glance
Top-level keys:
```yaml
version: 1