Using the CLI in CI/CD

The Loha CLI authenticates with a bearer token. On your laptop that's usually your personal access token. In an automated pipeline there's no person to log in, so use a service account key instead. It's owned by the workspace, scoped to exactly what the job needs, and doesn't break when someone leaves the team.

The CLI reads its token from the LOHA_TOKEN environment variable. When that's set, it runs with no loha login and no config file, exactly what a build agent needs.

1. Create the credential

1. In the dashboard, go to Workspace → Settings → Service accounts and create one (e.g. ci-deploy-bot) with the role the job needs.
2. Mint a key with just the scopes the commands you'll run require (see the table below). Leave the expiry blank for a long-lived CI credential, or set one and rotate.
3. Copy the key: it's shown once.

CLI command	Scope the key needs
loha validate	pipelines:read
loha repos / repos discover	repos:read
loha repos add	repos:write
loha connections list / add	connections:read / connections:write
loha builds / build get / logs	builds:read
loha cancel	builds:write
loha deploy	triggers:run (+ pipelines:read when resolving via --repo)
loha releases	repos:read

2a. From an external CI (GitHub Actions, GitLab CI, …)

Store the key as a secret in that system and expose it as LOHA_TOKEN, and set LOHA_API_URL to https://app.loha.longtumlab.com. The CLI's built-in default endpoint is not this environment, so always set it.

# GitHub Actions
- name: Deploy via Loha
  env:
    LOHA_TOKEN: ${{ secrets.LOHA_TOKEN }}
    LOHA_API_URL: https://app.loha.longtumlab.com
  run: |
    curl -fsSL https://s3th-api-a.inet.co.th/nopadolsooktiebqli1:loha-cli/install.sh | sh
    loha deploy --repo <repository-id>

2b. From inside a Loha build step

Store the key as a workspace secret (see Variables and secrets) named LOHA_TOKEN, then reference it from the step that runs the CLI. Secrets are injected per-step only when named:

jobs:
  release:
    steps:
      - name: Trigger downstream deploy
        env:
          LOHA_API_URL: https://app.loha.longtumlab.com
        run: |
          curl -fsSL https://s3th-api-a.inet.co.th/nopadolsooktiebqli1:loha-cli/install.sh | sh
          loha deploy --repo <repository-id>
        secrets:
          - LOHA_TOKEN

LOHA_API_URL is a plain step env: value, not a secret. Keep it: the CLI's built-in default endpoint is not this environment.

Verify

loha whoami confirms the credential and shows that you're authenticated as a service account:

$ LOHA_TOKEN=loha_… loha whoami
Workspace: Acme (acme)
Identity:  service account (ci-deploy-bot)
Token:     production deploys (loha_abc…)
Scopes:    pipelines:read, triggers:run

Driving builds from a script or agent

For unattended callers, two flags make the CLI safe to automate:

• --watch (on deploy and build get) blocks until the build reaches a terminal status and exits non-zero if it ends FAILED/CANCELLED/TIMEOUT. A CI step or agent can branch on the exit code without parsing output.
• --json (on the read commands) emits a stable, parseable shape instead of the human table.

# Ship and gate the pipeline on the result — non-zero exit fails the job.
loha deploy --repo <repository-id> --watch

# Inspect or stream a build programmatically.
loha build get <build-id> --json
loha logs <build-id> --follow
loha builds --status FAILED --json | jq '.[].id'

Rotating and revoking

• Rotate: mint a new key, update LOHA_TOKEN in your secret store, then revoke the old key.
• Compromise: revoke the single key, or disable the whole service account to kill all of its keys at once. Either takes effect immediately: the next request returns 403.

Every CLI action a service account takes is attributed to it by name in the audit log.