# Console & observability

Explore the embedded console and persistent metrics.

Canonical URL: https://getyano.dev/operate/console/

The Yano distribution embeds the unified console. Start Yano and open
`http://127.0.0.1:7070/ui/`. The node, app-chain, plugin, and observability
routes are real static paths, so `/ui/status/`, `/ui/app-chain/`,
`/ui/plugins/`, and `/ui/observability/` can be bookmarked directly.

The connection panel accepts a Yano API base and an optional API key. Keys
remain in memory unless the operator explicitly opts into browser-local
persistence. The plugin operations route is stricter: it ignores `?api=` and
saved base overrides, trusts only `/ui/plugins/api-prefix.json`, and retains
its privileged key in the current tab's `sessionStorage`.

## Standalone hosting

Use the embedded console in your installed release where available. A separately hosted console is an advanced deployment; see [the source-build page](/contribute/build-from-source/#standalone-console-artifact) to produce its ZIP and extract it below `/ui` on a static server. The archive has no Node.js runtime and
contains no credentials. For the plugin page, route `/api/v1` to the Yano node
on the same origin (the archive's fixed plugin discovery document intentionally
does not accept a query-controlled remote base).

For the other console routes, a cross-origin node can be selected from the
connection panel. CORS is disabled in Yano by default. Enable it only for the
exact console origin, for example:

```yaml
quarkus:
  http:
    cors:
      enabled: true
      origins: https://console.example.com
      methods: GET,POST,OPTIONS
      headers: Accept,Content-Type,X-API-Key
```

The equivalent environment settings are
`YANO_HTTP_CORS_ENABLED=true`,
`QUARKUS_HTTP_CORS_ORIGINS=https://console.example.com`,
`QUARKUS_HTTP_CORS_METHODS=GET,POST,OPTIONS`, and
`QUARKUS_HTTP_CORS_HEADERS=Accept,Content-Type,X-API-Key`.

Never configure `origins: "*"` when API keys are used. CORS controls which
browsers may call the node; it does not replace or weaken Yano's API-key
checks. The fetch-based app-chain stream uses the same CORS and `X-API-Key`
rules as normal JSON requests.

## Historical metrics

Without extra services, the node and app-chain charts retain up to one hour
of bounded history in the current browser tab. This short history survives a
refresh but is not a monitoring database.

For persistent local history, the JVM and native distributions include a
pinned Prometheus companion:

```bash
./yano.sh observability start
./yano.sh observability status
./yano.sh observability stop
./yano.sh observability clean --yes
```

`start` discovers a running maintained local app-chain cluster, or defaults
to `http://127.0.0.1:7070`. Repeat `--target <node-origin>` to replace
discovery. It prints a preconfigured `/ui/observability/?metrics=...` link.
The default retention is 15 days / 2 GB; `stop` preserves history and only
the explicit `clean --yes` command removes the marked state and labeled
volume. Docker Compose v2 is required only for this optional mode.

Production operators can set an existing Prometheus-compatible origin in the
Connection panel. The console issues only its built-in read-only queries.
Configure exact-origin CORS and access control on that endpoint. Its optional
bearer credential is retained only in the current tab, is bound to the exact
metrics origin, is never stored with or substituted for the Yano API key, and
is never sent to the node.

## Capability panels

The App chains page discovers optional capabilities from the selected chain's
status and, when authorized, confirms first-party bundles against the plugin
catalog. It does not assume that every deployment has effects or role-aware
approvals.

- An effects-enabled chain shows emitted effects, statistics, composed proofs,
  and confirmed requeue/cancel actions. Mutations require the appropriate
  operator API key.
- A `role-approvals` or `role-evidence` chain queries the proposal through the
  root-fixed committed-query surface and adds the decoded domain projection
  when available. The committed result remains visible if that convenience
  projection is unavailable.
- Every running app chain exposes **Operations**, **Capabilities**, and
  **Proofs**. Proofs is divided into **Message**, **State**, **Import and
  verify**, and **Advanced** workflows. The browser can SHA-256 the exact
  finalized message payload or
  included proof value and compare each with its own optional expected digest.
  A proof can be loaded at the current tip, loaded at the exact height of the
  latest anchor confirmed by this node, or pasted as JSON. **Verify proof**
  sends only the bounded key/value/proof/root fields to the connected node's
  release-matched MPF verifier and reports three facts independently:

  - whether the MPF path is mathematically valid for the expected root;
  - whether the proof envelope's root and optional height match that source;
  - where the expected root came from.

The State workflow discovers typed proof subjects from the chain's immutable
capability manifest and keeps physical state keys in Advanced. For
extension-specific trust labels and proof workflows, see the
[Yano X Proof Lab guide](https://github.com/bloxbean/yano-x/blob/main/docs/appchain/PROOF_LAB.md).

`L1-confirmed by this node` means Yano observed the anchor transaction and
bound its persisted confirmation back to the exact finalized app block. It is
not an independent Cardano lookup. For an audit decision, resolve the shown
transaction through an independent Cardano source, validate the metadata or
script datum/output, and pin the expected chain, membership, threshold, and
script identity. The browser digest remains a byte-integrity check rather than
finality, anchor, or MPF verification. Custom component-specific panels remain
data-only future catalog work; plugins cannot inject executable console code.

### EUTxO lifecycle

An `eutxo-ledger` chain exposes a reviewed EUTxO route at
`/ui/app-chain/eutxo/?chain=<chain-id>`. With the node-local
`indexer:eutxo-lifecycle` capability, it provides bounded transaction,
account, bridge, lineage, and optional validity views. A user can start from
an address, L1 deposit outpoint, app-message ID, L2 transaction ID, or
withdrawal claim and follow the canonical L1 deposit to L2 activity to L1
payout.

The indexer is a derived SQLite projection. The console displays its coverage,
checkpoint, finalized height, lag, and bridge-reconciliation diagnostics.
If it is disabled or unavailable, the page falls back to the committed
transaction-summary API; consensus and bridge execution are unaffected.
L1 transaction details are loaded lazily from the connected Yano node and
remain optional when retained L1 history is unavailable. The browser does not
decode arbitrary Cardano or proof CBOR and never reads the disposable demo
journal.

The Bridge tab's server-built CIP-30 deposit may select a wallet input that
contains ADA plus native assets. The vault output remains ADA-only and every
native asset is returned to the depositor as change; signing and submission
remain wallet-owned.

Operational configuration, endpoints, metrics, rebuild safety, and the
measured SQLite support envelope are documented in the
[Yano X EUTxO indexer runbook](https://github.com/bloxbean/yano-x/blob/main/ledgers/eutxo/INDEXER_OPERATIONS.md).

For local frontend development, run `npm run dev` in
`console-ui/frontend`; Vite proxies `/api` and `/q` to
`http://127.0.0.1:7070`.