Use the CLI in CI

Use a scoped service/API key for non-interactive deployment. Keep it in the CI platform’s secret store and expose it to only the deployment step that needs it.

Applicability

This page describes the v0.1.10 CLI contract for a self-hosted control plane. It does not establish Cloud token issuance, Cloud account availability, or a managed Cloud deploy path.

Provide the token to the deployment step

After the CLI is installed and the project/release context is prepared, map the CI secret to HYFENS_TOKEN for the hyfens deploy process:

YAML

steps:
  - name: Deploy verified patch
    env:
      HYFENS_TOKEN: ${{ secrets.HYFENS_TOKEN }}
    run: hyfens deploy

This is the released CLI’s environment-variable example, not a complete CI workflow. The command also needs the project and selected self-hosted control-plane scope required for the deployment. Use the provider’s secret masking and least-privilege controls.

Keep secrets out of the build

Do not put token values in hyfens.yaml, profile files, command arguments, logs, artifacts, container images, or source control.
Do not print the environment or enable shell tracing around secret-bearing steps.
Do not use a human browser/device session as a CI credential.
Keep infrastructure SSH credentials separate; SSH is an operator deployment mechanism, not developer authentication for hyfens deploy.
If your CI system cannot mask and scope the value, stop and choose a safer credential mechanism before running deployment.

The v0.1.10 CLI reads HYFENS_TOKEN for the deployment authorization and does not persist it in project configuration. The service token itself is not documented here as a way to obtain an account or a Cloud entitlement.

Verify before promotion

Use the release and patch commands' help from the installed version to check required options. Verify the exact artifact and target before deployment; do not put a live credential into a local example or run this snippet against a production control plane while validating the documentation.