Skip to main content

SnoutData Cloud

SnoutData Cloud is hosted Postgres. You create a database from a terminal or from dashboard.snoutdata.com, and you get a postgres:// URL that any client can use: psql, your ORM, the SnoutData desktop app, or a coding agent.

Each project is a Postgres 17 database with pgvector available, reachable at <ref>.db.snoutdata.com over TLS on port 5432. Its data is continuously shipped to object storage, which is the only place it has to exist.

note

SnoutData Cloud is in private testing. The snoutdata CLI itself is published on npm, so npx snoutdata works today with nothing to install.

Sign in

npx snoutdata login

This opens your browser, signs you in with the same account as the desktop app and snoutdata.com, and writes a session to ~/.snoutdata/auth.json (mode 0600).

The session lasts an hour and the CLI refreshes it while you are at the machine. For CI or an agent, use a long-lived access token instead. See access tokens.

Create a database

npx snoutdata init --env

In one command that:

  1. creates a project named after the current folder,
  2. waits until it is actually serving queries, not just until the row exists,
  3. writes .snoutdata/project.json so every later command in this folder knows which project it is about,
  4. writes DATABASE_URL into .env (that is what --env adds).

It is idempotent. A folder that is already linked is used as it is, so running it twice gives you the same project rather than two.

Prefer to name it yourself, or pick a region:

npx snoutdata init --name analytics --region us-west-2 --env

Connect

npx snoutdata db psql # opens psql, with no password typed
npx snoutdata db url # prints the connection string

db psql fetches the project's credentials because you are signed in, and hands psql the password through the child process environment rather than on a command line. You never type a database password into the CLI.

db url prints exactly one line on stdout, so it pipes cleanly:

export DATABASE_URL="$(npx snoutdata db url)"

If the project is paused, connecting to it wakes it. The client waits while that happens. See what pauses, and what it costs.

Look at what you have

npx snoutdata projects list
npx snoutdata usage

usage answers the question people actually have, which is whether they are about to have a problem:

first light (x8x3sb2hcx4xn)
7.7 MB of 8.0 GB on plus (0%).
Over 2 days: 1d 6h of compute, 2 connections.

Run your migrations

Put numbered .sql files in a migrations folder and:

npx snoutdata db push --dry-run # say what would happen, change nothing
npx snoutdata db push

Each file runs once, in name order, and what ran is recorded in a _snoutdata_migrations table in your own database. The ledger row is written in the same transaction as the migration, so a file that fails half way leaves nothing behind.

db push connects to the database like any other client, so it needs psql on the machine.

Access tokens, for CI and agents

A browser session is right for a terminal and useless for a build server. An access token does not expire unless you ask it to, and is revocable:

npx snoutdata tokens create --name ci

The token is printed on stdout, alone, once. Only its hash is stored, so there is no second call that returns it. Put it in SNOUTDATA_ACCESS_TOKEN and every command uses it:

export SNOUTDATA_ACCESS_TOKEN=sdt_...
npx snoutdata init --env

The control plane exchanges an sdt_ token for a short-lived JWT on its side, so row-level security in the database is still the only thing deciding what it can see. Two rules follow from that: a token cannot create another token, and a token can revoke itself or any other.

The dashboard

Everything above is also on dashboard.snoutdata.com: your projects and their state, the connection details with the password behind a reveal, a SQL editor, a table browser, usage, the audit log in plain words, access tokens, and your plan.

The dashboard is not privileged. Every call it makes is the same function the CLI calls, with your own session, and the database decides once.

Next