/nubase

name: nubase
description: Use when the user mentions Nubase broadly, wants a backend for an AI-generated app, or needs to deploy/publish generated code online — across Database, Auth, Storage, Assets (static frontend CDN), Functions (edge/serverless), AI Gateway, Memory, cron/scheduled jobs, Supabase-style REST/RLS, service_role keys, or MCP. This is the top-level Nubase skill; use the references folder for capability-specific guidance.

Nubase Core Skill

Nubase turns AI-written code into real apps: the backend **and** deploy layer that a coding agent drives directly to ship a generated app online in minutes.

It provides eight capability modules, each with a stable API and (where useful) MCP tools:

| Module | What it does | Agent entry | | --- | --- | --- | | Database | Postgres + PostgREST data layer (`/rest/v1`) per project, with RLS | `rest_select`, `sql_execute` | | Auth | Supabase-style users, sessions, OAuth/MFA (`/auth/v1`) | `auth_*` | | Storage | Buckets + signed URLs for user files (`/storage/v1`) | `storage_*` | | Assets | Publish the generated **frontend** to a public CDN (`/assets/v1`) | `assets_*` | | Functions | Deploy backend logic as edge functions (`/functions/v1`) | `functions_*` | | AI Gateway | OpenAI/Anthropic-compatible LLM routing + usage (`/v1`) | `gateway_*` | | Memory | Durable agent/user/project context (`/mem/v1`) | `memory_*` | | cron | Schedule recurring jobs (edge fn / db fn) | `cron_*` |

Required First Moves

When starting a Nubase task:

1. Call `nubase_overview()` first. One call returns the whole backend state — capabilities, database schema, storage buckets, auth users, AI Gateway keys, the permission gates that are on/off, and suggested next steps. 2. Call `memory_context({ "task": "<current task>" })` to recall prior decisions. 3. Identify which capability owns the work and read the matching reference (see References below). 4. Prefer stable Nubase APIs and tools over ad hoc scripts. 5. Store durable decisions with `memory_write`.

Deploy Flow (generate → live)

When the goal is to ship a generated app, the path is:

1. **Inspect** — `nubase_overview()`. 2. **Prefer one-call deploy** — when the app has a deploy manifest, call `deploy_app({ manifest })` or use `nubase_cli app deploy nubase.deploy.json`. It orchestrates SQL migrations, Functions, Assets, cron jobs, and optional Memory. 2. **Data + auth** — model tables with `sql_execute` DDL (RLS for user-owned data); manage users with `auth_*`. See `references/database.md`, `references/auth-storage.md`. 3. **Backend logic** — scaffold and deploy edge functions: `functions_new` → write the handler → `functions_deploy` → `functions_invoke` to verify. See `references/functions.md`. 4. **Frontend** — publish the generated HTML/CSS/JS with `assets_upload`; open the returned `publicUrl`. See `references/assets.md`. 5. **Schedule** — wire recurring work with `cron_create` (target a deployed function or a db function). See `references/cron.md`. 6. **AI calls** — route any LLM usage through the gateway (`gateway_*`). See `references/ai-gateway.md`. 7. **Remember** — `memory_write` the durable decisions (schema, deployed functions, published asset paths, cron jobs).

Generated frontend code uses the **anon key** (+ user JWTs); service_role keys stay server-side / in local agent tooling only.

MCP Tools

Expected tools from `nubase_cli`:

Core:

• `nubase_overview` (start here — one-shot backend snapshot)
• `fetch_docs`, `nubase_capabilities`, `nubase_instructions`, `project_keys`, `projects_list`, `project_keys_admin`, `project_select_instructions`, `deploy_app`, `deployment_rollback`
• `memory_context`, `memory_search`, `memory_write`
• `rest_select`, `sql_dry_run`, `sql_execute`

Backend ops (read), in module order (Database, Auth, Storage, AI Gateway): `db_export_schema`, `db_list_migrations`, `auth_list_users`, `auth_get_settings`, `storage_list_buckets`, `storage_list_objects`, `storage_create_signed_url`, `storage_create_signed_urls`, `gateway_list_keys`, `gateway_usage`, `gateway_usage_daily`, `gateway_usage_by_model`, `gateway_usage_logs`, `gateway_pricing`.

Deploy (read), in module order (Assets, Functions, cron, App workers): `assets_list`, `functions_list`, `functions_logs`, `functions_secrets_list`, `cron_list`, `cron_get`, `cron_runs`, `app_workers_list`, `app_worker_status`.

Backend ops (write, gated by `NUBASE_ALLOW_ADMIN_WRITE=true`): `auth_create_user`, `auth_delete_user`, `auth_update_settings`, `auth_clear_settings`, `storage_create_bucket`, `storage_delete_bucket`, `storage_create_signed_upload_url`, `gateway_issue_key`, `gateway_revoke_key`.

Deploy (write, gated by `NUBASE_ALLOW_ADMIN_WRITE=true`): `deploy_app`, `deployment_rollback`, `assets_upload`, `assets_delete`, `assets_update_settings`, `functions_new`, `functions_deploy`, `functions_invoke`, `functions_delete`, `functions_secrets_set`, `cron_create`, `cron_update`, `cron_delete`, `app_worker_delete`.

Project lifecycle (platform auth required with `NUBASE_PLATFORM_JWT` or `NUBASE_PLATFORM_KEY`): `projects_list`, `project_keys_admin`, `project_select_instructions`. `project_provision` and `project_update` are also gated by `NUBASE_ALLOW_ADMIN_WRITE=true`. Project delete is intentionally not exposed.

Before publishing, `deploy_app` and `functions_deploy` scan uploads for obvious secrets such as private keys, `.env` files, service-role-looking JWTs, and common provider API keys. Only bypass with `securityScan: false` or `--no-security-scan` when the user explicitly accepts the risk.

When a gate is off, write tools return `{ success: false, error }` without touching the backend — this is a permission switch, not a missing feature. Ask the user to enable the gate, then retry. If a tool is unavailable entirely, continue with REST/API guidance and tell the user what automation was unavailable.

Setup

Install the Nubase skills and project MCP config:

npx -y nubase_cli@latest install-skills

By d