MDK Logo

Run a Bitdeer Worker

Start an MDK Worker for a Bitdeer D40 container.

Overview

This page details how to run the Bitdeer D40 container Worker. Select the development (mock) or real-container path.

The Bitdeer D40 speaks MQTT, and the Worker embeds the broker (one per Worker process) that a container publishes into, rather than the Worker connecting out to the container. Device specs are keyed by containerId, not by an address and port.

Prerequisites

Deployment-specific requirements:

  • A Node.js service or script in your deployment that runs the MDK Worker and registers containers
  • A supported D40 container configured to publish into the Worker's embedded MQTT broker, reachable on that broker's port (default 10883)

Development

Run against a mock

To support development, this repo ships a runnable example that starts the Worker (embedding its MQTT broker), points a mock D40 container at that broker as an MQTT client, starts a Kernel, and registers the container:

node examples/backend/containers/bitdeer/index.js

It prints the Kernel HRPC key and the registered device ID, then stays running until Ctrl+C. For the mock's model and container ID options, see the Bitdeer README.

Connect a container

2.1 Pick your model

Use the Bitdeer README to confirm the model value for your D40 variant: a1346, m30, m56, or s19xp. This guide uses m56, replace it with the value for your container.

2.2 Register your container

Add this code to the Node.js service or script that runs the MDK Worker in your deployment. The snippet shows the minimum boot call seeding one D40 container, replace the example container ID with your container's value:

const { getKernel } = require('@tetherto/mdk')
const { startBitdeerWorker } = require('@tetherto/mdk-worker-bitdeer')

const kernel = await getKernel()

const worker = await startBitdeerWorker({
  workerId: 'bitdeer-rack-1',
  model: 'm56',
  storeDir: './store/bitdeer-rack-1',
  mqttPort: 10883,
  seedDevices: [{
    info: { serialNum: 'D40-M56-001', container: 'container-A' },
    opts: { containerId: 'D40-M56-001' }
  }]
})
await kernel.registerWorker(worker.runtime.getPublicKey())

Make sure the container is configured to publish into this Worker's broker port before registering. Commands act on physical cooling and power hardware, prioritize thermal safety.

seedDevices only seeds a fresh, empty storeDir, once persisted, the device set survives restarts on its own. To add a container to an already-running fleet, send the registerThing command to the live Worker instead:

const { createMdkClient } = require('@tetherto/mdk/backend/core/client')

const client = createMdkClient({ hrpc: { key: kernel.getPublicKey() } })
await client.connect()
await client.sendWorkerCommand('bitdeer-rack-1', null, 'registerThing', {
  id: 'D40-M56-002',
  info: { serialNum: 'D40-M56-002', container: 'container-A' },
  opts: { containerId: 'D40-M56-002' }
})

registerThing persists the container config immediately, but the running Worker does not pick it up until it is stopped and restarted (await worker.stop(), then call startBitdeerWorker again with the same storeDir and no seedDevices), there is no hot-add.

For the full seedDevices and registerThing option reference, the telemetry and command tables, and the shared install pattern, see the Bitdeer README and install pattern.

Troubleshooting

The development example on this page is examples/backend/containers/bitdeer/index.js. A working run prints the Kernel HRPC key and the registered device ID, then stays running until Ctrl+C.

If it does not print those values, or if the broker port is already in use, the network and port checks in miner troubleshooting apply here too, the underlying HRPC and DHT requirements are the same across every Worker.

Next steps

On this page