edgible device

List and manage devices in your organization

edgible device create

Aliases: new

Create a new device in your organization and print its one-time password

edgible device create <name> [flags]

Flag	Description
--type <type>	Device type: serving (default)
-d, --description <description>	Device description

Examples

edgible device create my-laptop
edgible device create syd-gateway --type gateway
edgible device create ci-runner --description "build box" --json

The password is printed ONCE and cannot be retrieved later — it is the secret edgible agent enroll consumes, so capture it now:

$ PASSWORD=$(edgible device create ci-runner --json | jq -r .password)

Creating the device row is only the first half of onboarding; run edgible agent install (or agent provision + agent enroll) on the device itself to attach an agent to it.

edgible device list

Aliases: ls

List all devices in the organization

edgible device list [flags]

Flag	Description
--type <type>	Filter by type

Examples

edgible device list
edgible device list --type gateway
edgible device list --json | jq -r '.[] | select(.status != "online") | .name'

The status column is a tri-state read at request time: online (WebSocket heartbeat fresh), ws-degraded (heartbeat stale but the agent’s API still answers) and offline. A stored status that is not a liveness verdict (pending, suspended) is shown verbatim rather than guessed at.

Agent version marks an update when a newer release is published for the device’s build channel — apply it with edgible device update.

edgible device delete

Aliases: rm

Delete a device

edgible device delete [flags]

Flag	Description
--device <id-or-name>	Device to delete, by id or name
-y, --yes	Never prompt — for a selection or a confirmation; fail instead

Examples

edgible device delete --device my-laptop
edgible device delete --device my-laptop --yes
edgible device delete            # pick from a list, then confirm

--yes covers both questions this verb can ask: which device, and are you sure. In CI, pass the device explicitly as well — with nothing to select from and nothing to confirm, the command either deletes or fails, and never waits.

Deleting a device does not delete the applications deployed to it; check edgible application list first if the device was serving traffic.

edgible device health

Check device health (CPU, memory, disk, uptime) via a diagnostics job

edgible device health [flags]

Flag	Description
--device <id-or-name>	Device to act on, by id or name
-y, --yes	Never prompt — for a selection or a confirmation; fail instead

Examples

edgible device health --device my-laptop
edgible device health --device my-laptop --yes && ./deploy.sh
edgible device health --device my-laptop --json | jq -r .metrics.disk.verdict

Verdict and exit code

• 0 — ok, or a warning (CPU/memory >= 90%, disk >= 85%)

• 5 — failed - CPU >= 98%, memory >= 97% or disk >= 95%

• 1 — inconclusive - the agent reported a value that is not a 0-100 percentage

The verdict is the exit status, so the command works as a gate. Under --json the same verdict travels with the numbers, on the document and on each metric, so a reading of cpuUsage: 10558 cannot be mistaken for a measurement.

edgible device diagnostics

Aliases: diag

Collect a full comprehensive diagnostics report (metrics, services, network, logs) for a device

edgible device diagnostics [flags]

Flag	Description
--full	Collect up to 4 MB instead of the 300 KB default; the device uploads a report that large rather than truncating it
--device <id-or-name>	Device to act on, by id or name
-y, --yes	Never prompt — for a selection or a confirmation; fail instead

Examples

edgible device diagnostics --device my-laptop
edgible device diagnostics --device my-laptop --full
edgible device diagnostics --device my-laptop --json > report.json

Every category the agent can collect (metrics, services, network, WireGuard, Caddy, logs) in one report — the same one the gateway paths print. The device must be online: this dispatches a job and waits for it.

Without --full the report is capped at 300 KB and the oldest log lines are dropped to fit; --full raises the cap to 4 MB, which the device satisfies by uploading the report rather than posting it inline.

edgible device logs

Show the device’s edgible-agent logs, collected on demand over the diagnostics channel

edgible device logs [flags]

Flag	Description
--priority <level>	Minimum journald priority: debug, info, warning, err (default: info)
--since <time>	Only lines at/after this time (ISO-8601 or epoch-ms)
--limit <number>	Maximum number of lines to return
--device <id-or-name>	Device to act on, by id or name
-y, --yes	Never prompt — for a selection or a confirmation; fail instead

Examples

edgible device logs --device my-laptop
edgible device logs --device my-laptop --priority warning --limit 200
edgible device logs --device my-laptop --since 2026-07-06T12:00:00Z --json

Agent logs are the edgible-agent daemon’s own journal (not per-app workload output — use edgible application logs for that) and require organization owner access. The journal lines are the only thing on stdout, so edgible device logs --device my-laptop | grep -i panic sees log lines and nothing else.

edgible device application-health

Aliases: app-health

Check application health (workload status, deployment) for applications running on a device

edgible device application-health [flags]

Flag	Description
--device <id-or-name>	Device to act on, by id or name
-y, --yes	Never prompt — for a selection or a confirmation; fail instead

Examples

edgible device application-health --device my-laptop
edgible device application-health --device my-laptop --json

Per-application health AS THE DEVICE SEES IT — the agent’s own probe of each workload it runs, plus the container state and the deployment state. That is a different question from edgible application list, which reports what the control plane believes; when the two disagree, this one is the device’s answer.

edgible device repair

Idempotently (re)provision the device’s ingest application

edgible device repair [flags]

Flag	Description
--device <id-or-name>	Device to act on, by id or name
-y, --yes	Never prompt — for a selection or a confirmation; fail instead

Examples

edgible device repair --device my-laptop
edgible device repair --device my-laptop --json

Recreates, adopts, or creates the device’s ingest application as needed; it is a no-op when the app is already healthy. Gateway and cloud devices have no ingest app to repair. If no healthy managed gateway exists, gateway assignment is deferred and attaches on the next repair or storage push, once one is available.

edgible device update

Update the device’s agent to the latest published release (latest-only)

edgible device update [flags]

Flag	Description
--wait	Wait for the agent to apply the update and report a result
--device <id-or-name>	Device to act on, by id or name
-y, --yes	Never prompt — for a selection or a confirmation; fail instead

Examples

edgible device update --device my-laptop
edgible device update --device my-laptop --wait
edgible device update --device my-laptop --wait --json

Updates are latest-only by design — the agent is moved to the newest published release for its build channel (no version selection). Without --wait the update is queued and the agent applies it on its own (a brief restart); the new version re-reports on reconnect (see edgible device list). With --wait the command follows the job to its terminal result. Edgible-managed devices are updated by platform operations, and a version pinned by operations cannot be moved.

edgible device plugins

List the plugins a device reports (name, version, description)

edgible device plugins <deviceId> [flags]

Examples

edgible device plugins my-laptop
edgible device plugins <deviceId> --json

The positional takes an id or a name, the same as --device elsewhere in this group. Reads the plugin manifest off the device row — the same list the platform checks a plugin job against — so the device need not be online. Plugins are installed on the device by its operator; the platform never ships plugin code. An empty list is explained: never reported, an agent predating plugin support, or a plugin-capable agent with nothing installed.

edgible device run-plugin

Run an operator-installed plugin on a device and print its JSON result

edgible device run-plugin <deviceId> <pluginName> [flags]

Flag	Description
--params <json>	Parameters for the plugin, as a JSON object (default: {})
--timeout <s>	Job timeout in seconds (default: the plugin job type’s 120s)

Examples

edgible device run-plugin my-laptop disk-audit
edgible device run-plugin my-laptop disk-audit --params '{"path":"/var/log"}'
edgible device run-plugin my-laptop disk-audit --timeout 300 --json

The first positional takes an id or a name, the same as --device elsewhere in this group. --params is an opaque bag handed to the plugin as JSON on stdin; the plugin owns its own parameter contract (see edgible device plugins). It is validated as a JSON object locally before anything is dispatched. The command polls the job to its terminal status; a result too large to store inline is uploaded by the device and downloaded here (byte- and digest-verified) so both cases print the same thing. A plugin the device does not report is refused, naming what it does.