Skip to main content

Overview

A Project is Domino’s unit of organization: the code, data, results, and people for one piece of work. Apps, models, and API endpoints publish from a Project, and governance bundles track the work inside it. Projects carry work from first experiment to production asset.

How it works

Project types

Domino has two types of Projects, distinguished by where your code lives:
  • Git-based Projects store code in a repository at an external Git provider such as GitHub, GitLab, or Bitbucket. You control when work syncs, and you keep access to your provider’s features: pull requests, branch protection, CI integrations.
  • Domino File System (DFS) Projects store code in the Domino File System. Domino versions your files automatically with a Git server it operates in the background, but you don’t get the features of an external Git provider.
Best practice: Use Git-based Projects whenever possible. They give you more control over code synchronization and a more modern development experience. Choose DFS only when your organization’s policies require it.

What’s in a Project

Every Project connects three kinds of content:
  • Code: Each Project has a code repository, available from the Code section of the Project.
  • Data: Connect data sources, Domino Datasets, and external data volumes from the Data section. Data offerings live outside the Project so multiple Projects can share them securely.
  • Artifacts: Files that are neither source code nor data, such as plots, reports, and serialized models. Git-based Projects have a dedicated Artifacts repository for these; DFS Projects store them alongside the code.
Keep bulk data out of the code and artifact repositories. Small data files (less than 1 GB each, or fewer than 50,000 files in total) are fine, but repositories have storage limits and large files slow down future work. Use Datasets or data sources instead; data sources are managed centrally, are shareable across Projects, and get an automatic audit trail.

What a Project produces

A Project is also where work ships from. These assets are created from a Project and stay tied to it, even though they serve users who may never open the Project itself:
  • Apps: web tools built from the Project’s code and published for others to use, with Domino managing infrastructure, permissions, and routing.
  • API endpoints: models from the Project deployed as REST APIs for real-time or batch predictions.
  • Launchers and Scheduled Jobs: self-service forms and recurring runs that execute the Project’s code.
Governance connects to a Project from the outside: a governance bundle originates in a Project and tracks its governable materials, such as models, Apps, API endpoints, files, and agents, against your organization’s policies. Policies define what evidence and approvals each stage requires, and gates can block actions like deploying a model or an App until those approvals are complete.

Versioning and execution

When you change a Project’s files, Domino records a new version. When you run an execution (a workspace, job, or app) from a Project, Domino loads that Project’s files onto the machine that executes it, so every run starts from a known state.

Work with Projects

  • Create Projects: Start a Project from scratch, from a template, or from existing work.
  • Manage Projects: Rename, copy, fork, merge, transfer, export, and archive Projects.
  • Project settings: Configure hardware and environment defaults, visibility, tags, credentials, and notifications.
  • Git-based Projects: How code syncs with your Git provider and how to organize a Git-based Project.
  • DFS Projects: How the Domino File System versions your files, and how to manage them.
  • Files, artifacts, and results: Where Project files live and how to retrieve execution results.
  • Collaborate on Projects: Invite collaborators, set permissions, and discuss work with comments.
  • Track Projects: Use stages, statuses, and the activity feed to move work to production.