Domino 4.1

4.1.0 (November 2019)

Domino 4.1 delivers powerful enhancements to enterprise authentication by enabling credential propagation through Domino to other systems that user code interacts with. Domino 4.1 also introduces new options for administrators to manage per-user compute resource consumption, and adds the ability to fully purge data from the Domino file store.

New features

  • Domino 4.1 introduces a full delete operation that allows Domino system administrators to completely remove all instances of a file from the Domino file system. Performing a full delete on a file finds all instances of the file’s contents across all revisions of all projects, erases those contents wherever they appear, and replaces them with a message indicating that the file was subject to a full delete. This will affect all files that have identical contents to the target file, even if they have different filenames. It will not affect files with the same filename if they have different contents.

    To perform a full delete, open the file in question and click the Full Delete button. Full delete can only be performed on one file at a time.


    You will be prompted to supply a commit message before confirming the full delete. The full delete will remove all instances of the file contents from the Domino file system. Note that this operation does not alter the revision history of any of the affected projects. All commits that contained the file contents will continue to exist, but when viewing the file contents within you will only see the full delete message.


    One limitation of full delete is that if any Model APIs have been published from project revisions that contained a file that has been fully deleted, the Model API images will continue to contain that file. There is currently no way to permanently purge that image from Domino. Contact if you have questions about such files.

  • Domino now supports mapping assertions from your SAML identity provider or SSO service to Domino admin roles.

    To automatically assign admin roles to a user, you will need to assert one of the following role values in a SAML attribute statment for that user:

    • SysAdmin
    • Librarian
    • ReadOnlySupportStaff
    • SupportStaff
    • ProjectManager

    Consider this example assertion that could be used to assign a user system admin roles:

    <saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
      <saml2:Attribute Name="DominoSystemRoles">
        <saml2:AttributeValue xsi:type="xs:string">

    Additional instructions on how to finalize these configurations with mappers and enable this feature in the Domino will be available in the Keycloak authencation section of the Domino Administrator’s Guide.

  • Domino now supports mapping assertions from your SAML identity provider or SSO service to Domino organization membership.

    To automatically grant a user membership in a Domino organization, you will need to pass the names of the organizations as values in a SAML attribute statment for that user, such as in the following example.

    <saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
      <saml2:Attribute Name="DominoOrganizations">

    Additional instructions on how to finalize these configurations with mappers and enable this feature in the Domino will be available in the Keycloak authencation section of the Domino Administrator’s Guide.

  • Domino 4.1 introduces the ability to propagate AWS temporary credentials for accessing external systems into Domino run environments. This requires federation from AWS IAM to your SAML identity provider.

    To enable credential propagation for a user, you must pass SAML attributes for that user that define the IAM roles they can assume and configurations for temporary credentials. Domino will then enable automatic requests for temporary credentials when the user signs in, and will load them into an AWS credentials file in the user’s run environments.

    Additional instructions on how to finalize these configurations with mappers and enable this feature in the Domino will be available in the Keycloak authencation section of the Domino Administrator’s Guide.

  • In Domino 4.1 admins can now optionally configure a maximum number of simultaneous executions per user. This can be used to prevent individual users from monopolizing available compute resources. This feature is enabled by default, but can be turned off with the ShortLived.UserExecutionsQuotaEnabled.

    The maximum number of per-user executions is configurable with a new com.cerebro.domino.computegrid.userExecutionsQuota.maximumExecutionsPerUser option in the central config, and it defaults to 25. If a user attempts to start a new execution when already at the limit, the new execution will be queued in a WaitingForResources state until one of their existing executions finishes.


    Executions that remain in a WaitingForResources state for more than 24 hours will be terminated. This timeout is configurable with a new com.cerebro.domino.computegrid.timeouts.sagaStateTimeouts.waitingForResourcesStateTimeoutSeconds option in the central config.

    Note that Model APIs and Web Apps are exempt from these limits, as they are considered long-lived services hosted by Domino and are not treated as variable user demand. Jobs, Scheduled Jobs, and Workspace sessions are subject to the limits.

  • A new option is available in the Executions tab of the admin interface to download a Support Bundle. This option downloads a .zip archive of all logs related to the selected execution, including Domino events logs, Kubernetes deployment logs, and Domino application logs.


  • Hardware tiers now have an Overprovisioning Pods option. This number represents a number of empty pods that will be deployed to the cluster using the hardware tier’s resourcing requests and node pool settings. If overprovisioning pods are present when a new user-launched execution pod is sent to the cluster for assignment, the user’s pod replaces one of the overprovisioning pods.

    Admins can use this feature to build in some automatically reserved capacity for the hardware tier, so that user executions on the hardware tier always have a node with reserved resources ready to go, and users will never have to wait for autoscaling to spin up a new node.


    Additionally, admins can check the Enable Overprovisioning Pods On a Schedule option to limit deployment of overprovisioning pods to a specified range of hours on specified days of the week. When outside the scheduled period, overprovisioning pods will be removed to allow the cluster to scale down. When the scheduled period begins again, overprovisioning pods will be deployed.

    A new com.cerebro.computegrid.periodicProcessing.overprovisioningInterval option has been added to the central config that sets how often Domino checks to see if new overprovisioning pods are needed. This defaults to 600 seconds.

  • Deployment logs for Domino executions are now available in .csv format. Click the (CSV) link to download the new format. Clicking the Deployment logs link will still download the logs in the original JSON format.


  • New API endpoint have been added to enable exporting Docker images of Model APIs built in Domino to external registries. Additional details will be available in the Domino API docs.

  • Added a new `com.cerebro.domino.modelmanager.requestBufferSize option in the central config that controls the maximum size in bytes of a request block to a Domino Model API. This defaults to 8192 and can be set to a value from 1-65535.


  • Improved messages on the Workspace startup page that provide more granular information about the startup process.


  • The Cores limit and Memory limit options have been removed from Domino hardware tiers. Domino now automatically sets the limit values equal to the request values to ensure stable and predictable behavior from Domino execution pods and keep assignment simple and reliable.

  • Fixed an issue where having a large number of published models failing to deploy could cause future attempts to publish new models to fail in deployment scheduling. Published models that fail to deploy and end up in a crash loop will now be automatically unscheduled to improve reliability of scheduling newly published models.

  • Domino 4.1 improves performance, UX responsiveness, and user feedback design in many components across the application.