Dashboard API Key vs Git-based Secrets for Credential Isolation

Short answer

Based on the public documentation snapshot reviewed for this draft (mid-2024; verify against the current dashboard), Discloud exposes a single account-level API key and no documented scoped or per-application tokens. That means the dashboard key cannot be made least-privilege by configuration alone. Credential isolation has to come from per-app environment variables, distinct per-app credentials, and keeping the master key out of Git and CI.

What is confirmed vs. what is likely

Claim	Status
One account-level API key, no scope selector	Documented; confirm in dashboard
Environment variables are set per application	Documented; confirm per app
Key persists until manually revoked	Documented
Git-linked auto-deploy does not forward repository secrets into the runtime	Likely, but needs current verification

Why Git-based secrets alone are not isolation

Repository secrets are scoped to the pipeline, not to the running process. An app that reads its configuration from the runtime environment will start with missing values if nothing mirrors those secrets into the platform. Worse, a Git-linked pipeline is editable by anyone with workflow permissions, so placing the account key there expands the blast radius from one app to every app under the account.

Practical pattern for multiple bots

1. Keep the master API key only in the dashboard. Do not paste it into repository secrets unless a pipeline genuinely must call the platform API.
2. Create one application per bot and set unique environment variables per app (Settings → Environment Variables).
3. Use genuinely distinct downstream credentials per app (separate bot tokens, separate database users) so one leak does not unlock the others.
4. Prefer push-based auto-deploy so no account key is needed in CI at all.
5. Plan rotation as an account-wide event: revoking the key affects every app that consumes it.

Safe verification commands

# Confirm a runtime variable exists without printing its value
test -n "$BOT_TOKEN" && echo present || echo missing

# Confirm a local .env file is actually ignored by Git
git check-ignore -v .env

Verification checklist

• Dashboard → Account Settings → API Key: count the keys listed and look for any scope or per-app selector.
• App → Settings → Environment Variables: confirm you can add, edit, and delete variables scoped to that app.
• Trigger a deploy from a Git-linked repository and inspect the build log for whether repository secrets appear; if they do not, mirror them manually as platform variables.

The one detail that changes the recommendation

Does your pipeline need to call the Discloud API to trigger deployments, or is push-to-deploy sufficient? If push-to-deploy is enough, never export the account key and treat the dashboard as the only secret store. If the pipeline must call the API, the key has to live in CI, and that CI becomes an account-admin system: restrict who can edit workflows and audit changes to them.

Uncertainty to resolve before designing around this

Absence from documentation is not proof that scoped tokens do not exist, and platform behavior around Git-linked secret forwarding may have changed. Treat the table row marked for verification as an open item and confirm it in the dashboard and build logs before committing to an architecture.