The Eurobase CLI lets you manage your projects, database, storage, vault, and more from the command line. Install it via Homebrew or download the Go binary.

Installation

Without Homebrew (CI, agents, Linux servers), download the binary for your platform (macOS or Linux, amd64 or arm64):

Getting started

In CI or scripts, log in with a personal access token instead: eurobase login --token "$EUROBASE_PAT". A project token selects its project automatically and can run the project commands with the access you gave it. A project token can't create or delete projects: do that in the console (or after eurobase login, if your account signs in with a password only, without a passkey or SSO).

Where the CLI keeps your login, and working with several projects

Every command reads one file, $HOME/.eurobase/config.json (mode 600): your token, the active project and the API URL. eurobase login and eurobase switch write it; nothing is kept in the macOS Keychain or any other credential store, and the CLI finds the file only through HOME. There’s no profile option or --project flag yet, so to keep a test project fully apart from production, give it its own directory as HOME for the CLI, and log in there with a token scoped to that project:

Setting HOME per command keeps the rest of your shell unchanged, and the test login stays in ~/.eurobase-test for next time. A project token is refused for every other project, so even a mixed-up configuration can’t reach production. eurobase migrations up reads ./migrations/*.sql from the current directory.

Command reference

Testing RLS policies

Test your policies the way your users actually reach your data: as an authenticated client. Create a few test end-users in a separate project, sign each one in, and exercise the SDK (or REST API) with that user's access token. Row-Level Security is evaluated under the same non-owner role as in production, so what a test user can read or write is exactly what a real client would get.

import { createClient } from '@eurobase/sdk'

const eb = createClient({ url: PROJECT_URL, apiKey: PUBLIC_KEY })

// Sign in as a seeded test user, then read/write under their session.
await eb.auth.signIn({ email: 'alice@example.test', password: '...' })

const { data: mine } = await eb.db.from('tasks').select('*')        // only Alice's rows
const { error } = await eb.db.from('tasks').update(BOB_TASK_ID, { title: 'x' })  // RLS blocks updating Bob's row

// Sign out -> anonymous: a protected table returns nothing.
await eb.auth.signOut()
const { data: anon } = await eb.db.from('tasks').select('*')        // []

Each session carries its identity automatically: the platform sets app.end_user_id and app.end_user_role for the request, which your policies read through auth_uid(), auth_role() and is_service_role(). Confirm what a session resolves to with GET /v1/auth/user using that user's token. The Row-Level Security chapter has the policy patterns and a "Test it from the SDK" walkthrough.