> For the complete documentation index, see [llms.txt](https://docs.bitsafe.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bitsafe.finance/decentralization-manager/get-started/prerequisites.md).

# Prerequisites

[Overview](/decentralization-manager/overview.md)

## Choose a setup path

| Goal                        | Minimum path                                                       | Additional requirements                                                                                                   |
| --------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- |
| Review the architecture     | Repository and documentation access                                | No running Canton environment.                                                                                            |
| Build from source           | Rust, Node.js, Git and the build packages                          | Canton access is optional for a compile-only check.                                                                       |
| Run one development node    | Build tools or Docker, plus Canton Admin API and Ledger API access | An identity provider, or insecure mode on `devnet`. Local storage and free ports.                                         |
| Run a local multi-node mesh | Docker Compose, or several local processes                         | One participant for each node, and distinct ports for each node.                                                          |
| Deploy to production        | A release image, Kubernetes or equivalent, and persistent storage  | An identity provider, TLS for the HTTP listener, a raw TCP path to the Noise port, secret storage, monitoring and backup. |

## Development tools

The repository requires:

* Rust edition 2024, with Rust `1.94.1` or newer. The locked AWS SDK crates require that version.
* Node.js `^20.19.0` or `>=22.12.0` for the embedded frontend.
* Docker for container builds and for the full integration test.
* Daml SDK `3.4.11` through the `dpm` CLI, for Daml packages and tests.
* Java 17 or newer, for Daml tests.
* Git.

The build fetches its Git dependencies over HTTPS from public GitHub repositories. A source build needs no SSH key. The CI build installs `pkg-config`, `libssl-dev`, `protobuf-compiler`, `libprotobuf-dev` and `cmake` on Debian or Ubuntu.

## Canton access

A running node needs access to one Canton participant:

* The **Admin API**, for topology, keys, identity, package upload and other privileged operations.
* The **Ledger API**, for contracts, commands, user rights, party data and interactive submissions.

The operator must know these values for each API:

* The host and the port.
* Whether the endpoint serves plaintext, TLS or mTLS.
* The certificate authority and the certificate name, where TLS applies.

The operator must also know the Canton synchronizer name and the network: `devnet`, `testnet` or `mainnet`.

The node reads its participant ID from the Admin API at startup. If the Admin API is unreachable, the process exits.

## Authentication

The operator UI needs one identity provider:

* A Keycloak public client with Authorization Code and PKCE.
* An Auth0 single-page application and an Auth0 API audience.

Each Decentralized Party also needs party credentials for Canton operations. These credentials are separate from the browser login. Document their owner, rotation, storage and `actAs` or `readAs` rights before you run workflows.

A node that hosts an external party, or that adds hosts to a local party, also needs tenant API keys in `DECPM_TENANT_API_KEYS`. The tenant API rejects every call when the node has no keys.

### Insecure mode

Insecure mode (`--insecure` or `DECPM_INSECURE=true`) replaces the identity provider for local development. It needs a Canton participant with unsafe shared-secret (HS256) authentication.

Insecure mode starts only on `devnet`. The process refuses to start in insecure mode on `testnet` or `mainnet`. The network defaults to `devnet` when `DECPM_CANTON_NETWORK` is unset. Set the network explicitly on every shared node.

{% hint style="warning" %}
Insecure mode turns off authentication. Never enable it on a node that other people can reach.
{% endhint %}

## Signing keys and AWS KMS

A member of a Decentralized Party signs ledger transactions with the party's Daml key. The crypto provider of the participant decides who holds that key:

| Participant crypto provider | How Decentralization Manager signs                                                                                              | Setup                 |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | --------------------- |
| JCE                         | The node exports the party's Daml private key from the vault for each signature. It signs on the node and never stores the key. | None.                 |
| AWS KMS                     | The key cannot leave AWS KMS. The node calls the AWS KMS `Sign` API with the key ID.                                            | IAM setup, see below. |

Prepare these items for a node next to an AWS KMS participant:

* AWS credentials that the AWS default credential chain of the node resolves. On Amazon EKS, attach an IAM role to the service account of the node.
* The AWS region of the KMS keys. Set `AWS_REGION` when the credential chain does not resolve a region.
* The `kms:Sign` permission on each party Daml key. Grant it in the key policy of each key.
* Key metadata that holds a bare KMS key ID. The node rejects an ARN, an alias or a malformed ID.
* EC-P256 keys. The node supports no other key spec for KMS signing.

[Sign with AWS KMS](/decentralization-manager/operations-and-reference/sign-with-aws-kms.md) gives the key policy and the failure modes.

## Networking

The node uses these default ports:

| Port   | Variable                   | Listener or connection                                     | Who connects                   |
| ------ | -------------------------- | ---------------------------------------------------------- | ------------------------------ |
| `8080` | `DECPM_PORT`               | HTTP: operator UI, operator API, tenant API and `/healthz` | Operators and wallet providers |
| `9000` | `DECPM_NOISE_PORT`         | Noise peer protocol over raw TCP                           | Other nodes                    |
| `9464` | `DECPM_METRICS_PORT`       | Prometheus metrics at `/metrics`, with no authentication   | The metrics collector only     |
| `5001` | `DECPM_CANTON_LEDGER_PORT` | Outbound connection to the Canton Ledger API               | This node                      |
| `5002` | `DECPM_CANTON_ADMIN_PORT`  | Outbound connection to the Canton Admin API                | This node                      |

{% hint style="warning" %}
The metrics listener has no authentication and binds to `DECPM_HOST`. The HTTP listener binds to the same address. `DECPM_HOST` defaults to `0.0.0.0`. Keep port `9464` unreachable from untrusted networks, or set `DECPM_METRICS_PORT=0` to turn the listener off.
{% endhint %}

Peers dial the address in `DECPM_PUBLIC_ADDRESS`. Without it, the node gives peers its Noise listen address. That address defaults to `0.0.0.0`. Set `DECPM_PUBLIC_ADDRESS` on every node that peers reach from another host.

These values are defaults. Confirm the actual ports, firewall rules, DNS, load balancers and TLS termination for each environment. [Configuration reference](/decentralization-manager/operations-and-reference/configuration-reference.md) lists every variable.

## Persistent data

Plan persistent storage for the data directory. The node writes these files under `<dir>/data/`:

* `noise.key`: the Noise identity of the node.
* `decpm.db`: the SQLite database with peers, party credentials and workflow state.

The node reads an optional `.env` file from the `-d` or `--dir` directory, or from the working directory. `DECPM_DIR` does not choose the `.env` location. A lost Noise key forces every peer to update its record for this node. A production setup needs a tested procedure for backup and recovery.

## Container images

Each release has two images on Amazon ECR Public:

* `public.ecr.aws/dlc-link/decentralization-manager:<tag>` runs as uid 0.
* `public.ecr.aws/dlc-link/decentralization-manager:<tag>-nonroot` runs as uid 65532.

Both images are `linux/amd64` images. [Run with Docker](/decentralization-manager/get-started/run-with-docker.md) explains the mount path of each image.

## Preflight commands

```bash
rustc --version
cargo --version
node --version
docker version
dpm version
java -version
git --version
protoc --version
```

Run only the checks that your setup path needs.

## Readiness checklist

* [ ] You chose a release tag or an image.
* [ ] The build tools match the versions above.
* [ ] The node can reach the Canton Admin API and Ledger API.
* [ ] The TLS or mTLS settings match what each Canton endpoint serves.
* [ ] You configured the operator identity provider.
* [ ] Party credentials and their Canton rights are available.
* [ ] Each node next to an AWS KMS participant has AWS credentials and the `kms:Sign` permission.
* [ ] The intended callers can reach the HTTP and Noise ports.
* [ ] Untrusted networks cannot reach the metrics port, or the metrics listener is off.
* [ ] You planned persistent storage, secret storage, backup, logs and monitoring.
* [ ] Insecure mode is off on every shared or production node.

## Technical sources

* [Repository README](https://github.com/DLC-link/decentralization-manager/blob/main/README.md)
* [Operator guide](https://github.com/DLC-link/decentralization-manager/blob/main/USER_GUIDE.md)
* [Deployment guide](https://github.com/DLC-link/decentralization-manager/blob/main/docs/DEPLOYMENT_GUIDE.md)
* [Contribution prerequisites](https://github.com/DLC-link/decentralization-manager/blob/main/docs/CONTRIBUTING.md)
* [Signing with AWS KMS party keys](https://github.com/DLC-link/decentralization-manager/blob/main/docs/KMS_SIGNING.md)
* [Command-line flags](https://github.com/DLC-link/decentralization-manager/blob/main/crates/decman/src/cli.rs)
* [Startup and `.env` loading](https://github.com/DLC-link/decentralization-manager/blob/main/crates/decman/src/main.rs)
* [Server startup and the insecure-mode check](https://github.com/DLC-link/decentralization-manager/blob/main/crates/decman/src/server/mod.rs)
* [Vault export signer](https://github.com/DLC-link/decentralization-manager/blob/main/crates/decman/src/signing/vault_export.rs)
* [Build environment](https://github.com/DLC-link/decentralization-manager/blob/main/.github/actions/setup-build-env/action.yml)
* [Workspace manifest](https://github.com/DLC-link/decentralization-manager/blob/main/Cargo.toml)

## Related pages

* [Run locally](/decentralization-manager/get-started/run-locally.md)
* [Run with Docker](/decentralization-manager/get-started/run-with-docker.md)
* [Production deployment](/decentralization-manager/get-started/production-deployment.md)
* [Configuration reference](/decentralization-manager/operations-and-reference/configuration-reference.md)
* [Authentication and operator roles](/decentralization-manager/operations-and-reference/authentication-and-operator-roles.md)
* [Sign with AWS KMS](/decentralization-manager/operations-and-reference/sign-with-aws-kms.md)
* [Compatibility, releases, and troubleshooting](/decentralization-manager/operations-and-reference/compatibility-releases-and-troubleshooting.md)

## Next step

👉 **Choose a setup:** [Run locally](/decentralization-manager/get-started/run-locally.md) or [Run with Docker](/decentralization-manager/get-started/run-with-docker.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.bitsafe.finance/decentralization-manager/get-started/prerequisites.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.