Connect a device

Authoring and building need no connection at all. To sign, install or list Packages, the CLI has to act on your behalf in an Organization. You grant that once per machine through a device approval: the CLI shows a short code, and you approve it in your browser while signed in to Elizon.

You never paste an API key into the terminal, so none ends up in shell history, CI logs or screenshots. Approval works from any device, including a phone, so it also suits a headless server, an SSH session or a container.

Connect

Run target add with the address you use to reach Elizon:

npx @elizon/cli target add acme.elizon.example

The easiest way to get the exact command is Studio → Settings → CLI Devices, which shows it with your Organization's address filled in and a Copy button.

The CLI prints a link and a code, then waits:

  To authorise this device, open:  https://acme.elizon.example/studio/device?user_code=WXYZ-2345
  and enter the code:              WXYZ-2345
  The code expires in 10 minutes. Waiting…

Open the link

Open the link on any device. If you aren't signed in, Elizon asks you to sign in first. The link fills in the code for you; if you open the bare address instead, type the code into the Connect a device page.

Check what's asking

The page shows which device is asking (by default elizon CLI on <user>@<machine>), when the request was made and when it expires, plus what approving grants: permission for this device to act on your behalf in the Organization you choose, installing, signing and listing Packages through the Elizon CLI.

Check the Organization. The page names the Organization the device will be connected to. If you belong to more than one, choose it from the list. It starts on the Organization the CLI asked for with --org, otherwise the one this browser tab is in. See Choosing the Organization.

Make sure the code on the page matches the code in your terminal. If you didn't start this request, choose Deny.

Approve

Choose Approve. The page confirms Device connected to your Organization, and within a few seconds the terminal shows:

Authenticated to https://acme.elizon.example as dev@acme.example
  target:       acme.elizon.example (default)
  organization: Acme GmbH (0f0b1c2d-…)
  expires:      2026-10-25T09:14:03.000Z
  credential:   /home/dev/.config/elizon/targets.json (outside this project, mode 0600)
  reference:    .elizon/config.yaml (name and host only — no credential)

The device acts as you, in the Organization you were signed in to when you approved it, with your role's permissions. To use a different Organization, sign in to that one and connect again under another name.

Address formats

You type	The CLI connects to
`acme.elizon.example`	`https://acme.elizon.example`
`acme.internal:8443`	`https://acme.internal:8443`
`https://acme.internal`	`https://acme.internal`
`http://localhost:3001`	`http://localhost:3001`

HTTPS is assumed unless you spell out a scheme. The CLI talks only to the address you give it. It never contacts any other Elizon-operated service, which is what lets it work with self-hosted and private deployments.

Options

Option	Effect
`--name=<name>`	What to call this target in later commands (`--target=<name>`). Defaults to the host.
`--default`	Make this the target used when a command gets no `--target`.
`--json`	Print one JSON document instead of the summary.

The first target you add becomes the default automatically.

npx @elizon/cli target add acme.internal:8443 --name=acme --default

Where the credential is stored

The token is written to a file in your user configuration directory, never inside a project:

Platform	Location
Linux / macOS	`$XDG_CONFIG_HOME/elizon/targets.json`, else `~/.config/elizon/targets.json`
Windows	`%APPDATA%\elizon\targets.json`

The file is readable only by you (mode 0600, in a 0700 directory). ELIZON_CONFIG_HOME, if set, is used as the directory that holds targets.json instead. If any of these would resolve inside the current project (a common CI mistake), the CLI refuses with CLI_TARGET_STORE_UNSAFE before sending anyone to a browser, so a token can't end up one git add away from a commit.

When you run target add inside a Package project, the project's .elizon/config.yaml also gets a reference (a name and a host, nothing secret), so teammates can see which Organizations the project is meant for:

targets:
  - name: acme
    host: https://acme.internal:8443

See what this machine is connected to

npx @elizon/cli target ls

Targets (credentials in /home/dev/.config/elizon/targets.json):
  acme                        https://acme.internal:8443        dev@acme.example  [default, active]

target ls works offline and never prints token material. It flags a token that has already expired, and warns about targets the current project references but this machine hasn't connected to.

Expiry and revocation

A device token lasts 30 days. After that, commands fail with CLI_TARGET_TOKEN_REJECTED. Run target add again to reconnect.
Revoke a device at any time in Studio → Settings → CLI Devices. Revocation takes effect on the device's next call, not when its token would have expired.
A code that nobody approves within 10 minutes expires (CLI_TARGET_APPROVAL_EXPIRED). A denied request fails with CLI_TARGET_APPROVAL_DENIED. In both cases nothing is stored.

Not the same as a Package credential

The device token is the CLI's own credential for talking to your Organization. It's unrelated to the credentials a Package needs to reach third-party services (a calendar, a ledger, a speech provider). Those live in your Organization's Secrets vault and are never handled by the CLI.

For the same reason, target add refuses --token, --api-key, --password and similar flags, refuses credentials embedded in the address (https://user:pass@…), and reads nothing from stdin.

Connect a device

On this page