Deploying a Dedicated Synchronizer

​

Who this guide is for

• You need a dedicated synchronizer for privacy, performance, governance, or cost reasons
• A single organization will own and operate the sequencer and mediator (the default path below)
• You may later connect the same validators to the Global Synchronizer (hybrid pattern)

​

Choose your topology

​

Prerequisites

• Familiarity with Canton’s synchronizer architecture
• PostgreSQL 14+ — separate databases for sequencer and mediator; for production, a managed service with automated backups, at least 4 vCPUs / 16 GB memory, and SSD-backed storage
• TLS certificates for the sequencer public API (validators connect here)
• The Canton 3.5 release (canton-open-source-3.5.<patch>.tar.gz from Canton releases) for the sequencer and mediator
• Shell access to the host that runs the sequencer and mediator, for the Canton Console

​

1. Configure APIs, backend, and TLS

1. Sequencer and mediator APIs — public and admin ports/addresses (Configure Synchronizer APIs)
2. Sequencer backend — sequencer.type = BFT for the default path (Configure Sequencer Backend)
3. TLS on the sequencer public API (Secure Synchronizer APIs)
4. Storage — Postgres for each node (next section)

canton {
  sequencers {
    sequencer1 {
      storage.type = postgres
      // ... postgres connection ...
      public-api {
        address = "0.0.0.0"
        port = 5001
        // TLS: see Secure Synchronizer APIs
      }
      admin-api.port = 5002
      sequencer.type = BFT
    }
  }

  mediators {
    mediator1 {
      storage.type = postgres
      // ... postgres connection ...
      admin-api.port = 5202
    }
  }
}

​

2. Set up databases

​

3. Deploy and start sequencer and mediator

./bin/canton daemon --config synchronizer.conf

​

Open a Canton Console

canton {
  remote-sequencers {
    sequencer1 {
      public-api {
        address = "localhost"
        port = 5001
      }
      admin-api {
        address = "localhost"
        port = 5002
      }
    }
  }
  remote-mediators {
    mediator1 {
      admin-api {
        address = "localhost"
        port = 5202
      }
    }
  }
}

./bin/canton --config remote.conf

​

Confirm nodes are healthy

• The sequencer and mediator processes are running
• Sequencer health endpoint returns HTTP 200 (when exposed)
• nodes.remote.foreach(_.health.wait_for_running()) returns in the console

​

4. Bootstrap (initialize) the synchronizer

@ bootstrap.synchronizer(synchronizerName = "my-private-sync", sequencers = Seq(sequencer1), mediators = Seq(mediator1), synchronizerOwners = Seq(sequencer1), synchronizerThreshold = PositiveInt.one, staticSynchronizerParameters = StaticSynchronizerParameters.defaultsWithoutKMS(ProtocolVersion.forSynchronizer))
    res1: PhysicalSynchronizerId = PhysicalSynchronizerId(
      logical = SynchronizerId(
        uid = UniqueIdentifier(
          identifier = String185(str = "my-private-sync"),
          namespace = Namespace(fingerprint = 122032922613...)
        )
      ),
      serial = NonNegativeNumeric(value = 0),
      protocolVersion = 36
    )

• Decentralized synchronizer
• Decentralized with a subset of sequencers as owners
• Permissioned synchronizer

​

5. Connect validators

@ participant1.synchronizers.connect_local(sequencer1, "my-private-sync")

extraDomains:
  - alias: "my-private-sync"
    url: "https://sequencer.example.com:5001"

​

6. Verify the deployment

1. Sequencer health — HTTP health endpoint returns 200
2. Mediator in topology — Mediator is registered on the synchronizer
3. Participant connected — participant.synchronizers.list_connected() shows your alias
4. Ping — Participant can ping across the synchronizer (see bootstrap examples in Synchronizer Operations)
5. Optional smoke test — Allocate a test party and create a contract assigned to the dedicated synchronizer

​

Production hardening and next steps

• TLS everywhere — Validators to sequencer public API; prefer TLS for peer and admin paths in production (Secure Synchronizer APIs)
• Network policies — Restrict sequencer endpoint access to known validator networks
• Monitoring — Synchronizer monitoring; reuse your validator metrics stack where possible
• Backups — Back up sequencer and mediator databases regularly (Backup and Restore)
• HA — High Availability in Synchronizer
• Traffic management — If you enable traffic controls on a dedicated synchronizer, see Sequencer Traffic Management
• Pruning — Synchronizer Pruning

​

Related reference

• Dedicated Synchronizers — Why and when to use them
• Hybrid Synchronizer Pattern — Dedicated + Global Synchronizer
• Linking Validators — Multi-synchronizer participants
• Synchronizer Operations — Configure, bootstrap variants, HA, traffic, pruning, backup
• BFT Orderer Architecture — Ordering backend background
• Synchronizer Monitoring — Observability