Console Overview

Daml Hub is a cloud platform built to help you take your Software-as-a-Service (SaaS) application from humble beginnings to mass adoption with as little development as possible.

Daml Hub is for developers looking to build a simpler, scalable backend for their applications with a serverless experience.

Almost any application heavier than a pure web app can benefit from using Daml Hub as a backend. Developers use Daml Hub to build applications like crypto exchanges, loan management platforms, medical claims management, digital rights management, and many more.

Daml Hub Tiers

Daml Hub has two account tiers: Free Tier and Enterprise Tier. When you sign up for Daml Hub you are automatically subscribed to Free Tier. To upgrade to Daml Hub Enterprise Tier, please contact Digital Asset Sales here.

The differences between the two tiers can be seen in the table below:

Feature Free Tier Enterprise Tier
Create standard ledgers
Standard ledger quota
3 ledgers

10 ledgers
Create High Capacity ledgers
Ledger events quota
10k events/month

No quota
Ledgers run uninterrupted
Paused after 24hr inactivity
Support
Community support

24/7 Enterprise support
Uptime commitment
No uptime commitment

At least 99.9%
Stream logs to Datadog for High Capacity ledgers
Can invite ledger collaborators
Reserve custom subdomains and assign them to ledgers

Workspace

After signing in to Daml Hub, you enter your own app-building workspace. The workspace is where you manage your projects, ledgers, files, and ledgers that have been shared with you. Each project can contain multiple ledgers that differ based on their deployments. Both projects and ledgers can be created and deleted within the workspace. For more information on ledgers, see the Daml Ledger Model.

The workspace in the Daml Hub UI, focused in the Your Projects zone, with the Welcome to Daml Hub! message and sample apps.

The workspace is split into two zones, "Your Projects" and "Shared Ledgers". "Your Projects" is where your projects and ledgers live. "Shared Ledgers" is where you find ledgers that have been shared with you. Collaborating on ledgers allows two or more Daml Hub users to configure, deploy artifacts to, and manage the same ledger instance. As a collaborator on a ledger, you can do everything the ledger owner can do, with four exceptions: you cannot delete the ledger, change the ledger capacity, add/remove other collaborators, or add/change a subdomain for the ledger.

The workspace, now focused on the Shared Ledgers zone, with one instance of the Daml chat ledger running.

Collections

The Collections column at the left of the workspace lets you upload and manage files containing Daml models and triggers, automation, and UI assets. Keeping your files in your workspace collection makes it easy to deploy and re-deploy them across multiple ledgers. Files can be deployed into a ledger from the workspace collection by clicking the button Deploy to... or by dragging and dropping the file into a ledger.

The workspace is also home to fully functional, pre-built sample applications. You can deploy these applications to dedicated ledgers with a single click. For more information and a quick start guide, see Sample Apps.

Quick Build Tab

The Quick Build tab is revealed when you click "Wondering what to do next?" It shows you the building blocks of a Daml Hub app and the file count of your current ledger. Click on a tile to upload Daml, Daml Triggers, automation, and UI assets directly to your ledger. These tiles also contain links to their corresponding sections of the Daml Hub documentation.

The Quick Build page, with the Daml, Automation, and UI Asset tiles.

Deployments Tab

You can view the Deployments tab for a ledger by clicking on the ledger in the workspace. This tab is where you manage deployed artifacts, configure new instances, and publish a front end for your application.

The Deployments tab with one file in the Action Needed tile.

Live Data Tab

The Live Data tab allows you to explore the Daml contracts on your ledger.

The table displays a list of contracts filtered by party. Therefore, the contracts listed at any given time are those that the selected party can view and act on. You can add and manage ledger parties in the Identities tab.

You can view a specific contract's data by selecting it from the center column. Additionally, you can exercise choices on behalf of your currently selected party. Daml contracts can be created in two ways: by clicking the Add Contract button and creating a new contract from a template, or by exercising a choice on an existing contract. New contracts are temporarily marked with a green dot to indicate that they have been recently created.

The Live Data tab, showing contracts and contract details for the party Alice.

The Create Contract interface supports the following Daml Types: Bool, ContractId, Date, Decimal, GenMap, Int, List, Map, Numeric, Optional, Party, Text, Time, and Unit. For more details on Daml data types, visit the Daml Docs.

When creating a contract from a template through the Create Contract interface, be advised of the following type structure:

  • Primitives - For Int, Decimal, Text, Timestamp, Scenario, and ContractId, enter the value in the empty field. Date lets you select the date you want from a calendar. Bool lets you select a boolean value. Party lets you select the desired value from a drop-down.

    Note: The Party drop-down displays only the parties visible to you. If you created the ledger, you can see all the parties of each user that has joined. If you joined someone else's ledger, you can only see the parties you created. If you want to input a party that you don't have visibility to, you need to ask that party's user for their party ID and paste it directly into the drop-down.

  • Lists - [v₁, ..., vₙ]
    Enter each list value separately and press enter. If you don't enter any values an empty list is created. If you wish to delete a single value, press on the x that appears above it.

  • Optionals - You can fill in optional fields can be filled in or they may be left blank. If the field is left blank, its value is encoded as null.

  • Maps and TextMaps - { k₁: v₁, ..., kₙ: vₙ }
    Maps and Text Maps are represented as objects containing a series of key-value pairs. Keys and values have their respective separate input fields.

  • GenMaps - [ [k₁, v₁], [kₙ, vₙ] ]
    Gen Maps are represented as lists of pairs. Keys and values have their respective separate input fields.

  • User-Defined Types - Variants appear as drop-downs and records as blocks containing their values. Variants with constructors appear as drop-down menus. Each constructor is an item on the drop-down. Once you choose a constructor, the input fields for that constructor appear below.

The representation of user-defined types may become arbitrarily complicated and this user interface assumes a relatively simple structure. To request support for unsupported types or report bugs, post on the Daml Forum.

Identities Tab

The Identities tab lets you manage your ledger's parties and users. This page becomes available once the ledger is running. It has three zones: "Parties", "Users", and "Service Accounts".

To learn more about parties and users in Daml, see the Daml docs. To understand parties and users in Daml Hub, see Users and Parties

Parties

"Parties" shows a table with all the existing parties on your ledger, as shown below. You can create and delete ledger parties here.

The Parties zone of the Identities tab, showing a table with four parties.

Users

"Users" shows a table with all the existing users on your ledger, as shown below. Selecting a user in the table shows the list of parties the user can read and/or act as. You can create new users here, as well as delete existing users.

The Users zone of the Identities tab, showing a table with eight users.

Clicking a user's name in the table displays the parties associated with the user and their rights, as well as the button that allows you to delete the user.

The Users zone of the Identities Tab, with expanded user details.

Service Accounts

"Service Accounts" lets you generate a credential to interact with external services.

Collaborators Tab

The Collaborators tab lets you manage the other Daml Hub users contributing to your ledger. Ledger collaborators can do nearly everything a ledger owner can do, but they cannot delete the ledger, change ledger capacity, add/change subdomains, or add/remove other collaborators. Any collaborator added to your ledger gains a UserAdmin token and has administration rights on that ledger; see Default Parties in the Parties section for more details.

To add collaborators to your ledger, you must have their User IDs (which they can copy from their Account Settings page under the heading "User ID"). From the workspace, click the "Options" drop-down on the ledger's project tile and select "Share Ledger". Choose the ledger you wish to share and enter the User IDs of desired collaborators. Alternatively, you can add collaborators directly from your ledger in the Collaborators tab by selecting "Add Collaborators". The ledger(s) you share appears in the collaborator's "Shared Ledgers" tab in their account's workspace.

Collaborators tab with four collaborators listed.

Ledger Settings Tab

The Ledger Settings tab allows you to find basic information about your ledger and interact with it (e.g. rename, pause, or delete the ledger). You can also initialize a ledger or manage subdomains.

Ledger Settings tab showing the General, Subdomains, Initialize, API, and Ledger Actions tiles.

Integrations Tab

Daml Hub integrations available for installation are shown in the Integrations tab. You can install an integration into a ledger by clicking the "Deploy" link for the corresponding integration.

The Integrations tab with integrations for the Daml Chat sample app.

New Services in Beta

A beta version of the three new Daml Hub services is now available to enterprise customers only:

  • Scratchpad service
  • Participant service
  • Synchronizer service

The capabilities of the new participant and synchronizer services allow application builders to create truly distributed applications on Daml Hub. Application users can also use Daml Hub to host their participant node regardless of where the synchronizer for the application they want to connect to is hosted. This reduces the cost and complexity of users managing their own nodes.

A new Daml Hub tier system offers different access levels of to these services. To upgrade, please contact Digital Asset Sales here.. The default quotas for each of the new services by tier are as follows:

Scratchpad Participant Synchronizer
Free 1 - -
Connect 1 2 standard 0 high capacity -
Connect+ 4 3 standard 4 high capacity -
Build 4 3 standard 4 high capacity 4

The table below lists the capacities of the services.

Service CPUs RAM (GB) Storage (GB)
Scratchpad 1 2.6 10 GB
Standard Capacity Participant 1 2.6 10 GB
High Capacity Participant 4 16 50 GB
Synchronizer 1 2.6 10 GB

Note that the new services do not support party tokens and services account tokens. PACs are the recommended type of credentials for use with these services.

To try these new services, log in to Daml Hub and flip the Try the beta toggle in the top navigation bar.

This displays a new layout for the workspace:

The beta workspace with the Scratchpad tab, a file column on the right, and options to add a participant or synchronizer service.

Once the workspace is populated, scratchpads appear in their own tab, while synchronizers and participants appear in a table with synchronizers on the left and participants on the right. The table shows which services are connected and which have no connections.

The beta workspace with the Scratchpad tab, a file column on the right, and the synchronizers/participants table.

Scratchpad service

The scratchpad service consists of one participant node and one synchronizer that are pre-connected. As the name suggests, the scratchpad service is useful for quickly testing and developing Daml applications. The scratchpad service is self-contained; the synchronizer can’t receive connections from other participant nodes. This service is very similar to the old standard capacity ledger.

To create a scratchpad:

  1. Click Create New in the workspace. This opens the Create New Service screen.

The Create New Service screen with nothing selected.

  1. Select Scratchpad in the left column.
  2. If you do not want to use the default name already in the Scratchpad Name field, enter a new name.
  3. Click Submit. The scratchpad appears in your workspace, but it may take a few minutes to become fully operational.

The Create New Service screen with the Scratchpad tile selected, showing a default name and the Cancel/Submit buttons.

To access an existing scratchpad, select the Scratchpad tab in the Workspace. The artifacts currently deployed to your scratchpads are displayed in the Files column on the left of the screen.

The Scratchpad tab with one scratchpad running and no files deployed.

Clicking on the tile for a scratchpad takes you to the Deployments tab for that scratchpad.

To deploy use the Deployments, Live Data, Identities, and Settings screens, see the documentation for the Workspace above.

Participant service

The participant service is a participant node that can connect to synchronizers hosted on Daml Hub or elsewhere. This service allows application operators to distribute nodes to individuals or organizations who want to access the operator's applications. Application users can then easily provision the enterprise-grade infrastructure they need to connect to permissioned Daml applications.

The participant service is available in standard and high capacity. The standard capacity participant service is for testing and developing distributed applications by connecting them to synchronizers. The high capacity participant service is suitable for running and testing production-level distributed applications workloads.

To create a participant:

  1. Click Create New in the Workspace. This opens the Create New Service screen.
  2. Select Participant in the left column.
  3. If you do not want to use the default name already in the Participant Name field, enter a new name.
  4. Choose Standard or High Capacity for the new participant.
  5. Click Submit.

The Create New Service screen with the Participant tile selected, showing a default name, capacity options, and the Cancel/Submit buttons.

The participant appears in your workspace, but it may take a few minutes to become fully operational.

Synchronizer service

The Synchronizer service is a synchronizer (formerly sync domain) that can receive connections from participant nodes hosted on Daml Hub or elsewhere to coordinate, sequence, and guarantee consistency and finality of transactions between participants.

To create a synchronizer:

  1. Click Create New in the Workspace. This opens the Create New Service screen.
  2. Select Synchronizer in the left column.
  3. If you do not want to use the default name already in the Synchronizer Name field, enter a new name.
  4. Click Submit.

The Create New Service screen with the Synchronizer tile selected, showing a default name and the Cancel/Submit buttons.

The synchronizer appears in your workspace, but it may take a few minutes to become fully operational.

Manage connections as a participant owner

Note: once you connect a given participant to a synchronizer, you can disconnect from and reconnect to that synchronizer, but you cannot connect to another synchronizer. To connect to a different synchronizer you must create a new participant.

To connect a participant to a synchronizer you do not own and have not previously connected to:

  1. Copy the participant ID for the participant you want to connect. You can find this at the top right of the Workspace when the participant is selected.
  2. Send that ID to the owner of the synchronizer, and ask for the synchronizer URL.
  3. Once the owner has added you to their allow list and sent back confirmation and the synchronizer URL, go to the Connection tab for the participant.

The Connection tab in its default state.

  1. Enter a unique identifier for the connection in the Connection Name field and the URL of the synchronizer in the Synchronizer URL field
  2. Click Connect.

Once a connection is established, participant and connected synchronizer details appear in this tab. The synchronizer is added to your saved synchronizer list so you can use it for future connections.

The Connection tab with connection details.

To connect your participant to a synchronizer you own or have previously connected to:

  1. Select your participant and go to the Connection tab.
  2. Click Use a saved Synchronizer below the Synchronizer URL field. This reveals a table listing your owned and previously saved synchronizers with their IDs and URLs.
  3. Select a synchronizer and click Connect in that row of the table.

If you own the synchronizer, your participant's details are automatically added to the synchronizer's allow list and now appear in the same row as the synchronizer in the workspace view. It may take a few minutes for the participant status to change to Connected.

The Connection tab with the saved synchronizer list expanded.

To temporarily disconnect your participant from the synchronizer, navigate to the Settings tab for that participant and click Pause. Pausing may take up to several seconds.

To reconnect a paused participation to the synchronizer, click Resume.

To permanently disconnect and delete your participant, navigate to the Settings tab for that participant and click Delete. **Use caution - this action also deletes all artifacts associated with the participant, and cannot be undone **.

To add to the saved synchronizer list:

  1. Navigate to your Account Settings and go to the Saved Synchronizers tab in the left nav bar.

Account Settings -> Saved Synchronizers.

  1. Click Add Synchronizer.
  2. Enter the synchronizer name in the Synchronizer Name field and the URL of the synchronizer in the Synchronizer Url field.
  3. Click Save.

Saved Synchronizers tab with fields for adding a synchronizer to the list.

Manage connections as a synchronizer owner

To receive a connection from an individual participant:

  1. Obtain the participant ID from the participant owner.
  2. Select your synchronizer and go to the Overview tab in the left nav bar.

Synchronizer overview tab

  1. Click Add Participant in the Participants/Allow List section. This takes you to the Add Participant screen.
  2. Enter the participant ID and select a permission level.
  3. Click Submit.

Add Participant screen

  1. Inform the participant owner that they have been added to the allow list and provide them with the synchronizer name and URL so that they can make the connection. You can find the synchronizer name and URL in the Synchronizer Details table on the Overview tab.

You can also make your synchronizer open access, which allows anyone with the synchronizer URL to connect without being added to the allow list individually. An open access synchronizer accepts any new participant and any topology transaction. Use caution - once this option has been enabled, it cannot be turned off.

To make your synchronizer open access:

  1. Select your synchronizer and go to the Settings tab in the left nav bar.
  2. Click Enable in the Allow Open Access section.

Synchronizer Settings tab

To change permissions for a connected participant, select your synchronizer and go to the Overview tab in the left nav bar. Use the Permission Level drop-down in the Allow List to select a permission level. Available permission levels are Submission, Observation, or Disabled.

  • Submission means that the participant can read, write, and confirm transactions, and submit commands through the ledger API
  • Observation means that the participant can read transactions only.
  • Disabled means that the participant cannot read transactions or affect transaction processing in any way.

Account Settings

To reach the Account Settings screen, click on your user name in the upper right corner of the Console and choose " Account Settings" from the drop-down.

Drop-down showing the Account Settings option circled in red.

From Account Settings, you can access the Profile, Ledger History, and Personal Access Credentials tabs. This is formerly where you would access the Site Credentials tab, which is now deprecated.

Profile

The Profile tab provides basic information about your Daml Hub account. It also allows you to copy your account's JSON Web Token (JWT) and choose whether to see pre-release versions of sample apps and integrations in your Workspace and the Integrations tab.

The Profile tab with the fields Name, Email, User ID, Authentication, and Privacy and Settings

Ledger History

The Ledger History tab shows each of your ledgers with its ID, date of creation, status, and the number of events that have occurred on the ledger. You can also pause your ledger(s) from this tab.

The Ledger History tab with information for one ledger

Personal Access Credentials

Personal Access Credentials (PACs) are long-lived, stable credentials that you can configure with human-readable names, set expiration dates, and specific permissions. From these PACs you can generate short-lived access tokens used when making API requests to Daml Hub.

The Credentials tab with one PAC

Note: When you generate a new PAC, you must save the secret associated with the PAC at once. You cannot retrieve the secret once you navigate away from the Personal Access Credentials tab.

Site Credentials (deprecated)

The use of Site Credentials is deprecated, and PACs should be used instead.

Develop Apps On Daml Hub

Daml Models

Daml templates define the data model and the functional features of your application. For more information on Daml and Daml modeling, see An Introduction to Daml.

Automation

Most applications powered by Daml Hub combine Daml templates and automation. You can write automated services in Python or by using Daml Triggers.

Daml Triggers

Daml Triggers allow you to write your app's automated processes in Daml. To deploy a Daml Trigger to Daml Hub, have all of the Daml templates compiled into one model .dar. Have the separate trigger project import this model in the dependencies of daml.yaml.

sdk-version: X.X.X
name: copy-trigger
source: daml
parties:
  - Alice
  - Bob
version: 0.0.1
# trigger-dependencies-begin
dependencies:
  - daml-prim
  - daml-stdlib
  - daml-trigger
  - copy-trigger-model-0.0.1.dar
# trigger-dependencies-end

Execute daml build on the trigger project, then upload both the model .dar and the trigger build separately to your Daml Hub ledger.

For more information on Daml Triggers see Running a Daml Trigger.

For limits on file size for .dar see file size limit above.

Python and JVM Automations

Automations written in Python must be uploaded and deployed in the form of .tar, .tgz, or .tar.gz files. JVM automations must be .jar files. You can read more about how to write and test automations here.

For limits on file size for .tar, .tgz, and .tar.gz, see file size limit above.

Datadog Logging Integration

Setup

Daml Hub supports exporting ledger and automation logs to Datadog for enterprise ledgers. To export them, obtain a Datadog API key and configure your ledger to use it.

To configure your ledger:

  1. Click on a ledger in your workspace to navigate to the ledger view
  2. Open the Integrations tab
  3. Click on the Datadog integrations tile
  4. Paste in your Datadog API key and click submit

Your Datadog instance begins to receive logs for this ledger once Hub validates the API key. Note: As of 6/2/2023, there is a delay between creating a Datadog token and it being usable. You may have to wait briefly between creating the token and setting up your integration in Daml Hub. Until the token is active, using it in Daml Hub to integrate with Datadog results in the error "Error creating datadog integration: Provided Datadog API key did not work"

Which Logs Get Exported?

This Datadog integration exports logs for

  1. The participant, and
  2. Any automations you have deployed and are running

Filtering in Datadog

Once the logs are in Datadog, you can filter by ledger ID, automation ID, or container name - e.g. "participant".

Who Can Export Logs?

Logs can only be exported on high-capacity ledgers, which are only available to Enterprise customers.

Integrations (Legacy)

Note: Daml Hub integrations are a legacy feature in the process of being deprecated.

Integrations are installable modules that allow your app to interact with the outside world by sending and receiving requests from external systems. Once installed in a Daml Hub app, an integration mediates between the Daml Hub ledger and an external system, managing connections to the external system, converting data to and from Daml contracts, and participating fully in the Daml security and permissions model. Integrations are uploaded and deployed as .dit files, and managed through the Daml Hub console. To get started, a standard package of basic integrations is available in the Workspace under After you create a project....

Daml Hub integrations available for installation are shown in the Integrations tab of the ledger view. Click the " Deploy" link for a given integration to install it into a ledger.

The Integrations tab with integrations for the Daml Chat sample app.

Once the integration has been installed into the ledger, the tile updates to show a "View deployment" link that takes you to the Deployment tab for the ledger. This allows instances of that integration to be installed and managed within the ledger.

To enable the deployment of previous versions of an integration, toggle the "Enable Pre-Release Sample Apps and Integrations" switch in Account Settings. If multiple versions of an integration are available, they are listed in a drop-down in the upper right corner of the respective tile. Unless you have a specific reason to do otherwise, it is best to install the latest version, which is the default selection of the drop-down. As you set the drop-down, the tile updates to show information relevant to the selected version. This includes the deployment status of the integration. (Note that it is possible to have multiple versions of the same integration installed, which can be useful when migrating from one version to the next.)

Once an integration is installed, the integration becomes available for deployment on the Deployments tab for the ledger:

The Deployments tab with the Slack integration in the Action Needed section.

Deploying the integration makes its resources available for use. Integrations generally contain a Daml model that represents their data model and integration types that can be deployed to connect the ledger to the outside world. The Daml model bundled within an integration is like any other Daml model installed into a ledger. It is possible to inspect the Daml code for the integration's Daml model, create and inspect contracts defined within that model, and exercise choices on those contracts. (In fact, ledger actions taken on an integration model's contracts are usually the public API for that integration, e.g. Creating a contract to send an outbound message).

The Deployments tab with the Slack integration running.

Once an integration has been installed into a ledger, instances of integration types defined within that integration may be deployed. Clicking on an integration type displays a screen showing configuration options for that integration.

Every integration has two standard configuration fields - a field for a label describing the purpose of the specific integration and a field identifying the ledger party the integration runs as. When running, the integration has only the rights of the "Run As" party - it can only see events relating to the contracts visible to that party and can only exercise choices on behalf of that party. If there is a need for an integration to run as more than a single party, a separate deployment of the integration must be created for each party. Some integrations also allow for additional configuration fields beyond just these two.

Once the integration has been launched, it appears on a list of deployments of that type of integration. Additional deployments (running as different parties or with different configuration settings) can be added by clicking on the Configure New Instance tab. Deployments may also be selected to allow them to be disabled or removed entirely.

There are also options available under "View Details" for inspecting and adjusting the configuration of the integration, viewing the detailed status of the integration, and seeing a technical log of how the integration is operating.

You can view running integrations as listed on the Deployments screen. Clicking on the name of the integration links to the deployment list for that specific integration and the screen for creating new deployments of that type.

For integrations that have inbound webhooks, the URLs of those hooks are visible under the detailed status for that integration deployment.

List of webhooks for a Slack integration deployment.

Core Integrations

Daml Hub ships with two special-purpose core integrations. These are not typical integrations in that they do not strictly integrate with external systems. Instead they are used to solve specific problems without additional code. The first is a periodic timer integration that allows ledger choices to be exercised in response to a periodic timer. The second is a Loopback integration that allows ledger commands to be issued in response to events occurring on the ledger.

Custom Integration Types

If you want to add custom integration types to Daml Hub, either for your own use or for the community, please contact Digital Asset for more details.

App UI

The App UI feature of Daml Hub allows you to provide a frontend for your app by publishing files to be exposed by HTTPS over a ledger-specific subdomain. These files are associated with the underlying ledger, and any access to that ledger by a UI hosted in Daml Hub is authenticated and authorized through Daml Hub itself.

UI assets must be uploaded to Daml Hub and deployed as .zip files. The .zip should contain a single root directory containing an index.html along with the rest of the resources for your UI. As an example, for DABL Chat, the .zip file contains a top-level build/ directory with all the assets for the UI. If there's anything outside that top-level directory or the build/index.html file is missing, the Daml Hub console signals an error when you attempt to upload the UI .zip into the workspace collections. For limits on file size for .zip, see file size limit above. (If you're building with npm, there is no need to include node_modules or the UI sources. The UI .zip file only includes the resources needed for the build output.)

$ unzip -l dablchat-ui-0.2.0.zip
Archive:  dablchat-ui-0.2.0.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  10-23-2020 10:56   build/
      457  10-23-2020 10:56   build/favicon.ico
     2275  10-23-2020 10:56   build/index.html
     1290  10-23-2020 10:56   build/precache-manifest.4b024a2a5462fd8f8b4f3a3c11220b3e.js
    12933  10-23-2020 10:56   build/logo512.png
     1568  10-23-2020 10:56   build/asset-manifest.json
        0  10-23-2020 10:56   build/static/
        0  10-23-2020 10:56   build/static/css/
    19361  10-23-2020 10:56   build/static/css/main.4e40915c.chunk.css.map

  ... elided ...

      496  10-23-2020 10:56   build/manifest.json
     1181  10-23-2020 10:56   build/service-worker.js
       57  10-23-2020 10:56   build/robots.txt
     4452  10-23-2020 10:56   build/logo192.png
---------                     -------
  3825920                     30 files

When your UI Asset is deployed to its associated ledger, you can publish it to a unique subdomain.

Credentials and Tokens in Daml Hub

The tables below will help you understand the credentials and tokens needed when performing actions on Daml Hub or against the ledger or services.

Credentials

The first account token needs to be manually copied from the ‘Copy Account JWT’ button in the Profile tab of Account Settings in the Daml Hub console

Credentials What do the Credentials do? Required Authentication Token Where is this Created in the Console? Works with Ledgers? Works with the New Services? API Link Expiry Time
Personal Access Credentials - Account Mints new account tokens Account token PACs tab in the account settings Y Y Site API: PACs User defined up to 365 days
Personal Access Credentials - User Mints user tokens Account token PACs tab in the account settings Y Y Site API: PACs User defined up to 365 days
Service Account Credentials Mints party tokens Account token Service accounts tab in the identities tab of a ledger Y N Application API: Service Accounts 365 days
Site Credentials (deprecated): use Personal Access Credentials - Account Mints account tokens Account token Site credentials tab in the account settings Y Y
(but they’re deprecated)
None User defined

Tokens / JWTs

Token What it Does Credentials Needed to Mint Daml Hub JWT or Participant JWT Docs Link / API Link Where is this Created in the Console? Expiry Time Notes
Account token Authenticates a Hub account to take Daml Hub platform actions through the site API (or via the console) Personal Access Credentials - Account Daml Hub After the first time use Site API: PACS generateAccessToken Profile tab of the Account Settings ‘Copy Account JWT’ User defined up to 24 hours. Defaults to 24 hours. Used for creating projects, ledgers, services and uploading artifacts to the workspace
User token Authenticates a user on the ledger / participant Personal Access Credentials - User Participant JWT Site API: PACS generateAccessToken Copy the JWT in the identities tab of the ledger / participant User defined up to 24 hours. Defaults to 24 hours. Preferred mechanism for automation when interaction with the Application Api
Ledger party token Authenticates a party against the ledger / participant Service Account Credentials Participant JWT Application API: Service Account saLogin Copy the JWT of the party in the identities tab of the ledger (only in ledgers) 24 hours Less-preferred (but still supported for ledgers) mechanism for automation when interaction with Application Api. User token preferred

User Actions Available

Only the ledger owner/collaborator users have the ability to do administrative things on the participant – the actions available to each are detailed below.

User Type Type of Token Administrative Right Return Own User Identity Retrieve Own User Rights Create/Delete/Modify/View Other Users Create Parties List Parties
Ledger / Service owner User token IdentityProviderAdmin Y Y Y Y Y
Collaborator User token IdentityProviderAdmin Y Y Y Y Y
Standard user User token Y Y N N N

Quotas and Limits on Daml Hub

Ledger Limits

For users on the Daml Hub Free Tier, ledgers are paused after 24 hours of inactivity. The ledger and its deployed artifacts (user websites, automation, and integrations) are suspended. A ledger can be resumed from the workspace at any point within 14 days of the time it is paused.

After 14 consecutive days of inactivity, paused ledgers on the free tier and all of their deployed artifacts are permanently removed.

Component Capacities

The table below lists the capacities of the different ledger sizes and integrations on Daml Hub.

Component CPUs RAM (GB) Storage (GB)
Standard Capacity Ledger 1 2 10 GB
High Capacity Ledger (Large) 6 6 50 GB
High Capacity Ledger (Huge) 6 6 555 GB
Automations (Integrations & Bots) 1 8 n/a
Triggers 1 4 n/a

Standard Capacity and High Capacity Ledgers

Users on the Daml Hub Enterprise tier can manage the capacity of their ledgers from the console. Each Enterprise tier account has one primary account holder, and a given Enterprise primary account holder can have up to three High Capacity ledgers at one time. If you already have three High Capacity ledgers, you must delete one or reset it to standard before creating another.

You can set the ledger capacity at the creation of a new ledger or project by selecting "High Capacity" on the Ledger Details screen.

Detail of the Ledger Details screen, with the Ledger Name and Ledger Size fields shown. High Capacity is selected in the Ledger Size field.

To change the capacity of an existing ledger, use the "Ledger Capacity" drop-down on the Ledger Settings page. Changing the ledger capacity of an existing ledger causes up to ten minutes of downtime for that ledger as it restarts with new settings.

The Ledger Settings page, with the Ledger Capacity field highlighted and Standard selected in that field.

gRPC Request Size Limits

gRPC requests on Daml Hub have a 10MB limit.

This means that:

  • The maximum size of a gRPC request is 10MB
  • The maximum size of a gRPC response is 10MB, and
  • The sequencer only performs computation on transaction trees under 10MB

Because of these limits:

  • The Canton domain sequencer only performs computation on transaction trees under 10 MB.

  • Integrating with other Canton domains/participants that have these limits set to different limits can result in unanticipated gRPC message failures.

To stay within these limits:

  • Any individual contract must be smaller than 10 MB.

    • To achieve this, avoid contracts with large blob data or very large data structures. Blobs can be stored off-ledger and their hashes recorded on the ledger; very large data structures should be split up into multiple contracts.
  • Total transaction tree sizes must also remain smaller than 10MB.

    • To achieve this, keep the number of commands submitted small, and write your Daml so that choice exercises result in a reasonable number of changes.

A primary goal of gRPC size limits is to reduce the memory consumption of the participant/sequencer. The larger the payloads, the more resources get used and the longer the response times. Without a limit, Hub encourages development anti-patterns: if you run into this limit, you are probably not using the system as intended. By design, the platform encourages limiting request sizes.

Additionally, in a Canton-enabled world, even if you increase the size limits on your participant and/or domain, you have no way to increase the size limit on other people's participants and domains. Increasing your size limits is therefore unlikely to produce the desired result.

Batch Size Limitations

The maximum number of individual commands submitted in a single CommandService.Submit or SubmitAndWait call is not limited, but you should target batch sizes between 50–100 commands for optimal performance:

  • Too few commands in one submission increase the overall time to completion.
  • Too many commands in one submission increase the complexity of that command and could lead to command rejection or the issue described in "Transaction Trees".

File Size Limit

The file size limit for all files, including .dar, .dit, .tar, .tgz, .tar.gz, and .zip, is 32 MB.

Daml Hub Rate Limits

Daml Hub imposes rate limits on cluster traffic based on IP address:

  • HTTP Requests to auth endpoints (/auth/) are limited to 500/minute.
  • HTTP Requests to the API (/api/) are limited to 1000/minute.
  • All HTTP requests are limited to 5000/minute.

Requests that exceed this rate limit receive a 429 HTTP error response.

API Docs

You can find detailed Daml Hub API documentation here.

Deploy Apps To Daml Hub

Deployments

After you upload a file to your ledger, it first appears in the "Action Needed" tile of the Deployments tab as a deployed artifact. Here, you are prompted to configure the first instance of that artifact. Daml and UI Asset artifacts only need one instance to be deployed to your ledger, while automation, trigger, or integration artifacts can have multiple running instances.

The Deployments tab with one file in the Action Needed tile.

Deployed artifacts are listed in the Deployments table, which is divided into Your Deployment and Default Deployments. Here you can easily access and manage each artifact's data, instances, code, and settings.

The Deployments table, with five rows in Your Deployments and two in Default Deployments.

Subdomains

Each ledger in the workspace is given a default domain. This is the web address of your application. Enterprise-tier users can also set a ledger's custom subdomain. You can view these domains in the Ledger Settings tab.

The Subdomains section of the Ledger Settings tab.

Custom Subdomains

Daml Hub's Custom Subdomain feature allows you to specify, reserve, and assign custom subdomains to ledgers you own. A custom subdomain is a URL defined by the user with '.daml.app' appended to the URL. Therefore reserving and assigning a subdomain of 'myapp' to your ledger gives your application a URL of 'myapp.daml.app'.

Custom subdomains must consist of lowercase alphanumeric characters, '-', or '.', and must start and end with an alphanumeric character. In the Ledger Settings tab, you can reserve and assign a custom subdomain directly to your ledger. You can also remove or re-assign the custom subdomain at any time.

You can manage all your custom subdomains in the Your Subdomains table on the Subdomains tab of Account Settings. Here, custom subdomains are listed as either reserved or active. When a custom subdomain has the status reserved, it means that you've claimed the domain but it has yet to be assigned to a ledger. When a custom subdomain has the status active, it means that you've claimed the domain and it has been assigned to a ledger.

The Subdomains tab with four subdomains listed in the Your Subdomains table. Three are active and one is reserved.

In the Subdomains tab of Account Settings, you can reserve subdomains, assign them to ledgers, remove them from ledgers, re-assign them to different ledgers, and delete them from your account.

Custom Subdomains is an Enterprise-tier feature only.

Sample Apps

When you first sign in to the Daml Hub console, a selection of sample apps appears at the bottom of the workspace. These are simple Daml Hub applications built by Daml Hub engineers. Deploy them to a ledger to get started with a fully implemented example.

  1. In the Sample Apps section at the bottom of the workspace, pick an app to deploy, then click Deploy.

The Sample Apps section with three sample apps - Daml Chess, Daml Chat, and DA Marketplace.

  1. Click the ledger you just deployed to.

The new Daml Chat ledger.

  1. Go to the Deployments tab. The unconfigured deployment appears under Action Needed. Click Deploy Instance. It takes about two minutes to deploy.

The Deployments tab with Daml Chat listed in the Action Needed section.

  1. Click on each automation row and, within it, click "Configure New Instance". Configure an instance of each automation as the UserAdmin party. You may view the status of these instances in that deployment's instance table.

The screen to configure a new instance of daml-chat-user-bot-2.0.2.tar.gz.

  1. You're live!

Back on the Deployments tab of your ledger, click "View Site" to navigate to a running instance of your app's UI.

The Daml Chat UI.

  1. Explore your app in the Daml Hub console

After deploying your sample app, you can inspect active contracts on the ledger and create new ones from the Live Data tab, upgrade and view your artifacts in the Deployments tab, and learn more about your ledger in Ledger Settings.

If you want to modify a sample app according to your needs, you can find the source code on:

DABL Chat GitHub

OpenWork Board GitHub.

DABL Chess GitHub (coming soon!)

Ledger Initialization with Daml Script

Daml Script is a development tool with a simple API that runs against an actual ledger. Using it with Daml Hub achieves automated and accurate ledger bootstrapping, enabling you to skip manual onboarding and other preliminary logic to initialize the state of your ledger.

Migrate Scenarios to Daml Script

The simplest way to write Daml Script is to use pre-existing scenarios and make simple changes to them. The Daml docs have a migration guide that explains this simple translation. The Daml docs also have a guide for writing Daml Script from scratch, which is very similar to writing scenarios.

Changing the scenario code of your .dar ultimately changes its hash. To avoid this, create a directory containing the project with your Daml models and create a new project in that directory containing a single file for your Daml Script.

Now, copy your scenario code into the single file of your script project. Convert it to Daml Script and import the contracts used in your models, as well as Daml.Script.

In the case of onboarding ledger parties, your Daml Script should include a record containing the ledger parties in your workflow. This record is passed in as the argument for your script. Below is an example of a script that takes parties as input:

  module Setup where

  import Actors.Intern
  import Actors.Analyst
  import Actors.Associate
  import Actors.VicePresident
  import Actors.SeniorVP
  import Actors.ManagingDirector

  import Daml.Script

  data LedgerParties = LedgerParties with
    intern : Party
    analyst : Party
    associate : Party
    vicePresident : Party
    seniorVP : Party
    managingDirector: Party
      deriving (Eq, Show)


  initialize : LedgerParties -> Script ()
  initialize parties = do
    let intern = parties.intern
        analyst = parties.analyst
        associate = parties.associate
        vicePresident = parties.vicePresident
        seniorVP = parties.seniorVP
        managingDirector = parties.managingDirector

    -- continue with the rest of your script's logic...

Configure Your Build With Daml Script

In the daml.yaml file of your script project, add daml-script to the list of dependencies, the ledger parties that you specified as arguments to your script, and under data-dependencies add the name of the corresponding .dar containing your models. You can exclude this line if you are not using a separate project for your script.

sdk-version: 1.3.0
name: bootstrap-script1
source: daml
init-script: Setup:initialize
parties:
  - Intern
  - Analyst
  - Associate
  - VicePresident
  - SeniorVP
  - ManagingDirector
version: 0.0.1
dependencies:
  - daml-prim
  - daml-stdlib
  - daml-script
data-dependencies:
  - ../bootstrap/.daml/dist/bootstrap-0.0.1.dar
sandbox-options:
  - --wall-clock-time

Deploy Your .dar to a Daml Hub Ledger

In the terminal, execute the command daml build in your script project. Then, upload the .dar containing your models to an empty ledger in Daml Hub.

For limits on file size for .dar, see file size limit above.

Download the Script’s Ledger Parties from Daml Hub

Next, add the ledger parties from your script to your ledger in the Parties tab of the Identities screen. All this is doing is initializing parties, so there are no contracts yet.

The Parties tab of the Identities screen, with Default Parties, All Parties, and Your Parties sections.

Now, download these parties and their access tokens to use as inputs to your script. Daml Hub produces a participants.json for you in the Ledger Settings tab.

The Initialize your ledger with Daml Script section of the Ledger Settings tab, with the Participant Config and Ledger Parties fields.

Add the participants.json file to your script project.

Initialize Ledger Inputs

As the final step, create a file named ledger-parties.json in your script project. The JSON here must be formatted [party_name] : value, which is the reverse mapping of the party_participants field in participants.json. Here is an example of the contents of ledger-parties.json:

{
  "intern": "ledger-party-2b645725-41d2-441d-b259-fb8dab0aad11",
  "analyst": "ledger-party-0423c1fe-2287-4bd0-a20b-9624b4005d13",
  "associate": "ledger-party-581594c7-bd48-489b-a62d-9ec79c214cdf",
  "vicePresident": "ledger-party-964ef06c-e7f3-41fe-8517-426797944b00",
  "seniorVP": "ledger-party-0ae3d20a-b418-4b10-a20c-6f9ee0410233",
  "managingDirector": "ledger-party-dab32e1e-c472-4930-96e5-f105c3303cb5"
}

Run the Script Against Your Ledger

Now that you have all the inputs for our Daml Script, you need to run it against the ledger with the following command:

daml script --participant-config participants.json --json-api --dar <Name of .dar that contains the Daml Script> --script-name <Name of Daml Script function> --input-file ledger-parties.json

The command consists of participant-config being the participants.json file, the json-api tag because Daml Hub uses the JSON API, the name of the dar that contains the Daml Script (which in the example would be .daml/dist/bootstrap-script1-0.0.1.dar), the name of the script function (which in the example would be Setup:initialize), and the input file ledger-parties.json.

After running this command, return to your Daml Hub ledger, where you can see the contracts created by the Daml script bootstrap process.

For more details on Daml Script, visit the Daml docs.

Operate and Maintain Apps On Daml Hub

User Management

The User Management service eliminates the need for multi-party tokens and simplifies the assignment of read-as and act-as rights assigned to various parties.

Users and Parties

Parties and users are distinct concepts in Daml - a user can read and act as multiple parties at once.

The easiest way to think about parties and users is by analogy to classical databases: users are analogous to database users, while Daml parties are analogous to database roles. Further, the rights granted to a user are analogous to the user's assigned database roles.

Types of Parties

Daml Hub includes two types of parties: default parties and ledger parties.

Default Parties

Default parties are created automatically when you create a Daml Hub ledger, and are initially the only type shown in the "Parties" zone of the Identities tab. These include the UserAdmin and Public parties and are also referred to as “well-known” parties. They can be used by your Daml Hub application for the convenience of users and administrators. Users of your application (or UI) can find the default party identifiers using the getDefaultParties Endpoint.

The Public party is useful when you want to expose some contracts on the ledger to every user of the application. This is achieved by providing the Public party identifier as an observer to any contract you create that you want to expose publicly. Anyone can fetch a read-only token for the Public party using the getPublicPartyToken Endpoint and use it to query the ledger for public data.

The UserAdmin party grants administration rights and can be used as a ledger operator to help orchestrate administrative workflows, such as onboarding new users and granting any roles or privileges you have defined within your app's Daml models. The UserAdmin’s read/write token is only available to the ledger owner and to collaborators.

Ledger Parties

The parties listed under "Ledger Parties" are the ones created by you, the ledger owner, or on your behalf by any collaborators on your ledger. For more information on ledger parties, refer to the Daml documentation site, specifically Parties and Users On a Daml Ledger.

Manage Parties

Clicking the Add Party button launches the Add Party pop-up, where you can enter an alias for a new ledger party. For the alias, select a unique name that does not contain any special characters.

The Add Party pop-up with a field to enter the new user alias.

Why a User Rather Than a Party?

Acting as a party allows you to only see contracts for that particular party and, depending on rights, to exercise choices on these visible contracts. Creating a user with rights to multiple parties is useful when you want to read or act as multiple parties without repeatedly switching party views.

Party vs. User Examples

The main reason to choose a user rather than a party is for ease and continuity in situations where the rights of individuals may change but a given role remains stable. The general use case is to create users for individuals and add or remove party rights from them as they change roles. To better explain this consider the example below.

User - Alice
User - Bob
User - Charlie
Party - Manager

Alice, Bob and Charlie work for the same company, ACME Corp. They have their own users on the ledger and can act as and read as their own default parties.

Alice and Bob are managers at ACME Corp. and need to be able to see contracts relevant to managers. Go to the Users Zone of the Identities tab and give Alice and Bob’s users the ability to read as the party Manager on the ledger.

Now, suppose that Alice changes roles, so she is no longer a manager and Charlie takes over as the manager. Alice no longer needs to read as the Manager party; Charlie does. From the Users zone of the Identities tab, the read-as right can be removed from Alice’s user and added to Charlie’s user. This ensures that Alice no longer sees the contracts related to managers but Bob and Charlie do.

Another way to employ users is to handle situations where a role incorporates the right to read or act as more than one individual. Here, the individual maps to the party and the user maps to the role. To see this situation in action, consider the following:

Party 1 - Alice
Party 2 - Bob
Party 3 - Bank

Create a number of contracts where Alice, Bob, and the Bank each have their own view on the ledger dependent on rights.

From the Parties zone of the Identities tab, copy the JWT for Alice. Using Alice's token, you can only see or act on contracts where Alice has readAs or actAs permission respectively. Attempting to act as Bob fails.

Now, suppose that Alice and Bob are part of the same household and joint owners of an account. To manage contracts for the entire household, you can create a user called Household which has actAs rights as both Alice and Bob.

Go to the Users zone of the Identities tab and create a new user, Household. Grant actAs Alice and actAs Bob rights to Household. Copy the JWT token for Household and try out CURL command.

You are now able to read and act on contracts for both Alice and Bob.

Manage Users

To add a new user click the Add User button. This launches the Add User pop-up, where you can enter an alias for a new user.

The Add User pop-up with a field to enter the new user alias.

Each user is associated with a primary party created by default at the time of user creation. The newly created user has both the read-as and the act-as rights of the primary party.

To grant the user additional act-as rights, go to the Rights section and click the plus sign icon labeled Associate Party under Act As.

To revoke act-as rights from the user, click the x icon to the right of the party with the rights you are removing.

To grant the user additional read-as rights, go to the Rights section and click the plus sign icon labeled Associate Party under Read As.

To revoke read-as rights from the user, click the x icon to the right of the party with the rights you are removing.

To delete a user entirely, click the Delete User button (bordered in red) next to the user's name.

To grant the user administration rights, add a collaborator following the steps in Collaborators. All collaborators have UserAdmin rights by default.

View and Download Logs

To view logs for an automation that you have deployed or are a collaborator on, go to the Deployments tab and click the arrow at the right of that deployment's row in the Your Deployments table.

The Your Deployments section of the Deployments table, with the arrow icon at the right highlighted.

This opens the Instances screen. So long as at least one instance of the automation has been configured, you can view logs for that instance by clicking "View Details" for that instance.

The Instances screen, with the View Details link at the right highlighted.

From here you can expand the log view or download the logs. You can also jump to the end of the logs if they have expanded beyond the view of a single screen.

The logs view, with the "View Larger" and "Download Logs" buttons visible.

To view logs for a particular participant or domain, click "View Logs" in that deployment's row in the Default Deployments table.

The Default Deployments section of the Deployments table, with the arrow icon at the right highlighted.

This opens the Participant Logs or Domain Logs screen. You can expand the log view or download the logs from this screen. You can also jump to the end of the logs if they have expanded beyond the view of a single screen.

The Participant Logs view, with the "View Ledger", "Download Logs", and "Jump to End" buttons visible.

Ledger Performance

To provide guidance on what to expect from Daml Hub ledgers, here are the results of some intra-cluster load tests.

First, the numbers, followed by an explanation of the methodology. An important detail to note - all throughput numbers target an average latency of 1s:

Ledger Size Test Type Command Submissions* (CS) Events**
Standard gRPC IOU payload 40 CS/s 40 Events/s
Standard gRPC large payload 13 CS/s 13 Events/s
Standard gRPC 18 create events per CS 12 CS/s 213 Events/s
High Capacity gRPC IOU payload 81 CS/s 81 Events/s
High Capacity gRPC large payload 50 CS/s 50 Events/s
High Capacity gRPC 18 create events per CS 17 CS/s 307 Events/s

Methodology

These load tests were run in-cluster; command submissions were made via gRPC. The load tester sent X command submissions per second, increasing X until it reached an average latency for command submissions of one second. It then averaged the rate of command submissions per second for the run.

Standard ledgers are available to free and Enterprise tier users; High Capacity ledgers are available only to Enterprise users.

Definitions

*Command Submission (CS): A command submission is a request sent over the wire containing one or more commands. All command submissions in this test use only one command.

**Events: Each "event" is an individual contract change, such as a create or archive. Multiple events in a command submission were achieved by performing a varying number of creates within a single choice exercise.

Ledger Pruning

Pruning in Daml frees up storage space by deleting archived contracts.

Daml Hub prunes every other hour based on the following rules:

  1. If a ledger’s disk size is less than <usage threshold %> of the disk capacity available to it, no archived contracts are pruned.
  2. If a ledger’s disk usage exceeds <usage threshold %>, the oldest archived contracts are pruned, starting with an < oldest age - 3 days> range.
  3. If a ledger’s disk usage still exceeds <usage threshold %> after the initial pruning, the system continues to prune increasingly smaller time windows, reducing the retention window by one day (90 days, 89 days, 88 days ... down to 1 day) until disk usage is under <usage threshold %>.

The ledger remains available for use during pruning.

Disk sizes and percentage usage thresholds for the different classes of Daml Hub Ledgers are listed below:

Ledger Size DB Disk Size DB Percentage Usage Threshold
small 10GB 30%
medium 20GB 30%
large 50GB 30%
huge 555GB 90%

NOTE: Internally stored objects related to archived contracts within the domain and participant are regularly pruned within a 48hr period, but this does not affect the ability to stream these archived contracts via Ledger API.

Disaster Recovery

Daml Hub takes backups of all ledgers every hour and keeps the last 24 hours of hourly backups, the last backup from every previous day for the past week, and the last backup for the past week for 4 weeks. In the case of a disaster that takes out the persistent layer of the ledgers, Daml Hub recovers from the most recent backup. Ledgers with a large amount of data may take longer than an hour to back up, in which case subsequent backups only start once the previous backup finishes meaning they're backed up less than every hour.

Daml Hub Updates and Releases

Release Classifications

The following table shows the Daml Hub release classifications, the customary notification periods and the scope of the release.

Release Classification Customary Notification Period Impact scope
Critical impact As soon as identified Variable
High impact 5 business days The Daml Hub platform is taken down and the console, ledgers, and all user websites are inaccessible for the duration of the upgrade
Medium impact 2 business days The Daml Hub console remains running, but users’ ledgers may briefly restart and be unavailable for 5–30 minutes; this may also cause automations and triggers to restart
Minimal impact 1 business day The Daml Hub console remains running, but users’ ledgers may briefly restart and be unavailable for up to 5 minutes; this may also cause automations and triggers to restart

Daml Hub aims to keep medium and high-impact releases to a minimum and to apply them at most once a month, only as needed. This may not always be possible when addressing critical issues and security patches.

The release classification and expected impact on customers are included in the release announcement forum post. Most releases have no impact on customer applications because Daml is backward compatible between minor releases and Daml Hub does not deprecate features without appropriate warning. Releases that may necessitate changes to users' applications, for example moving to a new major Daml version, are announced with enough time for customers to plan and implement changes.

New Daml Hub features are announced after the release on the Daml Release Notes blog.

Release Notifications

Releases are announced on the Daml forum using the tag damlhub-release.

To receive email notifications about Daml Hub releases you will need to:

  1. Sign up to the forum with the email address where you'd like to receive the notifications
  2. Filter posts by the daml-hub-releases tag
  3. Click the bell icon and change your notification level to 'Watching'

Early Access Features

Features marked Alpha in the Daml Hub console or the documentation are in a very early stage of their development. Alpha features are not complete and have not been as thoroughly tested as beta or generally available (GA) features. The incomplete aspects may be noted in the documentation. A feature is released in an alpha state to receive feedback from customers as early in the development phase as possible. Users should expect breaking changes in alpha features and should not build the use of alpha features into production applications.

Features marked Beta in the Daml Hub console or the documentation are usually complete but have not been as thoroughly tested as GA features. A feature is released in beta to receive feedback from customers and to continue testing. Users should not build use of beta features into production applications.

To provide feedback on an alpha or beta feature in Daml Hub, please email productfeedback@digitalasset.com.