Know what your node is running

A running container answers one question: did the process start? It does not tell you which image is running, where its data lives, or whether the application is ready. Those distinctions matter when you are debugging a local node.

This note is an inspection checklist for an existing development container. The examples use qrl-node as its name; replace that with your own. It is not an installation recipe.

Start with the image

Inspect both the configured image reference and the immutable image ID. A tag is convenient, but the image ID helps establish what was actually used on this machine.

# The image reference supplied when the container was created
docker inspect qrl-node --format '{{.Config.Image}}'

# The image ID behind this particular container
docker inspect qrl-node --format '{{.Image}}'

Record the source revision, image reference, and any configuration changes alongside your development notes. If you rebuild an image, recreate the container before assuming that it uses the new build.

Make persistence visible

A writable container layer and a mounted data directory have different lifetimes. Inspect the mounts before replacing a container.

docker inspect qrl-node --format '{{json .Mounts}}'
docker logs --tail 100 qrl-node

Check the source, destination, and read/write mode of each mount. Keep secrets out of shared debugging output. Logs and mount paths can contain details that do not belong in a public issue.

A container reporting “running” is not evidence that a blockchain node is synchronised. Check the node’s own status using the documentation for the version you are running.

Leave a useful breadcrumb

A good debugging note is small enough to keep current. Start with the facts you will need to reproduce the issue:

# Example structure for local development notes, not a Compose file
runtime:
  container: qrl-node
  image_reference: "record your image reference here"
  image_id: "record the inspected image ID here"
checks:
  mounts_reviewed: false
  application_status_checked: false

Update those observations as you work. A short record of the environment is usually more useful than a long transcript of commands without context.

Further reading

Use the QRL documentation for version-specific node setup. The theQRL/qrl-docker repository contains Docker build environments; inspect its README before choosing an image or build procedure.