A deployment is one engine process beside your Canton node, with two PostgreSQL databases and your identity provider, on DevNet, TestNet or MainNet. Take every NodeAsset part from one release.

​
What a deployment runs

​
What it needs

  • Your Canton node: a Canton participant at version 3.5, on DevNet, TestNet or MainNet, hosting the venue’s party, with its gRPC Ledger API reachable over TLS. Each other party runs its own.
  • Two Ledger API users: the engine’s, with CanActAs on the venue’s party and nothing more, and PQS’s, with CanReadAs on that party only.
  • PostgreSQL for PQS’s database and the engine’s. A database on another host is reached with TLS and certificate verification.
  • Java 21 for the engine.
  • An identity provider that issues signed tokens for the API and publishes its keys. See Identity provider.
  • Network reach from the engine’s host to your Canton node’s Ledger API, both databases, the identity provider’s keys over HTTPS, the token endpoint when the engine fetches its own ledger token, and your webhook receivers.
Size the servers from Hardware requirements. The engine is one process; its database grows with its history, which retention bounds. The engine listens on a loopback address only, and refuses to start on any other. Whatever fronts the API, such as a reverse proxy that terminates TLS, runs on the same host. Run the engine as a service of your choosing, such as a systemd unit or a container: nothing depends on which.

​
Verify the release

Take the jar and the DARs from the same release: the engine is built against its packages’ ids, and a mismatched pair fails at its first ledger command. Each counterparty verifies the DARs it vets the same way.

​
The order it comes up in

Each step that writes to the network is its own decision, taken by whoever owns that node.
1

Onboard the DA Registry

From your Canton node, through DA’s request-and-accept chain: DA’s Registry archives on your node; the venue’s party as the Registry’s provider, and its request to DA’s operator; the provider’s configuration; the registrar and its services, from the registrar’s own node; and the configuration of each asset.
2

Start PQS before NodeAsset writes anything

Grant PQS’s user its read right on the venue’s party as soon as the party exists, then start PQS once the asset configurations are made. PQS resolves its parties when it connects and never back-fills: a contract written before it starts has no history in the projection, and reconciliation cannot check it. Confirm PQS shows each asset configuration before you go on.
3

Upload and vet NodeAsset's packages

Upload the release’s DARs to your Canton node and vet them: nodeasset, nodeasset-oracle-api and nodeasset-oracle, and for backed issuance nodeasset-reserve and nodeasset-reserve-lock. Without the reserve’s two the engine runs and reads no reserve, and refuses to open one with package-not-vetted; add them whenever you start backed issuance.This is a vetting event: each other party’s node vets the packages it uses before it acts (Who runs what). See Upgrades and package versions.
4

Configure and start the engine

Create the engine’s ledger user and its database, write its configuration (Configuration reference), and start it:
The engine checks its configuration before it touches the ledger or a database, and starts with no asset recorded: it acts on nothing until one is.
5

Settle the smallest transaction

Before anything else, take one settlement end to end: record one asset, admit one holder, settle the smallest subscription, and read it back on the ledger and in PQS.
6

Record the assets

Through the API, under four eyes: the assets, each asset’s policy, each backed instrument’s reserve, then the admissions. See Set up an asset.

​
Check it

Related: Configuration reference · Identity provider · Monitoring