View Markdown

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

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

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:

dina auth status --output json

Signing out

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, don’t share this file — every user should sign in separately. For CI runners, use keyless federated login instead of copying credentials around (see below).

Signing in from CI

You don’t need an interactive browser flow in a pipeline. There are two ways to authenticate a CI job.

Keyless login with --federated (recommended)

On CI systems that issue OIDC tokens, the CLI can exchange the job’s identity for a short-lived Dina session — no secrets to store:

dina auth login --federated

GitHub Actions, Forgejo Actions, and Gitea Actions are detected automatically. On those platforms, grant the job permission to request an identity token:

permissions:
  id-token: write

The token is scoped to that single job and expires quickly, so there’s nothing long-lived to leak. For other CI systems, provide the OIDC token yourself with --oidc-token, --oidc-token-file, or the DINA_OIDC_TOKEN environment variable. Use --audience if your setup needs a specific audience claim.

Static token with DINA_API_TOKEN

If your CI can’t produce an OIDC token, set a token in the environment and the CLI uses it directly, skipping the stored-credentials file entirely:

export DINA_API_TOKEN=...
dina apps list

This bypasses interactive sign-in and never writes anything to disk. Federated login is preferable where it’s available, since it avoids a long-lived secret.

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. You don’t need to be signed in to do that.