In addition to the management of multiple connections, the engines were limited in their access control model. They had a limited number of immutable roles that often missed the nuances of customer organizations. In DCT, we’ve built a robust Attribute-based Access Control mechanism that allows you to build your roles.  

The dct-toolkit takes advantage of these permissions. Therefore, the account’s provided API Key will follow the same permission model defined manually within DCT.  

Please read the Data Control Tower (DCT) - Access Control Implementation blog for further explanation and examples. 

Delphix Support 

One of the most common requests we heard was the need for Delphix to support a command line option. Thus, we have taken the extra step to release the dct-toolkit as a fully support offering. 

Unlike the dxtoolkit, you can file a ticket on the Delphix Support Portal for any dct-toolkit issues, and we’ll respond shortly!  

There are a few other minor differences between DCT and Delphix Continuous Data Engines, but they are outside the scope of the Delphix Self Service CLI migration. If you would like to learn more, please see the full set of differences in our documentation.  

When do I have to migrate off the dxtoolkit? 

If your dxtoolkit script depends on one of the following commands, you will need to migrate off the dxtoolkit by the September 2025 release of Continuous Data. 

If a script references any of the above dxtoolkit commands, we recommend the entire script is re-written using the dct-toolkit. However, you could also take the opportunity to migrate to DCT, CD, or CC's APIs or a DCT integration, such as Terraform, ServiceNow, or Jenkins.  

Whether you choose to move over to dct-toolkit or stay with dxtoolkit, all VDBs must be disassociated with their Self Service templates and containers by Continuous Data’s September 2025 release. 

What are the common dct-toolkit examples? 

Now that you have a good handle on the differences between dxtoolkit vs dct-toolkit and the scenarios that will require migration, let’s jump into various examples. Beware, not all commands can be copied directly into your terminal. Many will require some modification locally to specify valid VDBs, bookmarks, etc. 

Installation, Configuration, and Help 

Previously, dxtoolkit users would need to define connection and authorization information for each engine. With the dct-toolkit, only the credentials to DCT are required and thus, connectivity is drastically simplified.  

First, follow this documentation to download and configure dct-toolkit. 

Next, to see the available commands, simply run `. /dct-toolkit –h`. This will list every available command. Then, to learn more about a specific command, run ./dct-toolkit <COMMAND> -h  to see full helpful documentation.

For example: ./dct-toolkit.exe refresh_vdb_by_snapshot –h

We recommend you use the -h argument frequently! All text is populated based on your installed version of DCT. Therefore, you can see new commands or documentation updates when DCT is upgraded. 

This blog post was written against DCT v17 (May 2024’s release). 

VDB Provision  

Create a new virtual dataset 

Create a new VDB. The various provision sub-commands are dependent on the database type.  

Note: AppData is the generic term that refers to all database types that are managed through the connector’s plugin ecosystem. 

We recommend using the provision_vdb_by_snapshot –h argument to review all available input parameters. Every dataset type requires a different set of properties.  

Once provisioned, you can use this VDB in any of the following commands or instead, simply use a VDB that already exists. 

Single VDB Management 

Refresh from Parent’s Latest Snapshot 

Refresh a VDB with the parent’s latest snapshot. 

By default, the `refresh_vdb_by_snapshot` command will grab the latest snapshot from the VDB’s parent. Follow the example below to specify a specific snapshot. 

Refresh from a Snapshot 

Refresh the VDB with a chosen dSource snapshot. (Formally known as Restore.) 

./dct-toolkit.exe get_dsource_snapshots dsource_id=<DSOURCE NAME OR ID>
 
 

Note: A dSource and VDBs are “compatible” with one another if they originate from the same dSource. 

You will receive the following error if the snapshot is incompatible with the specified VDB: 
“Refresh to an object with a different root container is not supported.” 
 

Refresh from a Timestamp 

Refresh the VDB with a selected timestamp from within itself. (Formally known as Restore.) 

 
Note 1: The Timestamp is provided in ISO 8601 format. (Example: yyyy-MM-dd’T’HH:mm:ssZ) 

Note 2: By default, every snapshot has a timestamp. However, to enable a continuous range of timestamps, LogSync (or Point-in-Time Recovery) must be enabled for your selected VDB or dSource dataset. 

You will receive the following error if the timestamp is unavailable to the selected VDB: 
Cannot find provisionable point <timestamp> for source <VDB ID>

Refresh from a Bookmark 

Restore a VDB with any compatible bookmark. 

Similar functionality can be achieved for “snapshots” with equivalent get_snapshot_by_id and refresh_vdb_by_snapshot commands. 

Create, Share, and Delete a Bookmark 

Create a new bookmark on a VDB and then share it with compatible VDBs. 

Multi VDB Management 

Create a VDB Group 

Combine multiple existing VDBs into a new VDB Group. 

Create, Share, and Refresh Bookmark 

Pardon our dust! 
 
We are expanding heavily on our VDB Group refresh and bookmark management in the second half of 2024. This section will be revamped once implemented. 

Account and Access Management

Full user management is a detailed topic that requires comprehension of our Attribute-Based Access Control model. If you are unfamiliar with it, we recommend first reading our Data Control Tower (DCT) - Access Control Implementation blog post. Once you grasp how accounts, access groups, roles, and scopes interact, the following commands will make more sense. 

We do not recommend heavy access management through the dct-toolkit. The DCT user interface provides a better customization experience. Once set up, modifications are rarely needed outside of tag additions.  

The below examples provide ways to create accounts and perform minor permission management. 

Account Creation 

Create a new account with an email, password, API Key, and automatically assign the user to an Access Group. 
 

This example takes advantage of Access Group assignment by using tags.  

Accounts can be manually assigned to Access Groups by using the add_access_group_accounts_ids command. 

Access 

There are primarily three different ways in which object access, such as VDBs and dSources, can be granted to a specific user. Follow the examples below to learn more. 

Owner 

By default, if a user creates an object, that user will automatically have the `owner` access to that object. This is useful if your users create their own objects or an API Key is shared across a team. 

This can be confirmed by creating any object and then navigating to the Account’s Individual access group and reviewing its contents. 

Direct Assignment 

Due to DCT’s attribute-based access control model, this is considered an advanced assignment mechanism. It is not recommended for early DCT configurations. This strategy leverages the “Scoped - Objects Mapping” or “Advanced Scoping” assignment modes.  

We recommend implementing some form of Direct Assignment via the UI first before managing access via the CLI.  

Tags (see below) is a much simpler model. 

Tags  

We recommend tags as the primary mechanism to manage wide scale object access control. This leverages the “Scoped - Tag Mapping” assignment mode. This typically requires configuration outside of the CLI to set up the framework, but then you can easily add new object tags through the following commands. 

This VDB does not have any tags. 

In this example, if access is controlled by the “Team=Alpha” or “Geo=US” tags, the users within that access group will now have access to those resources defined by the role’s scope. It’s often best to attempt this workflow through the UI first and then automate it second. 

Closing 

We hope you found this blog post valuable when migrating from the dxtoolkit and hitting the September 2025 end of life date! While we only covered a subset of common Self-Service dct-toolkit commands, there are over 200+ others to explore. New features are being added frequently, so be sure to keep an eye on the DCT release notes to learn about new commands and use cases. 

If you have any questions or need some pointers on suggested commands, please leave a comment below.