One instance runs on infrastructure you choose, and everything outside it stays under your governance.
Each deployment path uses the same platform package. Enabled capabilities depend on the release, configuration, and connected services.
You choose where the platform stores its durable data. Review ledger, custody, identity-provider, and telemetry destinations against your residency and access policies.
Each instance connects to the approved EVM-compatible networks, public or private.
Why the deployment unit matters
A DALP Instance is the unit you deploy and run: one full copy of the tokenisation platform, placed where your own rules demand. It does not split into a hosted core and satellite services. Each copy carries issuance, servicing, and reporting inside the same deployment, wherever that deployment runs.
A regulated institution reviews where a platform runs before it reviews features. The platform has to run inside your perimeter, sign staff in through your corporate identity provider and hand its audit evidence to your own monitoring. You pick one of three deployment paths and configure the durable stores the instance uses. Records sent to external integrations or ledger networks also follow those systems' storage policies. The systems you connect it to stay under your own governance and receive only the traffic your configuration sends them.
The three paths differ on two things a deployment review tests: who holds the infrastructure, and who has to be able to reach the running system.
Start from the constraint that is hardest to move. A residency or vendor-access rule decides the path on its own, because no configuration makes an operated cluster private from its operator. Where no such rule binds, the question is whether you have the team: self-hosting gives you control over availability and upgrade timing at the cost of operating work. The vendor-run path takes that work from your team and also takes that control. On all three paths an instance has its own platform state, database and control plane, and instances share no application data. Shared infrastructure, network providers, or other external services can still affect multiple instances.
Approve each ledger network for the instance. A public EVM-compatible network uses its existing node governance. A private network lets you control who operates the nodes. Choose the network whose access and governance meet your deployment requirements.
Running an instance
Day to day, a DALP Instance is a short list of workloads on a Kubernetes or OpenShift cluster. The backend runs as separate workloads from one release: the Platform API, the Workflow Engine runner, the Ledger Data indexer and a scheduler, each with its own replica count. The web Console, a PostgreSQL data plane and Redis sit beside them, with object storage for documents and backups.
The runtime shape is the same on all three paths. Only the party that runs each layer changes.
On self-hosted paths your platform team runs the cluster and applies each upgrade from the vendor's versioned releases. Promote the same release artifacts from test to production. Use release and instance attributes in telemetry to identify mixed versions during a rollout. Two parts of one copy that report different versions in the same telemetry view are a defect. Finish rolling the new release out to the part that is behind, or roll the part that is ahead back, until every part reports the same version.
Every copy declares a stable, globally unique identity, stamped on every signal it exports. In the telemetry store you designate, that identity groups a whole fleet into one view, while each copy's dashboards show only itself. The identity is the Helm value global.dalpInstance. It defaults to local, which suits a developer machine only, so set a unique identity on every other install. The chart refuses an empty or malformed value, but not the default. Two copies that declare the same name are not refused either: their signals merge into what the fleet view reads as one instance, and separating them again means renaming one copy's declared identity.
Recovery splits by data class: the platform can rebuild indexed chain state from the ledger, while off-chain records such as approvals, identities, documents and workflow state exist only in the copy's database, so your backups protect them.
What sits inside the instance
A DALP Instance holds three zones: public access, the backend runtime, and durable data. Systems that you govern separately stay outside and connect in, including ledger nodes or remote procedure call endpoints, custody and signing, identity, outside data providers, and central telemetry.
Inside, the backend runs as separate workloads, and each scales on its own. The Platform API authenticates callers, serves reads, and accepts writes. The Workflow Engine runner carries multi-step work across crashes and restarts. The Ledger Data indexer turns chain events into typed, queryable business data: holdings, transfers, balances. A scheduler runs the platform's scheduled jobs. All of them share one PostgreSQL data plane, the durable core: platform state, workflow journals, and indexed read models live there, and the workloads coordinate who owns which durable work through it.
Multi-tenancy lives inside the copy, and it has two layers. On chain, each organisation operates its own set of contracts holding its registries and roles under its own rulebook, so one issuer's assets never mix with another's. Each copy also keeps a catalogue of served networks, and different organisations on it can put their on-chain systems on different approved networks.
Off chain, tenant routes scope data to the authorised organisation. Platform administration also has privileged cross-organisation operations. Separate firms run separate copies, which share no state, no database, and no control plane. Isolation also depends on network rules, credentials, and external services. The ledger and separately governed systems keep their own state.
Organisations share one firm's copy, each with its own contracts on chain, while a separate firm runs a separate copy that shares nothing.
The network list a copy serves has two writers: the values set when the platform is deployed, which seed a network the first time its name appears, and entries a platform administrator registers at runtime. After a network is stored, the stored entry wins. Adding a network therefore needs no redeploy, while the default network stays a change-controlled setting.
Frequently asked questions
Which of the three paths does a residency rule force?
It depends on the rule. A rule that requires the hardware and the records to stay on premises under your own administrative control forces the on-premises path. A rule that forbids the vendor's operations team from reaching your records rules out the vendor-operated path and leaves on premises or your cloud account. A rule that only requires an approved cloud account leaves both of those open.
Can we start on one path and move later?
Yes. The package is the same everywhere: the API surface, the software, and the records it holds do not change with a move. What changes is the operating split, who runs the cluster, applies upgrades, and answers the alerts. A later move redeploys the same package onto the new path, and the database and storage come with it. Plan the move of signing keys and secrets separately, because they sit with your custody provider or secret manager. Exit and data portability and Backup and disaster recovery set out what you can take with you and how to restore it. Your client code keeps targeting whichever copy's endpoint and credentials you configure, regardless of which of the three paths that copy runs on.
What traffic leaves the instance?
The integrations you configure, plus defaults you can replace. Configured traffic goes to the ledger networks you approve, the custody and outside data providers you select, mail delivery, telemetry to the store you designate, and webhooks to your endpoints. Unless you set your own exchange-rate source, the platform fetches exchange rates from a public currency service on the internet. Unless you mirror the images, each pod pulls them from SettleMint's public image repositories. When the operator turns analytics on, the Console sends usage data to SettleMint's analytics accounts. No shared control plane sits behind the copy, so telemetry reaches SettleMint only when you send it there. Your own network controls govern any other egress.
Does the environment label change how a copy behaves?
No. global., one of local, development, test, staging, demo or production, feeds one telemetry attribute, deployment., and nothing else. Declaring a copy's environment tells your fleet view which one it is. The platform's behaviour comes from the release image and the rest of its configuration, not from this field.
Where do the signing keys live?
They live where your policy puts them. The platform signs through a path you configure: your own hardware security module, an external custodian, or an encrypted store the copy hosts. Review who can access each signing service and its administration. When SettleMint operates an instance that uses the local key store, SettleMint staff with cluster access can reach the encrypted key material. Use an external HSM or custodian if that is not acceptable.