This guide takes you from a fresh machine to a running DamageBDD node.

By the end, you should have:

• Docker installed on Windows, macOS, or Linux
• the DamageBDD Docker stack running
• the web interface open locally
• an optional Tor onion address for private public access
• a node/account address copied from the web UI
• a first smoke test executed
• the basic operator path understood

The verified DamageBDD stack is not just a web app. It is a behaviour verification node with supporting infrastructure:

• DamageBDD web/API runner
• IPFS report storage
• Aeternity middleware/node for verification paths
• Bitcoin Core
• Core Lightning
• optional Tor onion service for exposing the web UI without exposing your home IP

DamageBDD exposes execution routes such as /version/, /tx/, and /execute_feature/, and the feature execution path writes reports that can be published through IPFS.

A DamageBDD node gives users a place to submit behaviour tests.

In plain English:

1. A user opens your node.
2. The user submits a Gherkin feature file.
3. DamageBDD runs the behaviour test.
4. A report is produced.
5. The report is stored/published through the stack.
6. Eligible verified execution can earn DAMAGE.

Careful wording matters: running a node creates execution capacity. Rewards, payments, and token flows depend on configuration, demand, network state, pricing, eligibility, and review rules. This is not an investment promise and not a guarantee of profit.

Docker Compose is the command that brings the whole stack up. Docker’s current recommendation is Docker Desktop for the easiest cross-platform Compose setup; Docker Desktop includes Docker Engine, Docker CLI, and Docker Compose. ([Docker Documentation][3])

The modern command is:

docker compose version

Not:

docker-compose version

The old docker-compose binary may still exist on some machines, but the current Docker Compose plugin is used as docker compose.

Linux is the preferred full-time operator environment.

The example below is for Ubuntu. Docker’s official Ubuntu install guide lists supported Ubuntu releases and recommends installing Docker from Docker’s apt repository. ([Docker Documentation][7])

Choose a working directory with enough disk space.

mkdir -p ~/damage
cd ~/damage

git clone <YOUR_DAMAGEBDD_REPO_URL> damagebdd
cd damagebdd

Use the real project repository URL in place of <YOUR_DAMAGEBDD_REPO_URL>.

Check the important files:

ls -la Dockerfile docker-compose.yml

You should have:

Dockerfile
docker-compose.yml
.env or .env.example
features/
contracts/

Copy the example environment file:

cp .env.example .env

Edit it:

nano .env

A starter .env should look like this:

DAMAGE_API_URL=[http://localhost:4888/api](http://localhost:4888/api)

BITCOIN_CHAIN=main
CLN_NETWORK=bitcoin

BITCOIN_RPC_USER=damage
BITCOIN_RPC_PASSWORD=change_me_with_a_real_random_password

BITCOIN_PRUNE=0

CLN_LOG_LEVEL=info
CLN_RUNE=

AE_FEE_MULTIPLIER=2
AE_GAS_MULTIPLIER=2
AE_GAS_PRICE_MULTIPLIER=3

Generate a real Bitcoin RPC password:

openssl rand -hex 32

Put the result into BITCOIN_RPC_PASSWORD.

For a full-power node, keep:

BITCOIN_PRUNE=0

That means no pruning.

Tor is optional, but it is the clean operator path when you want users to access your node without exposing your home IP directly.

The Tor Project’s onion service guide uses HiddenServiceDir to store onion service keys and HiddenServicePort to map the onion service port to a local service; the onion hostname is written to a file named hostname in the hidden service directory. ([Tor Community][8])

From the DamageBDD repository:

docker compose up --build -d

Watch the services:

docker compose ps

Follow logs:

docker compose logs -f damagebdd

For the full stack:

docker compose logs -f bitcoin
docker compose logs -f lightning
docker compose logs -f ae_mdw
docker compose logs -f ipfs
docker compose logs -f tor

On the machine running Docker:

[http://localhost:4888](http://localhost:4888)

Health check:

curl -fsS [http://localhost:4888/version/](http://localhost:4888/version/)

A successful response means the DamageBDD HTTP service is reachable. The /version/ route is part of the DamageBDD HTTP routes.

Once Tor starts, read the onion hostname:

docker compose exec tor cat /var/lib/tor/damagebdd/hostname

You should see something like:

exampleexampleexampleexampleexampleexampleexampleexampleexample.onion

Open Tor Browser and visit:

[http://exampleexampleexampleexampleexampleexampleexampleexampleexample.onion](http://exampleexampleexampleexampleexampleexampleexampleexampleexample.onion)

Replace the example address with your real onion hostname.

That onion address is the access point you can share with testers.

Open the web interface locally or through Tor.

Then copy the node/account address shown by the UI.

That address is important because it identifies the node/operator side of the execution flow.

Keep three things together in your operator notes:

Local UI:       [http://localhost:4888](http://localhost:4888)
Onion UI:       http://<your-onion-hostname>.onion
Node address:   ak_...

Do not publish private keys, seed material, token files, macaroon files, rune secrets, or raw wallet credentials.

Create a basic feature file:

mkdir -p features
nano features/smoke.feature

Paste:

Feature: DamageBDD node smoke test

Scenario: The local DamageBDD version endpoint responds
Given I am using server "[http://127.0.0.1:4888](http://127.0.0.1:4888)"
When I make a GET request to "/version/"
Then the response status must be "200"

DamageBDD supports plain-language HTTP steps such as setting a server, making GET requests, and asserting response status through the HTTP step implementation.

Submit the feature through the web UI, or use the API flow supported by your node configuration.

A simple API-style test shape is:

curl -X PUT [http://localhost:4888/execute_feature/](http://localhost:4888/execute_feature/) 
-H 'content-type: application/json' 
--data-binary @- <<'JSON'
{
"feature": "Feature: API smoke\n\n  Scenario: Version responds\n    Given I am using server "[http://127.0.0.1:4888\"\n](http://127.0.0.1:4888\%22\n)    When I make a GET request to "/version/"\n    Then the response status must be "200"\n"
}
JSON

Some nodes require authentication or a paid/signed execution flow. If the node returns an auth, balance, transaction, or payment error, that means the web server is up but the economic execution path still needs configuration.

DamageBDD’s execution path adds the run directory to IPFS and formats a report URL using the configured Damage API URL.

Check IPFS:

docker compose logs -f ipfs

Check whether the IPFS API is reachable from the host:

curl -fsS [http://127.0.0.1:5001/api/v0/id](http://127.0.0.1:5001/api/v0/id) -X POST

The DamageBDD IPFS step module also supports explicit IPFS API and gateway testing patterns.

Bitcoin Core will take time to sync. On mainnet with no pruning, expect a long initial sync.

Check Bitcoin:

docker compose exec bitcoin bitcoin-cli 
-rpcuser="$BITCOIN_RPC_USER" 
-rpcpassword="$BITCOIN_RPC_PASSWORD" 
getblockchaininfo

Check Core Lightning:

docker compose exec lightning lightning-cli getinfo

DamageBDD includes Nostr Wallet Connect request handling for Bitcoin-network wallet actions such as get_info, get_balance, pay_invoice, make_invoice, lookup_invoice, and list_transactions.

DamageBDD also exposes NWC-related HTTP routes for minting/revoking sessions, checking ledger balance, creating top-up invoices, and checking top-up status.

Check the middleware status:

curl -fsS [http://localhost:4000/status](http://localhost:4000/status)

Check logs:

docker compose logs -f ae_mdw

DamageBDD reads Aeternity middleware nodes from configuration and uses middleware contract logs for ledger/event-style reads in the NWC ledger path.

The operator path is:

1. Run the verified stack.
2. Keep the node online.
3. Publish the web UI through Tor or another controlled public route.
4. Share the onion address.
5. Share the node/account address.
6. Let users submit behaviour tests.
7. Execute tests reliably.
8. Produce reports.
9. Keep the verification path healthy.
10. Receive eligible rewards/payments according to the configured DamageBDD economy.

The clean signal is not hype.

The clean signal is:

working node
working onion address
working web UI
working execution
working reports
working verification path

When those are true, the node has useful capacity.

#+END_SRC

Then open:

[http://localhost:4889](http://localhost:4889)

Start:

docker compose up -d

Stop:

docker compose down

Rebuild DamageBDD after code changes:

docker compose up --build -d damagebdd

Watch everything:

docker compose logs -f

Check service status:

docker compose ps

Show disk usage:

docker system df

Do not blindly run:

docker system prune --volumes

That can delete state you care about.

A beginner proves the node can run.

An operator proves the node can stay up.

A sovereign operator proves the whole verification stack can survive real use.

The final state looks like this:

Docker stack: running
DamageBDD UI: reachable
Tor onion: published
Node/account address: copied
Bitcoin Core: syncing or synced
Core Lightning: running
Aeternity middleware: running
IPFS: running
Smoke test: passing
Reports: produced
Operator backups: done

That is the path from zero to hero.

Run the node.

Publish the onion.

Serve execution.

Deal DAMAGE through verified behaviour.

[1]: https://bitcoin.org/en/bitcoin-core/features/requirements?utm_source=chatgpt.com "Bitcoin Core Requirements and Warnings" [2]: https://github.com/aeternity/ae_mdw?utm_source=chatgpt.com "GitHub - aeternity/ae_mdw: Aeternity Middleware in Elixir" [3]: https://docs.docker.com/compose/install/ "Overview of installing Docker Compose | Docker Docs" [4]: https://docs.docker.com/desktop/setup/install/windows-install/?utm_source=chatgpt.com "Install Docker Desktop on Windows" [5]: https://docs.docker.com/desktop/features/wsl/?utm_source=chatgpt.com "Docker Desktop WSL 2 backend on Windows" [6]: https://docs.docker.com/desktop/setup/install/mac-install/ "Install Docker Desktop on Mac | Docker Docs" [7]: https://docs.docker.com/engine/install/ubuntu/ "Install Docker Engine on Ubuntu | Docker Docs" [8]: https://community.torproject.org/onion-services/setup/ "Tor Project | Set up Your Onion Service" [9]: https://github.com/aeternity/ae_mdw/blob/master/docker-compose.yml?utm_source=chatgpt.com "docker-compose.yml - aeternity/ae_mdw"