Quickstart

Install the CLI and sign in

Install the CLI:

curl -fsSL https://get.nevia.cloud | sh

If the install directory isn't on your PATH, the installer prints the export command to run and the shell file to add it to. Then check that the CLI runs:

nevia --version

This prints the CLI version.

The installer supports macOS 11 or later and Linux kernel 4.18 or later, on ARM64 and x86-64. It needs curl, tar with gzip support, mktemp, and either sha256sum or shasum. It verifies the download before replacing an existing installation, so run the same command again to upgrade. You can also run nevia update to upgrade in place, or nevia update --dry-run to only compare versions. nevia update explains when the CLI asks to update itself.

To pin a version or choose another install directory, pass variables to sh:

curl -fsSL https://get.nevia.cloud | NEVIA_VERSION=0.1.7 sh
curl -fsSL https://get.nevia.cloud | NEVIA_INSTALL_DIR="$HOME/bin" sh

Then sign in. nevia login opens your browser and stores the credential in your config directory. The browser ends on the console, already signed in. nevia whoami shows who you are and lists your workspaces with your role in each:

nevia login
nevia whoami

If you belonged to no workspace, Nevia created one named default. While it is your only workspace, commands use it and you can skip to the next step. Otherwise, pick a workspace from whoami where you have the admin or editor role. Copy its full ID and replace 01d4cnjjq40hnnh0nwmkg35nv2h below with it:

nevia workspace use 01d4cnjjq40hnnh0nwmkg35nv2h
nevia workspace current

Use the ID even if the workspace is named default, because creation and workspace management commands require it. nevia workspace current should print the ID you selected. If it prints something else, see Select a workspace for overrides. To create another workspace, see Create a workspace and manage access.

Create a database

Version, size and storage take platform defaults, so the command needs only a name. Use a workspace where orders and orders-staging are free.

nevia pg create orders

Check that the database is ready:

nevia pg ls

orders should be ready, with no pending transition. If creation is still running, run the command again or track the operation before connecting.

Get the connection details and password:

nevia pg connect orders

nevia pg connect orders prints the connection details and reads the password back from the machine when you need it. Add --uri to print only the postgres:// URI for psql and scripts. The URI reaches the database directly, with no tunnel in between.

Keep the URI's sslmode=require or stricter setting, because routing requires TLS. A ready state does not prove your client can connect. The first query below does. If the endpoint is unreachable or reports that SSL is unavailable, see Create and connect to a database.

Set up a schema and some data

Pipe a schema and some rows into the database. This heredoc creates a table, inserts four rows and counts them:

psql "$(nevia pg connect orders --uri)" <<'SQL'
CREATE TABLE IF NOT EXISTS pings (id serial PRIMARY KEY, note text);
INSERT INTO pings (note) VALUES
  ('csv-note-one'), ('csv-note-two'), ('baseline-a'), ('baseline-b');
SELECT count(*) FROM pings;
SQL

The count is 4.

Branch the database

Branching copies the parent's current data into a new database with its own connection string. The source must be ready, with no pending transition or running operation, and must have a persistent data disk supplied by the deployment.

nevia pg branch orders -b orders-staging
nevia pg status orders-staging

Wait until orders-staging is ready, with no pending transition, before running the SQL below. If it is still starting, check its status again.

The parent keeps running, and the branch records the ID of orders as its parent. The branch uses the same credentials, which pg connect reads from its machine, and starts with the same four rows. These statements change the branch only:

psql "$(nevia pg connect orders-staging --uri)" <<'SQL'
INSERT INTO pings (note) VALUES ('branch-mutation');
UPDATE pings SET note = 'baseline-a (edited in branch)' WHERE note = 'baseline-a';
SQL

psql prints INSERT 0 1 and UPDATE 1.

Check the divergence

Run the same query against both databases:

for db in orders orders-staging; do
  psql "$(nevia pg connect "$db" --uri)" -c \
    "SELECT count(*), array_agg(note ORDER BY id) FROM pings;"
done

The parent still has 4 rows. The branch has 5: the new branch-mutation row, and baseline-a rewritten to baseline-a (edited in branch). Your edits changed a full copy, and the original is untouched.