# pscale CI auth: PLANETSCALE_SERVICE_TOKEN_ID and PLANETSCALE_SERVICE_TOKEN

TL;DR: the CLI reads service-token credentials from the environment when the browser flow is unavailable. Create a service token in the dashboard with the needed grants, store the token id and token as CI secrets under exactly those variable names, and export them before any pscale call. The CLI then authenticates non-interactively.

```text
pscale commands need non-interactive auth in CI
```

## Steps

1. Create a service token in the PlanetScale dashboard with grants for the databases and branches the job touches.

2. Add two CI secrets: one holding the token id, one holding the token value. Name them exactly PLANETSCALE_SERVICE_TOKEN_ID and PLANETSCALE_SERVICE_TOKEN.

3. Export both before the pscale step (or set them as job-level env). Run a read-only command like `pscale database list`. Expected: it lists databases with no login prompt.

4. If auth fails, re-check the names character by character and confirm the secrets are actually injected into the job, not just defined.

## When this applies

- GitHub Actions, GitLab CI, or any runner needing pscale
- scheduled jobs and deploy pipelines
- Docker builds that call pscale

## When it doesn't

- local development — use `pscale auth login` there
- auth failures with the vars already set — check the token grants next
- interactive troubleshooting sessions

## Compatibility

pscale CLI; PLANETSCALE_SERVICE_TOKEN_ID / PLANETSCALE_SERVICE_TOKEN env vars; CI secret stores. Verified against the official PlanetScale CLI docs.

## Variant phrasings

- pscale CI authentication service token
- PLANETSCALE_SERVICE_TOKEN_ID env var
- planetscale github actions auth

## Root cause

The CLI checks these two env vars before attempting interactive login, so a correctly named pair silently converts every pscale invocation into an authenticated one. A single typo in either name drops back to the browser flow, which is why the names must be exact.

## Edge cases

- mark both as secret/masked; build logs must never show the token value
- scope the token to the branches the pipeline needs, not the whole org
- service tokens do not expire on password change, which is why they suit CI