# SnoutData Cloud **SnoutData Cloud is hosted Postgres.** You create a database from a terminal or from [dashboard.snoutdata.com](https://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 `.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 ```bash 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](#access-tokens-for-ci-and-agents). ## Create a database ```bash 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: ```bash npx snoutdata init --name analytics --region us-west-2 --env ``` ## Connect ```bash 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: ```bash 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](https://docs.snoutdata.com/cloud/limits#pausing-and-waking). ## Look at what you have ```bash 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: ```bash 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: ```bash 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: ```bash 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](https://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 - [CLI reference](https://docs.snoutdata.com/cloud/cli), for every command and flag. - [Limits and what is not built](https://docs.snoutdata.com/cloud/limits), for what pauses, what a plan actually gets, and what we do not protect against. - [For an agent](https://docs.snoutdata.com/cloud/agent), the whole CLI on one page, written to be read by a model.