# DBIS Hyperledger Runtime Status

**Last Reviewed:** 2026-03-28  
**Purpose:** Concise app-level status table for the non-Besu Hyperledger footprint currently hosted on Proxmox. This complements the VMID inventory and discovery runbooks by recording what was actually verified inside the running containers.

## Scope

This document summarizes the latest operator verification for:

- FireFly CTs: `6200`, `6201`
- Fabric CTs: `6000`, `6001`, `6002`
- Indy CTs: `6400`, `6401`, `6402`

The checks were based on:

- `pct status`
- in-container process checks
- in-container listener checks
- FireFly API / Postgres / IPFS checks where applicable

## Current status table

| VMID | Service family | CT status | App-level status | Listening ports / probe | Notes |
|------|----------------|-----------|------------------|--------------------------|-------|
| `6200` | FireFly primary | Running | Healthy minimal local gateway | `5000/tcp` FireFly API, `5432/tcp` Postgres, `5001/tcp` IPFS | `firefly-core` restored on `ghcr.io/hyperledger/firefly:v1.2.0`; `GET /api/v1/status` returned `200`; Postgres `pg_isready` passed; IPFS version probe passed |
| `6201` | FireFly secondary | Stopped | Formally retired until rebuilt | None verified | CT exists in inventory, but the rootfs is effectively empty and no valid FireFly deployment footprint was found. Treat this as retired / standby metadata only until it is intentionally rebuilt as a real secondary node. |
| `6000` | Fabric primary | Stopped | Reserved placeholder | None active | App-native checks found no active Fabric peer/orderer/couchdb processes, no expected listeners such as `7050` / `7051`, and no meaningful Fabric payload under `/opt`, `/etc`, or `/var`. The CT has now been stopped and retained only as a reserved placeholder. |
| `6001` | Fabric secondary | Stopped | Reserved placeholder | None active | Same disposition as `6000`: no proven Fabric application payload or listeners, now stopped and reserved only as placeholder inventory. |
| `6002` | Fabric tertiary | Stopped | Reserved placeholder | None active | Same disposition as `6000`: no proven Fabric application payload or listeners, now stopped and reserved only as placeholder inventory. |
| `6400` | Indy primary | Stopped | Reserved placeholder | None active | App-native checks found no active Indy-related processes, no expected listeners such as `9701`-`9708`, and no meaningful Indy payload under `/opt`, `/etc`, or `/var`. The CT has now been stopped and retained only as a reserved placeholder. |
| `6401` | Indy secondary | Stopped | Reserved placeholder | None active | Same disposition as `6400`: no proven Indy application payload or listeners, now stopped and reserved only as placeholder inventory. |
| `6402` | Indy tertiary | Stopped | Reserved placeholder | None active | Same disposition as `6400`: no proven Indy application payload or listeners, now stopped and reserved only as placeholder inventory. |

## Interpretation

### Confirmed working now

- FireFly primary (`6200`) is restored enough to provide a working local FireFly API backed by Postgres and IPFS.

### Present only as reserved placeholders right now

- Fabric CTs (`6000`-`6002`)
- Indy CTs (`6400`-`6402`)

These should be described as reserved placeholder inventory only, not as active Fabric or Indy application nodes. Current app-native validation found no meaningful service payload, processes, or expected listeners inside those CTs, and they have now been stopped to match that reality.

### Not currently active

- FireFly secondary (`6201`) should be treated as formally retired / standby metadata unless it is intentionally rebuilt and verified.

## Operational follow-up

1. Keep `6200` under observation and preserve its working config/image path.
2. Do not force `6201` online unless its intended role and deployment assets are re-established from scratch.
3. For Fabric and Indy, the next step is no longer generic validation. It is either:
   - deploy real app payloads onto these reserved CTs and verify them, or
   - leave them stopped and classified as reserved placeholders rather than active DLT workloads.
4. Any governance or architecture document should distinguish:
   - `deployed and app-healthy`
   - `container present only`
   - `planned / aspirational`

## Related artifacts

- [docs/02-architecture/DBIS_NODE_ROLE_MATRIX.md](../02-architecture/DBIS_NODE_ROLE_MATRIX.md)
- [docs/03-deployment/PHASE1_DISCOVERY_RUNBOOK.md](PHASE1_DISCOVERY_RUNBOOK.md)
- [docs/03-deployment/DBIS_PHASE3_E2E_PRODUCTION_SIMULATION_RUNBOOK.md](DBIS_PHASE3_E2E_PRODUCTION_SIMULATION_RUNBOOK.md)
- [dbis_chain_138_technical_master_plan.md](../../dbis_chain_138_technical_master_plan.md)