Keys and CI

Everything the eutonomous command and the Python package do, they do with a key. eutonomous login creates one for your computer; the platform’s CLI keys page creates one for a pipeline or a colleague’s script.

What a key carries

Both places ask three things about a key:

• Which environments it may use: all of yours, or a chosen few.
• What it may do.
  • deploy: deploy, roll back, read logs, set variables, run commands.
  • manage: switch public or private, add and remove domains, switch always-on.
  • create: create workspaces, and delete them with their files. It is never ticked for you, and a key limited to chosen environments may also use the ones it creates.
  • With none, it can only list environments.
• How long it is valid: 7, 30, 90 or 365 days. Every key expires, after a year at most.

Deploying and running commands are one permission on purpose: whoever can deploy code can run code.

A key never has more rights than its person. A member who was invited to view an environment cannot deploy to it with any key, and only the environment’s owner can use manage or delete it.

eutonomous whoami shows what the current key may do and when it expires. Creating, approving and revoking a key, and every change made with one, is recorded in the platform’s audit log.

Account keys

A key normally belongs to the person who made it, and stops working when that person leaves the account. For CI and shared automation, make an account key instead: on the CLI keys page, choose The account under Whose key is it?.

• It belongs to the account. It works on the account’s own environments and nowhere else.
• Every administrator of the account can see it and revoke it.
• It keeps working when the person who created it has left.
• It still carries only the permissions and the lifetime you gave it.

Only the account’s owner and its administrators can create one.

Revoking

Revoke a key on the CLI keys page, or run eutonomous logout on the computer that holds it. It stops working at once.

How a key is kept safe

Your key lives in ~/.config/eutonomous/config.toml, readable only by you, and only ever talks to the platform. For each environment the platform hands out a pass that works for that one environment for ten minutes. The environment checks the pass against the platform’s public key and never sees your key.

Deploying from CI

1. On the CLI keys page, create a key limited to the one environment the pipeline deploys to, with the deploy permission only.
2. Store it in the pipeline as the secret EUTONOMOUS_API_KEY.
3. Commit .eutonomous/project.toml (it holds only the environment’s id), or pass --env <id>.

With the key in the environment, eutonomous deploy needs no login and never prompts.

For a repository on Codebahn (Forgejo Actions), save this as .forgejo/workflows/deploy.yml:

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: docker            # your runner's label
    steps:
      - uses: https://code.forgejo.org/actions/checkout@v4
      - name: Deploy
        env:
          EUTONOMOUS_API_KEY: ${{ secrets.EUTONOMOUS_API_KEY }}
        run: |
          curl -LsSf https://astral.sh/uv/install.sh | sh
          ~/.local/bin/uvx eutonomous deploy

A deploy that does not start fails the job and leaves the previous release live.

The key expires like any other. Give it a year and note the date, or the pipeline will start failing with key_expired.