Agents in the Aetherfy dashboard

What the Aetherfy dashboard’s Agents area is

The Agents area of the Aetherfy dashboard, at app.aetherfy.com/dashboard/agents , has three places:

An Aetherfy agent’s configuration lives in its aetherfy.yaml, and the dashboard shows it read-only: memory, runtime, always-on, workspace and schedule change when you edit the file and deploy (see the aetherfy.yaml reference). What the dashboard does change is operational: pausing, archiving, running, rolling back, and the GitHub link.

The Aetherfy agent status badge

Every Aetherfy agent card, and the agent’s record, carries one status badge followed by the words last known. The badge is the status Aetherfy last recorded, not a check made when the page loaded — reading an agent’s live machines would wake a sleeping one and bill it. For a live answer use afy status <agent> or GET /api/v1/agents/{agent}/status.

The dashboard prints a status in capitals, with underscores as spaces (usage_paused reads USAGE PAUSED). The values are the ones the agent API returns:

last known is the literal mark beside the badge; its tooltip reads Last known state from our records, not a live check.

Badges beside the Aetherfy agent status

These appear on an Aetherfy agent card after the status, only when they apply.

While a start is on its way, the pause control on the card withdraws it rather than starting a second one: the latest intent wins, as with afy stop (pausing and resuming).

Notes under the Aetherfy agent badges

The dashboard prints each reason as a sentence, capitalised. The same reasons are resume.reason on the agent (starting while the previous stop is still finishing).

When an Aetherfy agent carries a failure reason, on any status, the card shows the control plane’s sentence for it in a panel under the card, with the afy command that acts on it: afy deploy <agent> when the app, image or machine was lost or every machine is failing its health check (a running agent can carry those last two), and afy restore <agent> once a refused restore’s cause (the plan’s agent limit, the usage limit, a payment, the plan’s settings) is dealt with. The reasons are the agent’s failure_code values, listed at listing and reading agents.

The Aetherfy agent card’s fields

A run’s state reads like a deployment’s (next section): completed for a run that finished, failed for one that did not.

When a scheduled run was blocked by a billing limit, the card shows Scheduled runs are blocked: plan limit reached. until a later run fires.

The Aetherfy agent card’s actions

Each Aetherfy action in the dashboard is a call to the control plane that the CLI and the REST API make too.

Archiving and restoring are explained at Running and managing agents; a restore refused by the plan’s agent limit opens an upgrade prompt rather than an error.

The Aetherfy agent record: deployments

An Aetherfy agent’s record, /dashboard/agents/{name}, opens on its deployments: one row per version, newest first, with VERSION, STATE, REGIONS, CREATED, DEPLOYED and OPERATION. Expanding a row adds its deployment id, image size, queue position, start time, regions ready and — for a failed build — BUILD OUTPUT, the tail of the build log. The page re-reads itself while a deployment is in flight. Below the versions, the record lists the collections the agent was observed reading or writing.

The states are the ones the deployments API returns, printed in capitals with underscores as spaces, the same way as an agent’s status (rolled_back reads ROLLED BACK).

Each is offered only on the versions the API says it can do it for. Both ask for confirmation and both create a new version; see Rollback and Secrets for when to pick which. A rollback or redeploy refused by your plan’s current limits opens an upgrade prompt.

When the agent is archived, a line above both tabs says its app was destroyed, so nothing in the list is serving, and that restoring it is the way back.

The Aetherfy agent record: logs

The LOGS tab of an Aetherfy agent’s record shows its log lines with TIME, LEVEL, STREAM and MESSAGE, filtered by time window, text search, level (INFO, WARN, ERROR, DEBUG, SYSTEM) and stream (stdout, stderr, system). FOLLOW polls for new lines. Opened from the run history, it is scoped to one run. It is the same data as afy logs (logs) and GET /api/v1/agents/{agent}/logs (runs and logs).

The Aetherfy YAML configurator

The configurator at /dashboard/agents/configurator, reached from CONFIGURATOR on the inventory, builds an aetherfy.yaml from a form — name, type, runtime, regions, memory, idle timeout, always-on, spawning, a schedule with a preview of its next runs, workspace and GitHub dependencies — and gives you the text to copy. It registers, deploys and changes nothing; deploy the file with afy deploy. afy init writes a starting file from the terminal (afy init), and Scheduled tasks covers the schedule fields.

When the Aetherfy control plane cannot be reached

If the Aetherfy control plane does not answer, the inventory falls back to what Aetherfy has stored and says so:

Every action is disabled in this state, with the reason beside it: the control plane carries out every action on the page. The agents themselves are not affected.

What the Aetherfy dashboard does not do for agents