Skip to main content

Glossary

Terms used in the Dagger documentation, each with a link to the page that covers it.

Artifact​

A part of a project that Dagger makes available as a typed value: source code, containers, binaries, generated files, even tests. Modules discover the artifacts in a project, and Dagger computes them on demand and caches them. Every artifact has a URI, called a DAG link. dagger list lists the artifacts in a workspace by type. See Module wiring.

Cache​

Each engine caches the result of each operation, for example a built container or a compiled binary, so that it does not run the operation again. Dagger also caches function results, keyed by inputs (arguments, parent state, module source). A function cache hit skips the function entirely. See engine.json for how the engine prunes its cache.

Cache volume​

A directory whose contents persist across Dagger sessions, such as a package manager's download cache. A function mounts it into a container. See CacheVolume.

Changeset​

A diff of proposed file changes. A Generator returns one, and so can a function that edits files, such as a formatter's fix. Dagger shows the changed paths and line counts, and nothing is written until the changeset is applied. When a function returns multiple changesets, the CLI merges them and offers one combined apply prompt. See Generating code.

Check​

A function that validates the project: tests, linters, scans, policy. A Check passes or fails, so it can be used as a gate. A module marks it with @check or its SDK's equivalent. dagger check runs every Check in the workspace, locally, in CI, and as Cloud Checks. A stale check finds generated files that are out of date. See Checking your code.

Client​

A program that opens a session with the engine and calls the Dagger API. The Dagger CLI is a client. Other programs become clients through a generated client, a client library, or raw GraphQL. See Client libraries.

In the context of services, a client is any container or program that connects to a service.

Client library​

A plain client library for the core API that each SDK publishes to its language's package registry, such as dagger.io/dagger for Go or @dagger.io/dagger for TypeScript. See Standalone client libraries.

Cloud Checks​

Runs a repository's Checks on Cloud Engines on each push to GitHub or pull request, with no additional CI configuration or third-party service needed. dagger cloud checks on connects the repository to Dagger Cloud. The results show as GitHub check statuses and in Dagger Cloud. See Set up Cloud Checks.

Cloud Engine​

A managed remote engine that Dagger Cloud runs, with scale-out, distributed cache, access control and observability. --engine=cloud runs any pipeline on Cloud Engines, and Cloud Checks run on them.

Collection​

A set of objects with unique keys that a module returns for the units of a project it discovers at run time, such as packages, test files, or config directories. Each collection adds a filter flag to dagger check and dagger generate, such as --go-package, that selects items by key. A collection can also define batch functions, which run once over the selected items. See Collections and Select collection items.

Constructor​

The function that creates a module's main object. Its arguments are the module's settings. See Design your module for wiring.

Core API​

The types and functions the engine provides without any module installed, such as Container, Directory, Secret, and Service. Modules extend it with their own types. See the API reference.

The URI of an artifact, with the dag:// scheme. A DAG link names one artifact with its filters, for example dag://go/packages/tests/test?go-package=store. It works on the command line, in dagger.toml, and in native configuration such as a //go:generate directive. Its first path segment is a module's install name, and the workspace main module's functions omit that segment, as in dag://serve. Also called a DAG address.

dagger check and dagger generate take DAG links to select Checks and Generators. A setting whose value is a DAG link wires in another module's artifact. See Filter checks.

Dagger API​

The GraphQL API that the engine serves. The CLI, modules, Checks, Generators, and services all run on it. It is made of the core API plus the types of the modules a workspace installs. See the API reference.

Dagger Cloud​

Dagger's hosted service. It offers managed remote engines, with scale-out, distributed cache, access control and observability. See Set up Cloud Checks.

Dagger Shell​

The bash-style language for pipelines, run with dagger -c '...' or from a script file. For example, dagger -c 'go | packages | get store | tests | keys' lists the tests in one Go package. See Collections.

dagger-module.toml​

The manifest of a module. It holds the module role of the Dagger 0.x dagger.json. See Migrate from dagger.json.

dagger.toml​

The workspace configuration file. It specifies the modules to load, their settings, SDK scopes, and includes. Dagger reads the nearest dagger.toml above the current directory, up to the workspace root. See dagger.toml.

Dang​

A scripting language designed specifically for Dagger, with a native runtime built into the engine. Dang loads types directly from the engine at runtime, so it needs no codegen and starts almost immediately. All official modules and SDK runtimes are written in Dang. See Dang.

Dev shell​

A shell in any container that a workspace provides, such as a dev environment, a build container or the container that tests run in. dagger shell opens one, and dagger check -i opens one in the exact state where a command failed. See dagger shell.

Engine​

The Dagger Engine serves the Dagger API and runs pipelines. It runs on a local machine, on a server, or as a Cloud Engine, and it stores the cache. The Dagger Engine is open source. See engine.json.

Function​

An operation that a module exposes on one of its objects. It takes typed arguments and returns a value, often another object whose functions can be called next. Checks, Generators, and services are functions with a role in the workspace. See Calling functions.

Generated client​

Code that gives a language typed access to the functions of a module, including the core API and every module it depends on. dagger module client add adds one to an SDK scope, and dagger generate regenerates it. See Generated clients.

Generator​

A function that produces source changes as a reviewable changeset: codegen, formatting, lockfile updates. A module marks it with @generate or its SDK's equivalent. dagger generate runs every Generator in the workspace, and dagger check runs them again to catch stale generated files. See Generating code.

Include​

An [[include]] entry in dagger.toml that inherits another config file. The included config is merged underneath the workspace's own, so the workspace wins every conflict. See Includes.

Install name​

The key a module is installed under in dagger.toml, as in [modules.<name>]. Commands, flags, and DAG links refer to the module by this name, as in dagger check --go and dag://go/packages.

Interface​

A type that lets a module accept any object that has the functions it needs, from a module in any language. See Interfaces in the Go SDK guide.

Lockfile​

The dagger.lock file beside dagger.toml. It pins resolved image, Git, and vanity URL lookups so that later runs reuse them. dagger lock update refreshes the pins. See dagger.lock.

Module​

A reusable, typed API for automation: functions, objects, Checks, services, and Generators that anyone can run from a workspace, in CI, in Cloud, or from an agent. It is a package of code that the Dagger engine can load and execute, written with an SDK and described by dagger-module.toml. A workspace uses a module by installing it. See SDKs.

The docs name a Dagger module by its install name in code font, such as the go module. "Go module" without code font is a Go project defined by a go.mod file. Module in code font is the API type.

Module source​

The address a module is installed from: a local path such as ./ci/myapp, or a Git ref such as github.com/org/mod@v1.0. It is the source of a module entry in dagger.toml. See [modules.<name>].

Module wiring​

Connecting installed modules through settings. A setting whose value is a DAG link injects the value returned by a function on another installed module. This is how generic modules compose without knowing about each other. See Module wiring.

Object​

A type that a module defines, with fields and functions. A module's main object is named after the module and created by its constructor.

Official module​

A module in the catalog that the Dagger team maintains. Each official module integrates Dagger with a common tool, for example Go, pytest, ESLint or Playwright. dagger module recommend examines a repository and recommends the official modules that match. Official modules have short addresses, for example dagger.io/go. See Modules.

Pipeline​

A chain of function calls. Each function returns an object, and the next function is called on that result. See Chain functions.

Remote engine​

An engine that runs on another machine. --engine or DAGGER_ENGINE selects it, for example ssh://, tls://, kube-pod://, or cloud for a Cloud Engine. Dagger streams local files, secrets, network tunnels and the terminal to it as needed. See dagger.

SDK​

The toolkit for writing modules in one language. Each SDK is a Dagger module, such as dagger.io/sdk/go or dagger.io/sdk/dang. An SDK installed in a workspace creates modules with dagger module init and supplies the language-specific generation code. See SDKs.

SDK scope​

A directory where an SDK generates code: a module, generated clients, or both. dagger.toml records each scope under [sdks.<name>.scopes]. See [sdks.<name>].

Secret​

A password, API key or token that a function receives as a Secret, sourced from a provider URI such as env:DEPLOY_TOKEN, file:./token.txt, or vault://secret/foo/bar.token. Secrets are never exposed in logs, written to container filesystems, or inserted into the cache. See Secrets.

Service​

A long-running process such as a database, web server, or proxy. Services run in ephemeral containers. A module function that returns a Service and takes no required arguments is a service of the workspace, and dagger start starts it and tunnels its ports to the local machine. See Running services.

Session​

A connection between a client and the engine. Each dagger command that calls the engine runs in a session, and dagger api with-session starts one for another program. See Standalone client libraries.

Setting​

A value that a workspace sets for an installed module, stored under [modules.<name>.settings] in dagger.toml. Each setting is an argument to the module's constructor. dagger module settings lists and changes them. See Configuring your Workspace.

Toolchain​

The compiler and tools of a language, such as the Go toolchain that a go.mod file asks for. Dagger detects a repository's toolchains and recommends official modules for them. For the Dagger 0.x term, see Toolchain (Dagger 0.x).

Trace​

The record of a run, traced end to end: each function call and operation, with its status, duration and logs, in the terminal and in Dagger Cloud. Each test that an official module runs is a span in the trace.

User configuration​

The file dagger/config.toml in the user config directory, such as ~/.config/dagger/config.toml on Linux, or the file named by $DAGGER_CONFIG. It holds personal module settings for a workspace, keyed by the workspace's Git remote, and merges them on top of dagger.toml. See User configuration.

Workspace​

A context in which Dagger is configured and run, usually one Git repository. Its dagger.toml specifies the modules to load and other settings. Modules access their workspace through the Workspace API: they load files on demand, find projects and read their native configuration. See Configuring your Workspace.

Workspace main​

The installed module marked main = true in dagger.toml. Its functions are hoisted onto the workspace root, so they are called and addressed without the module name. See Reference the workspace main.

Workspace root​

The root of the workspace's Git repository. A path that starts with / in a command or dagger.toml is relative to it.

Dagger 0.x terms​

These terms appear in dagger.json files from Dagger 0.x. See Migrate from dagger.json.

dagger.json​

The Dagger 0.x file that served two roles: a manifest for a module, and a configuration file for a workspace. dagger-module.toml and dagger.toml fill those roles in Dagger 1.0, which can still load dagger.json. dagger workspace migrate and dagger module migrate convert it.

Toolchain (Dagger 0.x)​

A Dagger module that provides ready-to-use functions and checks for common development workflows, installed in a Dagger 0.x dagger.json. dagger workspace migrate migrates each toolchain as a 1.0 module, installs it in dagger.toml, and converts its customizations to settings.

Blueprint​

A module installed in a Dagger 0.x module with dagger init --blueprint, whose functions that module served as its own.