Getting Started with Cloud

SQLAnvil Cloud runs your project’s CI for you: open a pull request, and it builds your workflow against a throwaway branch of your Supabase project, then reports pass/fail on the PR. You never hand it your database password — it runs on a short-lived, revocable authorization you can pull at any time.

There are two parts: author the project (in your own tools), then set it up in Cloud.

Part A — Author the project

Cloud runs a normal SQLAnvil project from a GitHub repo. If you don’t have one yet:

1. Scaffold a project — a workflow_settings.yaml + a definitions/ folder. Start from the supabase-sqlanvil-starter template, or see the OSS Getting Started.

2. Pin the core version. In workflow_settings.yaml, set warehouse: supabase and pin sqlanvilCoreVersion: to the current release — sqlanvil init writes this for you, and What’s New shows the latest version. Pinning a current version keeps the hosted runner fast (no per-run install).

3. Author + push. Build your models with the CLI, the Claude skill, or the VS Code extension, and push the repo to GitHub.

Part B — Set it up in Cloud

1. Sign in. Go to app.sqlanvil.com → Continue with GitHub. Your GitHub account is your identity — no separate password.

2. Create a project. Give it a name. The setup checklist guides the rest.

3. Connect the repo. Install SQLAnvil on GitHub, grant access to your repository, then pick it from the dropdown and Connect. See Connect a repo.

4. Connect Supabase. In Settings → Supabase warehouse → Connect Supabase, authorize once. If your account has more than one project, pick the warehouse project to branch off — it must be on the Pro plan (branch CI needs Supabase branching). You never register anything or paste a key: SQLAnvil runs the OAuth app; you just click Connect, and we store only a revocable authorization, never your DB credentials. See Connect Supabase.

5. Open a pull request. SQLAnvil mints a scoped, short-lived token, creates an ephemeral branch of your Supabase project, runs your workflow against it, posts a SQLAnvil CI check on the PR, and destroys the branch. Green or red, right on the PR.

6. Debug from the run page. Every run shows each action’s status, timing, the executed SQL, and — on failure — the verbatim error plus Copy failure context (a one-click bundle to paste into an AI agent).

7. Schedule a workflow (optional). On the project’s Schedules page, add a cron schedule with an optional tag selection. See Workflows.

Not on Supabase?

Hosted branch CI targets Supabase today: it relies on Supabase branching, which requires a Supabase project on their Pro plan (a free-tier project can’t run branch CI). For Postgres, BigQuery, or MySQL — or Supabase without branching — run execution in your own CI (e.g. GitHub Actions) and report results to the dashboard with an ingest token — same run history and PR checks, your compute.

What Cloud does and doesn’t do

• Authoring stays in your tools — the CLI and your AI agents. Cloud doesn’t replace your editor.
• Reviewing and operating — run history, run detail, schedules, PR checks — is the dashboard’s job.
• Credentials — we broker, we don’t custody. See Data handling.
• Two things hosted runs reject at compile time, with a clear error before anything is provisioned: local file paths on exports/imports (the runner’s disk is ephemeral — stage on s3:///gs:// instead), and python script actions (user code doesn’t execute on the shared runner — run those projects with the local CLI or your own CI).