.svg?fit=max&auto=format&n=mBaWmVpTOpDBIB6_&q=85&s=36c7989ebe591de9ac7d3618f0a04a28)
.svg?fit=max&auto=format&n=mBaWmVpTOpDBIB6_&q=85&s=5afe473ba3ef2469d3e839045bcb099c)
meridian dev works: this machine is signed in to your account, and this project is linked to an app.
Signing in
meridian login is a device-code flow. It prints a short code, opens the verification page in your browser, and waits for you to approve.
The token is stored in
~/.meridian/config.json with 0600 permissions. --hostname is what names this machine in your account’s CLI sessions list, so set it when the real hostname is meaningless: a container ID, a shared build box.
meridian logout clears the stored token. meridian whoami shows who you are, which organizations you belong to, and the linked project; add --offline to skip the API call and report only what is stored locally.
A machine stays signed in until its token expires or someone revokes it. Revoking is done from your account, per machine. See CLI sessions. Signing out of the dashboard does not disconnect the CLI, but End all other sessions does.
Linking a project
meridian link picks the organization and app for the current project and writes .meridian/project.json.
Passing
--org and --app makes the command non-interactive, which is what you want in a setup script or a devcontainer.
Commit project.json if your whole team uses Meridian. Each developer still gets their own isolated database, because databases are provisioned per user and app.
Unlinking
meridian unlink removes .meridian/project.json after confirming. It leaves .meridian/snapshots/ and everything else under .meridian/ alone, so unlinking never costs you a pre-migration snapshot.
Running it in a directory that was never linked reports that and changes nothing.