# Sign in

Almost every CLI command talks to the Dina platform on your behalf, so the CLI needs to know who you are. Signing in is a one-time step per machine.

## Signing in

```sh
dina auth login
```

What happens:

1. The CLI contacts the Dina platform to discover the login server.
2. If a browser is available, it opens a login page and waits for you to approve the connection.
3. If no browser is available (you're on a headless server or over SSH), the CLI prints a short code and a URL you can visit from any other device.

Once approved, the CLI prints the expiry time of your new session. You're ready to run any other command.

## Checking whether you're signed in

```sh
dina auth status
```

You'll see one of two things:

- **Authenticated** — the CLI tells you when the current token expires and which API it's pointed at.
- **Not authenticated** — the CLI tells you to run `dina auth login`.

For scripts, pass `--output json` to get a machine-readable payload:

```sh
dina auth status --output json
```

## Signing out

```sh
dina auth logout
```

This deletes the saved credentials. You can sign back in with `dina auth login` whenever you're ready.

## Where credentials are stored

The CLI stores a single file at:

```
~/.config/dina/auth.json
```

On Windows, that resolves to `%USERPROFILE%\.config\dina\auth.json` (typically `C:\Users\<you>\.config\dina\auth.json`). You can override the location on any platform by setting `XDG_CONFIG_HOME`.

The file is readable only by your user account. If you're setting up a shared machine or CI runner, don't share this file — every user or runner should sign in separately.

<div class="callout"><strong>Note:</strong> The CLI does not support API tokens today. Every machine that runs Dina commands needs its own interactive sign-in. Support for machine accounts is planned.</div>

## Do I always need to sign in?

A few commands work without authentication:

- `dina version`, `dina update`, `dina doctor`, `dina install` — these only touch your local machine.
- `dina feedback bug` — so you can report problems even when sign-in itself is broken.

Everything else (deploying, managing apps, reading logs, adding domains) requires you to be signed in first.

## Troubleshooting

**"Not authenticated" even after signing in.** Run `dina doctor`. It checks for expired tokens and missing credential files, and tells you what to do.

**Login tab didn't open.** Try running the command again with `--debug` to see where it's stuck, or check whether your terminal session is able to launch a browser. On a headless machine, the CLI should fall back to the device code flow automatically — copy the URL it prints and open it somewhere else.

**Still stuck?** [Send a bug report](/docs/feedback). You don't need to be signed in to do that.