# Environments URL: https://docs.dagger.io/config/environments # Environments An environment is a named overlay on top of your workspace configuration. Use environments when the same checks, generators, or services need different settings in different contexts, for example a different base image in `staging` than in `production`. Environments are path prefixes in your workspace configuration (`env..*` in `dagger.toml`). They aren't first-class commands; you create one implicitly by writing to its overlay, list them by inspecting workspace config, and remove one by deleting the keys. ## Apply an environment Pass `--env` to any command to apply an overlay for that run: ```shell dagger --env staging check dagger --env staging api call deploy ``` ## Configure an environment Most per-environment differences are module settings, such as a base image or a package manager. Set them with `dagger settings` and `--env`, which targets that environment's overlay instead of the base configuration: ```shell dagger settings --env staging eslint baseImageAddress node:22-alpine ``` Writing to a setting under `--env=` is also how the environment gets created. The first write creates the overlay; subsequent writes update it. Reads with `--env` show the *effective* view, the base settings with the overlay applied: ```shell dagger settings --env staging eslint ``` Without `--env`, you read and write the base configuration, which every environment inherits. ## Lower-level access `dagger workspace config` is the lower-level key/value interface to `dagger.toml`, and it follows the same `--env` overlay rules. Environment overlays only carry module settings, so the raw key form is: ```shell dagger workspace config env.staging.modules..settings. ``` ## Personal overrides Values that shouldn't be committed, such as private profiles, local paths, and personal clusters, belong in your [user configuration](./user.mdx), which can also define environments of its own on top of the repository's. --- # Configuring your Workspace URL: https://docs.dagger.io/config/index # Configuring your Workspace How a workspace is configured: the settings in `dagger.toml`, how modules connect to each other, and how values change per environment. - [Environments](./environments.mdx) are named overlays for staging, production, and per-developer values. - [User configuration](./user.mdx) holds personal overrides that stay out of the repository. - [Module wiring](./module-wiring.mdx) connects one module's output to another module's settings. - [Migrate from dagger.json](./migrate-dagger-json.mdx) converts a legacy project to a workspace. - [Configuration files](../reference/config-files/index.mdx) has the schemas for the files that configure Dagger. --- # Migrate from dagger.json URL: https://docs.dagger.io/config/migrate-dagger-json # Migrate from dagger.json :::note If you're new to Dagger, you can skip this page. It's for existing users encountering changes. ::: A workspace separates two things that a legacy `dagger.json` used to hold at once: - A module, described by `dagger-module.toml`, is a package of code. - A workspace, described by `dagger.toml`, is your project's Dagger configuration: which modules to use, and how they're configured. ## Run the migration You don't have to migrate right away. Dagger infers a workspace from an existing `dagger.json` and warns you, so your project keeps working. When you're ready: ```shell dagger setup ``` `dagger setup` prompts before each step. Its migration step writes workspace fields into `dagger.toml` and converts module-shaped `dagger.json` files to `dagger-module.toml` in place. It never moves module files, and it touches only the root `dagger.json` plus the local dependencies and toolchains that file references. If anything needs manual attention, it writes `.dagger/migration-report.md`. A few behaviors worth knowing: - If your repo *is* a module, meaning the root `dagger.json` describes a module whose source lives at the repo root, migration converts the config in place and writes a minimal `dagger.toml` that only pins the module's SDK. The module isn't installed into the workspace, so load it explicitly: `dagger -m . call --help`. - Run from a module subdirectory, migration converts just that module and creates no workspace. `dagger.json` becomes `dagger-module.toml` in place, along with any local dependencies it references. Module recommendations are skipped. - Migration never creates nested `dagger.toml` files. It installs toolchains listed in a subdirectory `dagger.json` into the workspace at the repository root and rebases their local source paths. It leaves a subdirectory `dagger.json` with a `blueprint` as legacy, with a warning. - When a `dagger.json` has both an `sdk` and `toolchains`, the toolchains are installed into `dagger.toml` **and** recorded as dependencies in the migrated `dagger-module.toml`. In 0.21 a module could call its toolchains from code the same way as dependencies (for example `dag.Go()`), so this keeps that code working. Remove any dependency the module code does not use. - Modules now commit their generated code (`dagger.gen.go` and friends) instead of regenerating it at runtime. Migration removes the `.gitignore` rules that used to exclude it. Afterwards, run `dagger generate` and commit the output. - Applying a migration ends the setup run. Run `dagger setup` again for module recommendations. ## Where your configuration lands **Toolchains are modules.** Install one with `dagger install github.com/foo/bar` and `dagger.toml` records it. Same functionality, one concept instead of two. **Blueprints are an entrypoint flag.** A workspace module marked `entrypoint = true` plays the role a blueprint used to. **Customizations are settings.** The deprecated `customizations` array becomes `[modules.*.settings]`: ```toml [modules.go] source = "github.com/dagger/go" [modules.go.settings] goVersion = "1.22" ``` **Modules are managed from the top level.** `dagger search` finds them; `dagger install` and `dagger uninstall` update `dagger.toml`. A module's own source metadata lives in `dagger-module.toml`. Edit that file directly when authoring a module or adding code dependencies. ## Workspace arguments in generated Go bindings A `*dagger.Workspace` argument that isn't marked `// +optional` used to be published as optional in the module's API, because Dagger fills it in automatically. It is now published as required, matching the declaration. Nothing changes when you call such a function from the CLI, a check, or a generator — Dagger still supplies the current workspace. What does change is calling that function **from another module's Go code**. The Go SDK puts required arguments in the function signature and optional ones in an `Opts` struct, so after `dagger generate` the workspace moves out of the options struct and into the argument list. Code that used to pass it through `Opts` (or not at all) fails to compile with errors like: ``` unknown field Workspace in struct literal of type dagger.FooOpts cannot use dagger.FooOpts{…} (value of struct type dagger.FooOpts) as *dagger.Workspace value in argument to dag.Foo not enough arguments in call to dag.Foo ``` To fix it, pass the workspace positionally. Take a `*dagger.Workspace` in your own constructor and hand it to the dependency: ```go func New(ws *dagger.Workspace) *MyModule { return &MyModule{Workspace: ws} } func (m *MyModule) Build(ctx context.Context) (string, error) { // Before: dag.Foo(dagger.FooOpts{Workspace: m.Workspace}) // or: dag.Foo() return dag.Foo(m.Workspace).Build(ctx) } ``` If `Foo` has other optional arguments, they stay in the options struct: `dag.Foo(m.Workspace, dagger.FooOpts{...})`. This only surfaces at compile time what was already true at runtime: a workspace is never inherited across a module-to-module call, so a dependency that needs one has to be given it explicitly. ## Quick reference | Before | Now | |---|---| | `dagger -m ` (with toolchains) | `dagger -W ` | | `dagger toolchain install ` | `dagger install ` | | `dagger install ` (module code dependency) | Add the dependency to `[[dependencies]]` in `dagger-module.toml` | | `toolchains` array in `dagger.json` | `[modules.*]` in `dagger.toml` | | `blueprint` in `dagger.json` | `entrypoint = true` in `dagger.toml` | | `customizations` in `dagger.json` | `[modules.*.settings]` in `dagger.toml` | | `.env` for constructor defaults | `[modules.*.settings]` in `dagger.toml` | --- # Module wiring URL: https://docs.dagger.io/config/module-wiring # Module wiring Modules in a workspace connect to each other through settings. A setting whose value is a `":"` string is a module reference. It injects the value returned by a function on another installed module. This is how generic modules compose without knowing about each other, and without you writing a glue module. ## Wire a service into a module A test-runner module accepts an optional `Service`; your app module has a function that returns one. Connect them in `dagger.toml`: ```toml [modules.myapp] source = "./ci/myapp" [modules.playwright] source = "github.com/dagger/playwright" [modules.playwright.settings] service = "myapp:serve" ``` Now `dagger check playwright:test` runs the browser tests against your app. Dagger resolves the reference when it constructs the playwright module and passes the running service in. To find functions you can wire, run `dagger up -l`. It lists every service-returning function in the workspace, in exactly the `module:function` form a setting accepts. Any function returning the right type works, whether or not it appears there. ## Wire a container References aren't limited to services. A `Container` argument wires the same way: ```toml [modules.playwright.settings] baseCtr = "base-images:chromium" ``` ## Wire a file, directory, or workspace Build artifacts and workspaces can be passed between modules in the same way. A function returning a `File`, `Directory`, or `Workspace` can be referenced by a matching constructor argument: ```toml [modules.packager.settings] binary = "builder:binary" assets = "frontend:assets" source = "source-prep:workspace" ``` ## Use a reference on the command line A module reference is an ordinary address string, so it also works as a CLI flag for any object-typed constructor argument: ```shell dagger api call playwright --service=myapp:serve test ``` ## How references resolve - The leading segment is a module's install name, the `[modules.X]` key in this `dagger.toml`. The second segment is a zero-arg function on it whose return type matches the argument. - If the first segment names an installed module, the string *is* a module reference. A missing function or mismatched type is then a hard error, never a silent fallback to an image or URL. If no install name matches, the string keeps its ordinary address meaning: an OCI ref for a `Container`, a `tcp://` URL for a `Service`. - Core names (`host`, `git`, `secret`, `container`, `http`, `module`, and so on) are reserved and never resolve as module references, so `git:2.40` stays an image ref. ## Design your module for wiring If you author modules, wiring changes how you shape a constructor: - **Accept collaborators as optional constructor arguments.** An optional `Service`, `Container`, `File`, `Directory`, or `Workspace` argument is a wiring point. Without one, users need a glue module to connect yours to anything. - **Consume workspaces in the constructor.** A module object cannot retain a `Workspace` as a field. Derive and store the `File`, `Directory`, or other value your module needs from the wired workspace instead. - **Put workspace-level configuration on the constructor, not on function arguments.** Settings map to constructor arguments. A shard count, a service, or a base image belongs there if the workspace should configure it once. - **Degrade gracefully.** When nothing is wired, do something sensible rather than failing: skip the service binding, or fall back to a default image. The workspace may have nothing to wire yet. The [Playwright module](../reference/modules/playwright.mdx) is a worked example of all three. --- # User configuration URL: https://docs.dagger.io/config/user # User configuration Some values shouldn't be committed: private account profiles, local paths, personal development clusters. Those live in your user-level Dagger config file, `~/.config/dagger/config.toml`, or the file named by `$DAGGER_CONFIG`. The file is shared with other Dagger subsystems (such as `[llm]`). Workspace overrides sit in a `[workspaces.*]` section, keyed by the workspace's Git remote: ```toml # Always applied when working in the github.com/acme/api workspace: [workspaces."github.com/acme/api".modules.aws.settings] profile = "alice-dev" # A personal environment, selected with `dagger --env dev ...`: [workspaces."github.com/acme/api".env.dev.modules.aws.settings] region = "us-west-2" ``` ## Merge order Dagger merges the effective configuration in a fixed order: the repository's `dagger.toml`, then your user-level overrides, then the selected [environment](./environments.mdx) overlay. User-level values shadow repository values key by key, and user-level environments add to the repository's, all without modifying `dagger.toml`. ## Writing values You don't have to edit the file by hand. Pass `-g/--global` to `dagger settings` or `dagger workspace config` to store a value user-level instead of in the repository: ```shell dagger settings -g aws profile alice-dev # always applied here dagger settings -g --env dev aws region us-west-2 # personal env overlay dagger settings -g -u aws profile # remove the override dagger workspace config -g modules.aws.settings.profile alice-dev ``` `--global` selects where a write is stored; reads always show the effective merged view. Unsetting with `-g` removes only the user-level value. The repository value underneath is untouched. `-g` also composes with `-W`. A remote workspace is readable but its repository config can't be written, while its user-level overrides live in your local file: ```shell dagger -W https://github.com/acme/api settings -g aws profile alice-dev ``` ## What can be stored Only module settings: `modules..settings.*`, optionally under `env..*`. Because one key spans every branch and clone of a repository, an always-applied entry for a module that doesn't exist in the current checkout is ignored there rather than being an error. User-level environments are validated normally when selected with `--env`. ## Workspace key The key is the normalized `origin` remote: host and path, with no scheme, no user, and no `.git` suffix. Equivalent spellings all match: `git@github.com:acme/api.git`, `https://github.com/acme/api`, and `github.com/acme/api` identify the same workspace, both as the config key and in the repository's git config. A repository with multiple remotes is keyed by `origin` only; a repository with no remote matches no user-level overrides. Remote workspaces selected with `-W` are keyed by their clone address. --- # Set up Cloud Checks URL: https://docs.dagger.io/getting-started/cloud-checks # Set up Cloud Checks In this guide, you will connect your GitHub repository to Dagger Cloud, and run your Checks automatically after each push. Complete the [Quickstart](./quickstart.mdx) before you start. A Git event, such as a push or pull request, starts Cloud Checks. They run your Checks on Cloud Engines. You do not need a CI workflow file. Your project must be a GitHub repository, and its Git `origin` remote must point to that repository. ## Sign in to Dagger Cloud Sign in or create an account: ```shell dagger cloud login ``` Complete the authentication in the browser. Create or select a Dagger Cloud organization when requested. ## Connect the repository Connect the GitHub account or organization that owns the repository: ```shell dagger cloud integration create github --open ``` In the browser, select that account or organization, then grant Dagger access to the repository. ## Enable Cloud Checks From your project root: ```shell dagger cloud check on ``` Dagger gets the repository from the Git `origin` remote. The command prints `on` when Cloud Checks are enabled. ## Trigger Cloud Checks Commit the files that the Quickstart created, then push them: ```shell git add dagger.toml git commit -m "Set up Dagger" git push -u origin HEAD ``` If `dagger generate` changed other files, stage those too. Run `git status --short` to list them. ## Watch the Checks pass The push started your Checks. Watch them run: ```shell dagger activity ``` Find the row for `Set up Dagger`. It can take a moment to appear. Run the command again until its `CHECKS` column is green. If a Check turns red, run `dagger check` locally. Fix the failure. Then commit and push the fix. Green means that every Check passed. ## What you accomplished Your project now checks itself. Every push and every pull request runs your Checks automatically, on Dagger's Cloud Engines. You did not write a CI workflow file. You do not maintain a build server. The Checks that run on each push are the same Checks that `dagger check` runs on your machine, so the two cannot drift apart. ## Next steps - [Run selected Checks](../using/checking.mdx) - [Manage Cloud Checks from the CLI](../reference/cli/index.mdx#dagger-cloud-check) --- # Install the Dagger CLI URL: https://docs.dagger.io/getting-started/install import { daggerVersion } from '../partials/version.js'; Use the command for your operating system. Each command installs Dagger v{daggerVersion}. {`curl -fsSL https://dl.dagger.io/dagger/install.sh | DAGGER_VERSION=${daggerVersion} BIN_DIR=/usr/local/bin sh`} If you cannot write to `/usr/local/bin`, run the script with `sudo -E`: {`curl -fsSL https://dl.dagger.io/dagger/install.sh | DAGGER_VERSION=${daggerVersion} BIN_DIR=/usr/local/bin sudo -E sh`} {`curl -fsSL https://dl.dagger.io/dagger/install.sh | DAGGER_VERSION=${daggerVersion} BIN_DIR=$HOME/.local/bin sh`} Verify that `$HOME/.local/bin` is in your `PATH`. To install Dagger for all users, run the script with `sudo -E`: {`curl -fsSL https://dl.dagger.io/dagger/install.sh | DAGGER_VERSION=${daggerVersion} BIN_DIR=/usr/local/bin sudo -E sh`} In PowerShell 7 or later: {`iwr -useb https://dl.dagger.io/dagger/install.ps1 | iex; Install-Dagger -DaggerVersion ${daggerVersion} -AddToPath`} This installs `dagger.exe` in `%USERPROFILE%\dagger` and adds it to your user `PATH`. Run this command to verify the installation: {`dagger version\n# version: v${daggerVersion}`} To change the Dagger version, run the applicable install command again. Specify the required version. --- # Introduction URL: https://docs.dagger.io/getting-started/introduction # Introduction Dagger is the missing software stack for CI. It makes your pipelines faster and more repeatable, not by throwing bigger machines at them, but by replacing artisanal scripts with a clean API, real code, and a portable DAG execution engine. Once daggerized, your pipeline logic is decoupled from its environment. Trigger it before or after push; run it locally or let our cloud scale it out; spin up multi-container environments just in time; all cached automatically, traced end to end, and extensible in your favorite language. --- # Quickstart URL: https://docs.dagger.io/getting-started/quickstart # Quickstart In this guide, you will create a basic Dagger configuration for your project, and run your first Checks locally. Complete [Try Dagger](./try-dagger.mdx) before you start. Dagger configures the project that you run it in. Run every command in this guide from your project root. ## Install modules Scan the project for suitable modules: ```shell dagger setup ``` Select the modules that match your project. Then select **Install selected**. The first install creates `dagger.toml` at the repository root. This file holds the workspace configuration for everyone who uses the repository. If Dagger migrates an old configuration, run `dagger setup` again. ### If setup finds no modules If Dagger reports `No recommendations`, search for a module by the name of a tool in your project. For example, if the project uses ESLint: ```shell dagger search eslint dagger install github.com/dagger/eslint ``` ## Configure modules Most modules use suitable default settings. List the available settings: ```shell dagger settings ``` Change a setting when the default does not match the project. For example, if you installed ESLint and the project uses Yarn: ```shell dagger settings eslint packageManager yarn ``` Settings are stored in `dagger.toml`, so they apply to all users of the workspace. ## Run Generators and Checks List the workspace Generators: ```shell dagger generate -l ``` If the list is not empty, run them: ```shell dagger generate ``` Review the changes. Apply them when requested. List the Checks: ```shell dagger check -l ``` If no Check validates your project, install another suitable module. If at least one does, run the Checks: ```shell dagger check ``` You are done when at least one Check runs and all Checks pass. --- # Try Dagger URL: https://docs.dagger.io/getting-started/try-dagger # Try Dagger In this guide, you will add a Check to an example project. You will fix a failure and run the Check successfully. ## Requirements - [Dagger CLI](./install.mdx) - [Git](https://git-scm.com/downloads) ## Clone the example project Clone the repository and open its directory: ```shell git clone --depth 1 https://github.com/dagger/hello-dagger.git cd hello-dagger ``` ## Add a Check Install the official Prettier module: ```shell dagger install github.com/dagger/prettier ``` The command creates `dagger.toml`. It also adds `prettier:check` to the workspace. ## Run the Check ```shell dagger check ``` `prettier:check` reports unformatted files. The command exits with an error. ## Fix the formatting Run Prettier and apply its changeset: ```shell dagger api call prettier write -y ``` ## Verify the result Run the Check again: ```shell dagger check ``` You are done when the output shows that `prettier:check` passed. --- Here is an example call for this Dagger Function: ```shell dagger -c version ``` ```shell title="First type 'dagger' for interactive mode." version ``` ```shell dagger api call version ``` The result will be: ```shell VERSION_ID=3.14.0 ``` --- :::note This page documents an upcoming release of Dagger. This release is currently experimental and should not be considered production-ready. If you arrived at this page by accident, you can [return to the official documentation](../index.mdx). ::: --- Volume caching involves caching specific parts of the filesystem and reusing them on subsequent function calls if they are unchanged. This is especially useful when dealing with package managers such as `npm`, `maven`, `pip` and similar. Since these dependencies are usually locked to specific versions in the application's manifest, re-downloading them on every session is inefficient and time-consuming. The `CacheVolume` type represents a directory whose contents persist across Dagger sessions. By using a cache volume for dependencies, Dagger can reuse the cached contents across Dagger workflow runs and reduce execution time. --- The `Container` type represents the state of an OCI-compatible container. This `Container` object is not merely a string referencing an image on a remote registry. It is the actual state of a container, managed by the Dagger Engine, and passed to a Dagger Function's code as if it were just another variable. --- The `CurrentModule` type provides capabilities to introspect the Dagger Function's module and interface between the current execution environment and the Dagger API. --- Dagger Functions do not have access to the filesystem of the host you invoke the Dagger Function from (i.e. the host you execute a CLI command like `dagger` from). Instead, host files and directories need to be explicitly passed as command-line arguments to Dagger Functions. There are two important reasons for this. - Reproducibility: By providing a call-time mechanism to define and control the files available to a Dagger Function, Dagger guards against creating hidden dependencies on ambient properties of the host filesystem that could change at any moment. - Security: By forcing you to explicitly specify which host files and directories a Dagger Function "sees" on every call, Dagger ensures that you're always 100% in control. This reduces the risk of third-party Dagger Functions gaining access to your data. The `Directory` type represents the state of a directory. This could be either a local directory path or a remote Git reference. --- The `Env` type represents an environment consisting of inputs and desired outputs, for use by an `LLM`. For example, an environment might provide a `Directory`, a `Container`, a custom module, and a string variable as inputs, and request a `Container` as output. --- The `File` type represents a single file. --- The `GitRepository` type represents a Git repository. --- The `LLM` type initializes a Large Language Model (LLM). :::tip `ENV` TYPE You use an `LLM` in conjunction with `Env`. The `Env` type is used to represent the environment in which an LLM operates. It allows the LLM to interact with inputs and outputs, such as directories, containers, and custom modules. ::: --- Dagger allows you to utilize confidential information ("secrets") such as passwords, API keys, SSH keys and so on, without exposing those secrets in plaintext logs, writing them into the filesystem of containers you're building, or inserting them into the cache. The `Secret` type is used to represent these secret values. --- The `Service` type represents a content-addressed service providing TCP connectivity. --- # Address URL: https://docs.dagger.io/reference/api/address {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # AgentGroup URL: https://docs.dagger.io/reference/api/agent-group {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Agent URL: https://docs.dagger.io/reference/api/agent {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # All types URL: https://docs.dagger.io/reference/api/all import ApiTypeList from "@site/src/components/api/ApiTypeList"; Every published core API type has a reference page generated from the Dagger GraphQL schema. --- # CacheVolume URL: https://docs.dagger.io/reference/api/cache-volume import CacheVolumeType from "@daggerTypes/_cache-volume.mdx"; import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Changeset URL: https://docs.dagger.io/reference/api/changeset {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # CheckGroup URL: https://docs.dagger.io/reference/api/check-group {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Check URL: https://docs.dagger.io/reference/api/check {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # ClientFilesyncMirror URL: https://docs.dagger.io/reference/api/client-filesync-mirror {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Cloud URL: https://docs.dagger.io/reference/api/cloud {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Container URL: https://docs.dagger.io/reference/api/container import Tabs from "@theme/Tabs"; import TabItem from "@theme/TabItem"; import ContainerType from "@daggerTypes/_container.mdx"; import ApiType from "@site/src/components/api/ApiType"; ## Default addresses It is possible to assign a default address for a `Container` argument in a Dagger Function. Dagger will automatically use this default address to pull the container image when no value is specified for the argument. :::tip Default addresses are only available for `Container` arguments. They are commonly used to provide a sensible default base image for build or test operations. When a value is explicitly passed for the argument, it always overrides the default address. ::: Here's an example: The default address is set by adding a `defaultAddress` pragma on the corresponding Dagger Function `ctr` argument. ```go file=./snippets/default-address/go/main.go ``` The default address is set by adding a `DefaultAddress` annotation on the corresponding Dagger Function `ctr` argument. ```python file=./snippets/default-address/python/main.py ``` The default address is set by adding an `@argument` decorator with a `defaultAddress` parameter on the corresponding Dagger Function `ctr` argument. ```typescript file=./snippets/default-address/typescript/index.ts ``` The default address is set by adding a `#[DefaultAddress]` Attribute on the corresponding Dagger Function `ctr` argument. ```php file=./snippets/default-address/php/src/MyModule.php ``` The default address can be any valid container image reference, such as: - `alpine:latest` - Docker Hub image with tag - `alpine:3.19` - Docker Hub image with specific version - `ghcr.io/owner/image:tag` - GitHub Container Registry image - `gcr.io/project/image:tag` - Google Container Registry image ## Volatile variables `withVolatileVariable` sets a non-secret environment variable for future `withExec` calls without invalidating exec cache when only the variable's value changes. Typical examples include CI and reporting metadata such as commit SHAs, branch or ref names, and CI run IDs. :::warning `withVolatileVariable` is an expert-only escape hatch. Use it only when you are certain that changing the variable alone must not invalidate cached `withExec` results. If that assumption is wrong, Dagger may reuse stale or incorrect cached results. ::: Unlike `withEnvVariable`, volatile variables: - are visible only to future `withExec` calls - are not persisted into the container image config - are not returned by `envVariable` or `envVariables` - are not available to `expand: true` Use `withEnvVariable` for normal container configuration, `withSecretVariable` for sensitive values, and `withVolatileVariable` only for exec-time metadata that should not decide cache reuse. ## API reference --- # CurrentModuleAsSDKClient URL: https://docs.dagger.io/reference/api/current-module-as-sdk-client {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # CurrentModuleAsSDKModule URL: https://docs.dagger.io/reference/api/current-module-as-sdk-module {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # CurrentModuleAsSDK URL: https://docs.dagger.io/reference/api/current-module-as-sdk {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # CurrentModule URL: https://docs.dagger.io/reference/api/current-module import CurrentModuleType from "@daggerTypes/_current-module.mdx"; import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # DiffStat URL: https://docs.dagger.io/reference/api/diff-stat {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Directory URL: https://docs.dagger.io/reference/api/directory import Directory from '@daggerTypes/_directory.mdx'; import ApiType from "@site/src/components/api/ApiType"; ## Reading workspace files Inside a module, you don't take the user's project directory as a function argument. Instead, your module's constructor receives a [`Workspace`](../sdks/index.mdx#developer-workflow) that Dagger auto-populates from the current workspace, and you read directories and files from it lazily with `Workspace.directory(path)` and `Workspace.file(path)` — nothing is uploaded until a function actually uses it. See your [SDK guide](../sdks/index.mdx) for the exact syntax. ## Filters When you pass a directory to a Dagger Function as argument, Dagger uploads everything in that directory tree to the Dagger Engine. For large monorepos or directories containing large-sized files, this can significantly slow down your Dagger Function while filesystem contents are transferred. To mitigate this problem, Dagger lets you apply filters to control which files and directories are uploaded. Dagger offers pre- and post-call filtering to mitigate this problem and optimize how your directories are handled. Filtering improves the performance of your Dagger Functions in three ways: - It reduces the size of the files being transferred from the host to the Dagger Engine, allowing the upload step to complete faster. - It ensures that minor unrelated changes in the source directory don't invalidate Dagger's build cache. - It enables different use-cases, such as setting up component/feature/service-specific workflows for monorepos. It is worth noting that Dagger already uses caching to optimize file uploads. Subsequent calls to a Dagger Function will only upload files that have changed since the preceding call. Filtering is an additional optimization that you can apply to improve the performance of your Dagger Function. ### Pre-call filtering Pre-call filtering means that a directory is filtered before it's uploaded to the Dagger Engine container. This is useful for: - Large monorepos. Typically your Dagger Function only operates on a subset of the monorepo, representing a specific component or feature. Uploading the entire worktree imposes a prohibitive cost. - Large files, such as audio/video files and other binary content. These files take time to upload. If they're not directly relevant, you'll usually want your Dagger Function to ignore them. :::tip The `.git` directory is a good example of both these cases. It contains a lot of data, including large binary objects, and for projects with a long version history, it can sometimes be larger than your actual source code. ::: - Dependencies. If you're developing locally, you'll typically have your project dependencies installed locally: `node_modules` (Node.js), `.venv` (Python), `vendor` (PHP) and so on. When you call your Dagger Function locally, Dagger will upload all these installed dependencies as well. This is both bad practice and inefficient. Typically, you'll want your Dagger Function to ignore locally-installed dependencies and only operate on the project source code. :::note Dagger Functions are not aware of the host filesystem, so they cannot automatically read exclusion patterns from existing `.dockerignore` or `.gitignore` files. You need to manually implement the same patterns in your Dagger Function. At the time of writing, Dagger [does not read exclusion patterns from existing `.dockerignore`/`.gitignore` files](https://github.com/dagger/dagger/issues/6627). If you already use these files, you'll need to manually implement the same patterns in your Dagger Function. ::: To implement a pre-call filter in your Dagger Function, add an `ignore` parameter to your `Directory` argument. The `ignore` parameter follows the [`.gitignore` syntax](https://git-scm.com/docs/gitignore). Some important points to keep in mind are: - The order of arguments is significant: the pattern `"**", "!**"` includes everything but `"!**", "**"` excludes everything. - Prefixing a path with `!` negates a previous ignore: the pattern `"!foo"` has no effect, since nothing is previously ignored, while the pattern `"**", "!foo"` excludes everything except `foo`. Here's an example of a Dagger Function that excludes everything in a given directory except Go source code files: ```go file=./snippets/fs-filters/pre-call/go/main.go ``` Here's an example of a Dagger Function that excludes everything in a given directory except Python source code files: ```python file=./snippets/fs-filters/pre-call/python/main.py ``` Here's an example of a Dagger Function that excludes everything in a given directory except TypeScript source code files: ```typescript file=./snippets/fs-filters/pre-call/typescript/index.ts ``` Here's an example of a Dagger Function that excludes everything in a given directory except PHP source code files: ```php file=./snippets/fs-filters/pre-call/php/src/MyModule.php ``` Here's an example of a Dagger Function that excludes everything in a given directory except Java source code files: ```java file=./snippets/fs-filters/pre-call/java/MyModule.java ``` Here are a few examples of useful patterns: ```go // exclude Go tests and test data // +ignore=["**_test.go", "**/testdata/**"] // exclude binaries // +ignore=["bin"] // exclude Python dependencies // +ignore=["**/.venv", "**/__pycache__"] // exclude Node.js dependencies // +ignore=["**/node_modules"] // exclude Git metadata // +ignore=[".git", "**/.gitignore"] ```` You can also split them into multiple lines: ```go // +ignore=[ // "**_test.go", // "**/testdata/**" // ] ```` ```python # exclude Pytest tests and test data Ignore(["tests/", ".pytest_cache"]) # exclude binaries Ignore(["bin"]) # exclude Python dependencies Ignore(["**/.venv", "**/__pycache__"]) # exclude Node.js dependencies Ignore(["**/node_modules"]) # exclude Git metadata Ignore([".git", "**/.gitignore"]) ```` ```typescript // exclude Mocha tests @argument({ ignore: ["**.spec.ts"] }) // exclude binaries @argument({ ignore: ["bin"] }) // exclude Python dependencies @argument({ ignore: ["**/.venv", "**/__pycache__"] }) // exclude Node.js dependencies @argument({ ignore: ["**/node_modules"] }) // exclude Git metadata @argument({ ignore: [".git", "**/.gitignore"] }) ```` ```php // exclude PHPUnit tests and test data #[Ignore('tests/', '.phpunit.cache', '.phpunit.result.cache')] // exclude binaries #[Ignore('bin')] // exclude Composer dependencies #[Ignore('vendor/')] // exclude Node.js dependencies #[Ignore('**/node_modules')] // exclude Git metadata #[Ignore('.git/', '**/.gitignore')] ```` ```java // exclude Java tests and test data @Ignore({"src/test"}) // exclude binaries @Ignore({"bin"}) // exclude Python dependencies @Ignore({"**/.venv", "**/__pycache__"}) // exclude Node.js dependencies @Ignore({"**/node_modules"}) // exclude Git metadata @Ignore({".git", "**/.gitignore"}) ```` ### Post-call filtering Post-call filtering means that a directory is filtered after it's uploaded to the Dagger Engine. This is useful when working with directories that are modified "in place" by a Dagger Function. When building an application, your Dagger Function might modify the source directory during the build by adding new files to it. A post-call filter allows you to use that directory in another operation, only fetching the new files and ignoring the old ones. A good example of this is a multi-stage build. Imagine a Dagger Function that reads and builds an application from source, placing the compiled binaries in a new sub-directory (stage 1). Instead of then transferring everything to the final container image for distribution (stage 2), you could use a post-call filter to transfer only the compiled files. To implement a post-call filter in your Dagger Function, use the `DirectoryWithDirectoryOpts` or `ContainerWithDirectoryOpts` structs, which support `Include` and `Exclude` patterns for `Directory` objects. Here's an example: ```go file=./snippets/fs-filters/post-call/go/main.go ``` To implement a post-call filter in your Dagger Function, use the `include` and `exclude` parameters when working with `Directory` objects. Here's an example: ```python file=./snippets/fs-filters/post-call/python/main.py ``` To implement a post-call filter in your Dagger Function, use the `include` and `exclude` parameters when working with `Directory` objects. Here's an example: ```typescript file=./snippets/fs-filters/post-call/typescript/index.ts ``` To implement a post-call filter in your Dagger Function, use the `include` and `exclude` parameters when working with `Directory` objects. Here's an example: ```php file=./snippets/fs-filters/post-call/php/src/MyModule.php ``` To implement a post-call filter in your Dagger Function, use the `Container.WithDirectoryArguments` class which support `withInclude` and `withExclude` functions when working with `Directory` objects. Here's an example: ```java file=./snippets/fs-filters/post-call/java/MyModule.java ``` Here are a few examples of useful patterns: ```go // exclude all Markdown files dirOpts := dagger.ContainerWithDirectoryOpts{ Exclude: "*.md*", } // include only the build output directory dirOpts := dagger.ContainerWithDirectoryOpts{ Include: "build", } // include only ZIP files dirOpts := dagger.DirectoryWithDirectoryOpts{ Include: "\*.zip", } // exclude Git metadata dirOpts := dagger.DirectoryWithDirectoryOpts{ Exclude: "\*.git", } ```` ```python # exclude all Markdown files dir_opts = {"exclude": ["*.md*"]} # include only the build output directory dir_opts = {"include": ["build"]} # include only ZIP files dir_opts = {"include": ["*.zip"]} # exclude Git metadata dir_opts = {"exclude": ["*.git"]} ``` ```typescript // exclude all Markdown files const dirOpts = { exclude: ["*.md*"] } // include only the build output directory const dirOpts = { include: ["build"] } // include only ZIP files const dirOpts = { include: ["*.zip"] } // exclude Git metadata const dirOpts = { exclude: ["*.git"] } ``` ```php // exclude all Markdown files $dirOpts = ['exclude' => ['*.md*']]; // include only the build output directory $dirOpts = ['include' => ['build']]; // include only ZIP files $dirOpts = ['include' => ['*.zip']]; // exclude Git metadata $dirOpts = ['exclude' => ['*.git']]; ``` ```java // exclude all Markdown files var dirOpts = new Container.WithDirectoryArguments() .withExclude(List.of("*.md*")); // include only the build output directory var dirOpts = new Container.WithDirectoryArguments() .withInclude(List.of("build")); // include only ZIP files var dirOpts = new Container.WithDirectoryArguments() .withInclude(List.of("*.zip")); // exclude Git metadata var dirOpts = new Container.WithDirectoryArguments() .withExclude(List.of("*.git")); ``` ### Mounts When working with directories and files, you can choose whether to copy or mount them in the containers created by your Dagger Function. The Dagger API provides the following methods: - `Container.withDirectory()` returns a container plus a directory written at the given path - `Container.withFile()` returns a container plus a file written at the given path - `Container.withMountedDirectory()` returns a container plus a directory mounted at the given path - `Container.withMountedFile()` returns a container plus a file mounted at the given path Mounts only take effect within your workflow invocation; they are not copied to, or included, in the final image. In addition, any changes to mounted files and/or directories will only be reflected in the target directory and not in the mount sources. :::tip Besides helping with the final image size, mounts are more performant and resource-efficient. The rule of thumb should be to always use mounts where possible. ::: ## Debugging ### Using logs Both Dagger Cloud and the Dagger TUI provide detailed information on the patterns Dagger uses to filter your directory uploads - look for the upload step in the TUI logs or Trace: ![Dagger TUI](/img/current_docs/reference/api/fs-filters-tui.png) ![Dagger Cloud Trace](/img/current_docs/reference/api/fs-filters-trace.png) ### Inspecting directory contents Another way to debug how directories are being filtered is to create a function that receives a `Directory` as input, and returns the same `Directory`: ```go func (m *MyModule) Debug( ctx context.Context, // +ignore=["*", "!analytics"] source *dagger.Directory, ) *dagger.Directory { return source } ```` ```python @function async def foo( self, source: Annotated[ dagger.Directory, Ignore(["*", "!analytics"]) ], ) -> dagger.Directory: return source ``` ```typescript @func() debug( @argument({ ignore: ["*", "!analytics"] }) source: Directory, ): Directory { return source } ``` ```php #[DaggerFunction] public function debug( #[Ignore('*'/, '!analytics')] Directory $source, ): Directory { return $source; } ``` ```java @Function public Directory debug(@Ignore({"*", "!analytics"}) Directory source) { return source; } ``` Calling the function will show you the directory’s digest and top level entries. The digest is content addressed, so it changes if there are changes in the contents of the directory. Looking at the entries field you may be able to spot an interloper: ` You can open the directory in an interactive terminal to inspect the filesystem: You can export the filtered directory to your host and check it with local tools: ## API reference --- # EngineCacheEntrySet URL: https://docs.dagger.io/reference/api/engine-cache-entry-set {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # EngineCacheEntry URL: https://docs.dagger.io/reference/api/engine-cache-entry {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # EngineCache URL: https://docs.dagger.io/reference/api/engine-cache {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Engine URL: https://docs.dagger.io/reference/api/engine {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # EnumTypeDef URL: https://docs.dagger.io/reference/api/enum-type-def {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # EnumValueTypeDef URL: https://docs.dagger.io/reference/api/enum-value-type-def {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # EnvFile URL: https://docs.dagger.io/reference/api/env-file {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # EnvVariable URL: https://docs.dagger.io/reference/api/env-variable {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # ErrorValue URL: https://docs.dagger.io/reference/api/error-value {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Error URL: https://docs.dagger.io/reference/api/error {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Exportable URL: https://docs.dagger.io/reference/api/exportable {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # FieldTypeDef URL: https://docs.dagger.io/reference/api/field-type-def {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # File URL: https://docs.dagger.io/reference/api/file import FileType from "@daggerTypes/_file.mdx"; import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # FunctionArg URL: https://docs.dagger.io/reference/api/function-arg {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # FunctionCallArgValue URL: https://docs.dagger.io/reference/api/function-call-arg-value {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # FunctionCall URL: https://docs.dagger.io/reference/api/function-call {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Function URL: https://docs.dagger.io/reference/api/function {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # GeneratedCode URL: https://docs.dagger.io/reference/api/generated-code {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # GeneratorGroup URL: https://docs.dagger.io/reference/api/generator-group {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Generator URL: https://docs.dagger.io/reference/api/generator {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # GitBundleRef URL: https://docs.dagger.io/reference/api/git-bundle-ref {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # GitBundle URL: https://docs.dagger.io/reference/api/git-bundle {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # GitCommit URL: https://docs.dagger.io/reference/api/git-commit {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # GitRef URL: https://docs.dagger.io/reference/api/git-ref {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # GitRepository URL: https://docs.dagger.io/reference/api/git-repository import GitRepositoryType from "@daggerTypes/_git-repository.mdx"; import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # HealthcheckConfig URL: https://docs.dagger.io/reference/api/healthcheck-config {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Host URL: https://docs.dagger.io/reference/api/host {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # HTTPState URL: https://docs.dagger.io/reference/api/http-state {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # API URL: https://docs.dagger.io/reference/api/index The CLI, modules, checks, generators, and services all run on one GraphQL API served by the engine. In addition to basic types (string, boolean, integer, arrays...), the Dagger API also provides powerful types which you can use as both arguments and return values for Dagger Functions. Each type page combines hand-curated guidance, when available, with a complete schema-generated API reference. The sidebar highlights commonly used core API types; see [All types](all.mdx) for the complete generated list. To call the API from your own program, see [Client libraries](../client-libraries/index.mdx). The following table highlights commonly used types: | Type | Description | |------|-------------| | [`CacheVolume`](cache-volume.mdx) | A directory whose contents persist across runs | | [`Container`](container.mdx) | An OCI-compatible container | | [`CurrentModule`](current-module.mdx) | The current Dagger module and its context | | [`Engine`](engine.mdx) | The Dagger Engine configuration and state | | [`Directory`](directory.mdx) | A directory (local path or Git reference) | | [`EnvVariable`](env-variable.mdx) | An environment variable name and value | | [`File`](file.mdx) | A file | | [`GitRepository`](git-repository.mdx) | A Git repository | | [`GitRef`](git-ref.mdx) | A Git reference (tag, branch, or commit) | | [`Host`](host.mdx) | The Dagger host environment | | [`LLM`](llm.mdx) | A Large Language Model (LLM) | | [`Module`](module.mdx) | A Dagger module | | [`Port`](port.mdx) | A port exposed by a container | | [`Secret`](secret.mdx) | A secret credential like a password, access token or key) | | [`Service`](service.mdx) | A content-addressed service providing TCP connectivity | | [`Socket`](socket.mdx) | A Unix or TCP/IP socket that can be mounted into a container | | [`Terminal`](terminal.mdx) | An interactive terminal session | :::tip In addition to the default Dagger types, you can create and add your own custom types to Dagger. These custom types can be used in Dagger modules and can be composed with other types to create complex workflows. Learn more about [creating custom types and developing Dagger modules](../sdks/index.mdx). ::: --- # InputTypeDef URL: https://docs.dagger.io/reference/api/input-type-def {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # InterfaceTypeDef URL: https://docs.dagger.io/reference/api/interface-type-def {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # JSONValue URL: https://docs.dagger.io/reference/api/json-value {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Label URL: https://docs.dagger.io/reference/api/label {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # ListTypeDef URL: https://docs.dagger.io/reference/api/list-type-def {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # LLMContentBlock URL: https://docs.dagger.io/reference/api/llm-content-block {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # LLMMessage URL: https://docs.dagger.io/reference/api/llm-message {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # LLMSkill URL: https://docs.dagger.io/reference/api/llm-skill {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # LLMTokenUsage URL: https://docs.dagger.io/reference/api/llm-token-usage {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # LLM URL: https://docs.dagger.io/reference/api/llm import LlmType from "@daggerTypes/_llm.mdx"; import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # ModuleConfigClient URL: https://docs.dagger.io/reference/api/module-config-client {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # ModuleSource URL: https://docs.dagger.io/reference/api/module-source {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Module URL: https://docs.dagger.io/reference/api/module {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Node URL: https://docs.dagger.io/reference/api/node {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # ObjectTypeDef URL: https://docs.dagger.io/reference/api/object-type-def {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Port URL: https://docs.dagger.io/reference/api/port {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Query URL: https://docs.dagger.io/reference/api/query {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # RemoteGitMirror URL: https://docs.dagger.io/reference/api/remote-git-mirror {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # ScalarTypeDef URL: https://docs.dagger.io/reference/api/scalar-type-def {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Schema URL: https://docs.dagger.io/reference/api/schema {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # SDKConfig URL: https://docs.dagger.io/reference/api/sdk-config {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # SearchResult URL: https://docs.dagger.io/reference/api/search-result {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # SearchSubmatch URL: https://docs.dagger.io/reference/api/search-submatch {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Secret URL: https://docs.dagger.io/reference/api/secret import SecretType from "@daggerTypes/_secret.mdx"; import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Service URL: https://docs.dagger.io/reference/api/service import ServiceType from "@daggerTypes/_service.mdx"; import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Socket URL: https://docs.dagger.io/reference/api/socket {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # SourceMap URL: https://docs.dagger.io/reference/api/source-map {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Stat URL: https://docs.dagger.io/reference/api/stat {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Syncer URL: https://docs.dagger.io/reference/api/syncer {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # TerminalGroup URL: https://docs.dagger.io/reference/api/terminal-group {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # TerminalTarget URL: https://docs.dagger.io/reference/api/terminal-target {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Terminal URL: https://docs.dagger.io/reference/api/terminal {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # TypeDef URL: https://docs.dagger.io/reference/api/type-def {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # UpGroup URL: https://docs.dagger.io/reference/api/up-group {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Up URL: https://docs.dagger.io/reference/api/up {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Volume URL: https://docs.dagger.io/reference/api/volume {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # WorkspaceGit URL: https://docs.dagger.io/reference/api/workspace-git {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # WorkspaceMigrationStep URL: https://docs.dagger.io/reference/api/workspace-migration-step {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # WorkspaceMigration URL: https://docs.dagger.io/reference/api/workspace-migration {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # WorkspaceModuleSetting URL: https://docs.dagger.io/reference/api/workspace-module-setting {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # WorkspaceModule URL: https://docs.dagger.io/reference/api/workspace-module {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # WorkspaceSDK URL: https://docs.dagger.io/reference/api/workspace-sdk {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # Workspace URL: https://docs.dagger.io/reference/api/workspace {/* Generated by plugins/dagger-api-reference/generate-stubs.js — do not edit. Content comes from docs-graphql/schema.graphqls; edit the schema. */} import ApiType from "@site/src/components/api/ApiType"; ## API reference --- # CLI reference URL: https://docs.dagger.io/reference/cli/index ## dagger A tool to run composable workflows in containers ``` dagger [options] [subcommand | file...] ``` ### Options ``` --allow-llm strings List of URLs of remote modules allowed to access LLM APIs, or 'all' to bypass restrictions for the entire session -y, --auto-apply Automatically apply changes when a changeset is returned -c, --command string Execute a dagger shell command -d, --debug Show debug logs and full verbosity --eager-runtime load module runtime eagerly --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -m, --load-module string Use a one-off module (local path or git ref) --model string LLM model to use (e.g., 'claude-sonnet-4-5', 'gpt-4.1') -E, --no-exit Leave the TUI running after completion -M, --no-load-module Don't load any module for this command --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger activity](#dagger-activity) - Show recent activity (runs, traces, etc.) for this workspace * [dagger agent](#dagger-agent) - Compose your installed agent modules and drop into an interactive prompt. * [dagger api](#dagger-api) - Interact with the Dagger API (advanced) * [dagger check](#dagger-check) - Verify your project — tests, linters, type checks, security scans, etc. * [dagger cloud](#dagger-cloud) - Manage Dagger Cloud * [dagger generate](#dagger-generate) - Generate derived files for your project — code, SDKs, types, docs, etc. * [dagger install](#dagger-install) - Install a module into your workspace * [dagger installed](#dagger-installed) - List installed modules * [dagger llm](#dagger-llm) - Manage LLM configuration * [dagger module](#dagger-module) - Author a module: edit dependencies, engine version, etc. * [dagger sdk](#dagger-sdk) - Install and manage SDKs (the modules that author other modules) * [dagger search](#dagger-search) - Search for modules you can install * [dagger settings](#dagger-settings) - Get, set, or unset module settings (use --env for an env overlay) * [dagger setup](#dagger-setup) - Ensure Dagger is properly set up and operational in the workspace * [dagger terminal](#dagger-terminal) - Open a terminal for a container or directory in your project * [dagger uninstall](#dagger-uninstall) - Uninstall a module from your workspace * [dagger up](#dagger-up) - Run your project's services for local development — databases, APIs, dev servers, etc. * [dagger update](#dagger-update) - Refresh installed-module state * [dagger version](#dagger-version) - Print dagger version * [dagger workspace](#dagger-workspace) - Inspect or configure your workspace (cwd, remotes, config, etc.) ## dagger activity Show recent activity (runs, traces, etc.) for this workspace ``` dagger activity ``` ### Options ``` -a, --all Show activity from all remotes in the current workspace ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers ## dagger agent Compose your installed agent modules and drop into an interactive prompt. ### Synopsis Compose your installed agent modules — their tools and system prompts — onto a base LLM, and drop into the interactive prompt with them all live. Each installed module that exposes an @agent function contributes its toolset and system prompt. With no arguments, every installed agent is composed, in alphabetical order. Name one or more agents to compose only those. Examples: dagger agent # Compose all installed agents and start the prompt dagger agent -l # List all available agents dagger agent editor dagger-go # Compose only the 'editor' and 'dagger-go' agents dagger agent -r # Resume a saved session (interactive picker) dagger agent -r=<session> # Resume a specific saved session ``` dagger agent [options] [name...] ``` ### Options ``` -l, --list List available agents -r, --resume session[=picker] Resume a saved session (interactive picker if no id given) ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers ## dagger api Interact with the Dagger API (advanced) ### Synopsis Every Dagger command — check, up, generate, even install — ultimately runs against a GraphQL API served by the Dagger engine, combining Dagger's core types with schema extensions loaded from modules. The "api" group surfaces direct access for scripting and advanced automation. Most users will never type these commands. See https://docs.dagger.io/api for the full overview. ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers * [dagger api call](#dagger-api-call) - Call one or more functions, interconnected into a pipeline * [dagger api client](#dagger-api-client) - Manage generated API clients * [dagger api functions](#dagger-api-functions) - List available functions * [dagger api query](#dagger-api-query) - Send API queries to a dagger engine * [dagger api with-session](#dagger-api-with-session) - Run a command with a connected Dagger API session (DAGGER_SESSION_PORT/TOKEN injected) ## dagger api call Call one or more functions, interconnected into a pipeline ``` dagger api call [options] [function]... ``` ### Options ``` --allow-llm strings List of URLs of remote modules allowed to access LLM APIs, or 'all' to bypass restrictions for the entire session --eager-runtime load module runtime eagerly -j, --json Present result as JSON -m, --load-module string Use a one-off module (local path or git ref) -M, --no-load-module Don't load any module for this command -o, --output string Save the result to a local file or directory ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger api](#dagger-api) - Interact with the Dagger API (advanced) ## dagger api client Manage generated API clients ### Synopsis Manage generated API clients for workspace modules. Generated clients are persistent typed bindings to the API surface exposed by one selected module. Client state is recorded in dagger.toml under the SDK module that generates it. ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger api](#dagger-api) - Interact with the Dagger API (advanced) * [dagger api client init](#dagger-api-client-init) - Initialize a generated API client * [dagger api client list](#dagger-api-client-list) - List generated API clients ## dagger api client init Initialize a generated API client ### Synopsis Initialize a generated API client at <path>. <path> is relative to the current directory; a leading "/" means the workspace root. <sdk> is an SDK installed in this workspace. Run `dagger sdk install ` to add more choices. The engine resolves <sdk> from dagger.toml, validates that it is installed as an SDK, plans the generated files and workspace config change, then returns a Changeset that the CLI previews and applies through the standard preview/apply flow. The SDK's generators run scoped to <path>, so the client's bindings come with it. Pass --no-generate to record and scaffold the client without them. ``` dagger api client init ``` ### Examples ``` dagger api client init typescript ./lib/cli .dagger/modules/api ``` ### Options ``` --no-generate Skip running the SDK's generators for the new client ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger api client](#dagger-api-client) - Manage generated API clients ## dagger api client list List generated API clients ``` dagger api client list ``` ### Options ``` --json Output the client list in JSON format ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger api client](#dagger-api-client) - Manage generated API clients ## dagger api functions List available functions ### Synopsis List available functions in a module. This is similar to `dagger api call --help`, but only focused on showing the available functions. Examples: dagger api functions # List top-level functions in current workspace dagger api functions container # List functions on container dagger -m core api functions # List core functions dagger -W github.com/acme/ws api functions # List top-level functions in explicit workspace dagger -W github.com/acme/ws api functions container from ``` dagger api functions [options] [function]... ``` ### Options ``` --allow-llm strings List of URLs of remote modules allowed to access LLM APIs, or 'all' to bypass restrictions for the entire session --eager-runtime load module runtime eagerly -m, --load-module string Use a one-off module (local path or git ref) ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger api](#dagger-api) - Interact with the Dagger API (advanced) ## dagger api query Send API queries to a dagger engine ### Synopsis Send API queries to a dagger engine. When no document file is provided, reads query from standard input. Can optionally provide the GraphQL operation name if there are multiple queries in the document. ``` dagger api query [options] [operation] ``` ### Examples ``` dagger api query <... ``` ### Examples ``` dagger api with-session go run main.go dagger api with-session node index.mjs dagger api with-session python main.py ``` ### Options ``` --cleanup-timeout duration max duration to wait between SIGTERM and SIGKILL on interrupt (default 10s) --focus Only show output for focused commands. ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger api](#dagger-api) - Interact with the Dagger API (advanced) ## dagger check Verify your project — tests, linters, type checks, security scans, etc. ### Synopsis Verify your project — tests, linters, type checks, security scans, etc. Examples: dagger check # Run all checks dagger check -l # List all available checks dagger check go:lint # Run the go:lint check and any subchecks dagger check --skip '**e2e' # Run all checks except those matching '**e2e' dagger -W github.com/acme/ws check go:lint # Run check(s) against explicit workspace ``` dagger check [options] [pattern...] ``` ### Options ``` --allow-llm strings List of URLs of remote modules allowed to access LLM APIs, or 'all' to bypass restrictions for the entire session --eager-runtime load module runtime eagerly --failfast Cancel remaining checks on first failure --generate Only run generate-as-checks, skip annotated check functions -l, --list List available checks -m, --load-module string Use a one-off module (local path or git ref) --no-generate Only run annotated check functions, skip generate-as-checks --skip stringArray Skip checks matching the specified patterns ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers ## dagger cloud Manage Dagger Cloud ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers * [dagger cloud billing](#dagger-cloud-billing) - Manage Dagger Cloud billing * [dagger cloud check](#dagger-cloud-check) - Manage Cloud-side automated checks for this workspace * [dagger cloud integration](#dagger-cloud-integration) - Manage Dagger Cloud integration providers * [dagger cloud login](#dagger-cloud-login) - Log in to Dagger Cloud * [dagger cloud logout](#dagger-cloud-logout) - Log out from Dagger Cloud * [dagger cloud logs](#dagger-cloud-logs) - Print the full logs for a Dagger Cloud trace, or a check/test/span within it * [dagger cloud org](#dagger-cloud-org) - Manage Dagger Cloud organizations * [dagger cloud rerun](#dagger-cloud-rerun) - Re-run checks on Dagger Cloud for the current commit ## dagger cloud billing Manage Dagger Cloud billing ``` dagger cloud billing ``` ### Options ``` --json Print JSON output ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud](#dagger-cloud) - Manage Dagger Cloud * [dagger cloud billing manage](#dagger-cloud-billing-manage) - Open the billing portal for a Dagger Cloud org * [dagger cloud billing plans](#dagger-cloud-billing-plans) - List Dagger Cloud plans available at signup ## dagger cloud billing manage Open the billing portal for a Dagger Cloud org ``` dagger cloud billing manage [org] ``` ### Options ``` --open Open the billing portal in a browser ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") --json Print JSON output -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud billing](#dagger-cloud-billing) - Manage Dagger Cloud billing ## dagger cloud billing plans List Dagger Cloud plans available at signup ``` dagger cloud billing plans ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") --json Print JSON output -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud billing](#dagger-cloud-billing) - Manage Dagger Cloud billing ## dagger cloud check Manage Cloud-side automated checks for this workspace ``` dagger cloud check ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud](#dagger-cloud) - Manage Dagger Cloud * [dagger cloud check list](#dagger-cloud-check-list) - List Cloud-side checks for this workspace * [dagger cloud check off](#dagger-cloud-check-off) - Disable a Cloud-side check (by name; defaults to the workspace remote's default check) * [dagger cloud check on](#dagger-cloud-check-on) - Enable a Cloud-side check (by name; defaults to the workspace remote's default check) * [dagger cloud check status](#dagger-cloud-check-status) - Show the status of a Cloud-side check (by name; defaults to the workspace remote's default check) ## dagger cloud check list List Cloud-side checks for this workspace ``` dagger cloud check list [version] ``` ### Options ``` --failed Only list failed checks ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud check](#dagger-cloud-check) - Manage Cloud-side automated checks for this workspace ## dagger cloud check off Disable a Cloud-side check (by name; defaults to the workspace remote's default check) ``` dagger cloud check off [name] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud check](#dagger-cloud-check) - Manage Cloud-side automated checks for this workspace ## dagger cloud check on Enable a Cloud-side check (by name; defaults to the workspace remote's default check) ``` dagger cloud check on [name] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud check](#dagger-cloud-check) - Manage Cloud-side automated checks for this workspace ## dagger cloud check status Show the status of a Cloud-side check (by name; defaults to the workspace remote's default check) ``` dagger cloud check status [name] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud check](#dagger-cloud-check) - Manage Cloud-side automated checks for this workspace ## dagger cloud integration Manage Dagger Cloud integration providers ``` dagger cloud integration ``` ### Options ``` --json Print JSON output ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud](#dagger-cloud) - Manage Dagger Cloud * [dagger cloud integration create](#dagger-cloud-integration-create) - Create a new integration of the given provider type * [dagger cloud integration list](#dagger-cloud-integration-list) - List configured integrations (optionally filtered by provider type) * [dagger cloud integration rm](#dagger-cloud-integration-rm) - Remove a configured integration ## dagger cloud integration create Create a new integration of the given provider type ``` dagger cloud integration create ``` ### Examples ``` dagger cloud integration create github ``` ### Options ``` --open Open the setup URL in a browser ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") --json Print JSON output -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud integration](#dagger-cloud-integration) - Manage Dagger Cloud integration providers ## dagger cloud integration list List configured integrations (optionally filtered by provider type) ``` dagger cloud integration list [type] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") --json Print JSON output -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud integration](#dagger-cloud-integration) - Manage Dagger Cloud integration providers ## dagger cloud integration rm Remove a configured integration ``` dagger cloud integration rm ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") --json Print JSON output -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud integration](#dagger-cloud-integration) - Manage Dagger Cloud integration providers ## dagger cloud login Log in to Dagger Cloud ``` dagger cloud login [options] [org] ``` ### Options ``` --switch-account Choose a different Dagger Cloud account ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud](#dagger-cloud) - Manage Dagger Cloud ## dagger cloud logout Log out from Dagger Cloud ``` dagger cloud logout ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud](#dagger-cloud) - Manage Dagger Cloud ## dagger cloud logs Print the full logs for a Dagger Cloud trace, or a check/test/span within it ### Synopsis Stream the full logs for a trace. Use this as a follow-up to 'dagger trace' to inspect a failure in detail, addressing it by name rather than an opaque span ID. Redirect to a file to grep large logs in a controlled way: dagger cloud logs <trace-id> --check build:lint -o span.log grep -i error span.log With no --span/--check/--test, the whole trace's logs are streamed. --check and --test roll up their subtree; --span is just that span (add --descendants to roll up its subtree too). ``` dagger cloud logs [--span | --check | --test ] ``` ### Options ``` --check string Read a check's logs, by name (rolls up its subtree) --descendants With --span, roll up the span's subtree logs too -o, --output string Write logs to a file instead of stdout --span string Read just this span's logs, by span ID --test string Read a test's logs, by name (rolls up its subtree) --timeout duration Max time to spend streaming logs (default 2m0s) ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud](#dagger-cloud) - Manage Dagger Cloud ## dagger cloud org Manage Dagger Cloud organizations ``` dagger cloud org [flags] ``` ### Options ``` --json Print JSON output ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud](#dagger-cloud) - Manage Dagger Cloud * [dagger cloud org info](#dagger-cloud-org-info) - Show Dagger Cloud organization status * [dagger cloud org list](#dagger-cloud-org-list) - List Dagger Cloud organizations * [dagger cloud org use](#dagger-cloud-org-use) - Select the current Dagger Cloud organization ## dagger cloud org info Show Dagger Cloud organization status ``` dagger cloud org info [org] [flags] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") --json Print JSON output -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud org](#dagger-cloud-org) - Manage Dagger Cloud organizations ## dagger cloud org list List Dagger Cloud organizations ``` dagger cloud org list [flags] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") --json Print JSON output -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud org](#dagger-cloud-org) - Manage Dagger Cloud organizations ## dagger cloud org use Select the current Dagger Cloud organization ``` dagger cloud org use [flags] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") --json Print JSON output -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud org](#dagger-cloud-org) - Manage Dagger Cloud organizations ## dagger cloud rerun Re-run checks on Dagger Cloud for the current commit ### Synopsis Re-run checks on Dagger Cloud, against the commit CI already ran on. By default this targets the commit at the current HEAD (matched by SHA, falling back to the branch or PR it belongs to) and re-runs the checks that failed. Pass --check to pick specific checks by name, --all to re-run everything, or --commit/--pr to target a different commit. Only outermost checks can be re-run; sub-checks run as part of their parent check, so name the parent (e.g. "ci:bootstrap", not "ci:bootstrap:lint"). This re-runs a check that already exists in Cloud for the commit. If CI hasn't run on the commit yet there's nothing to re-run -- use 'dagger check' to run checks locally against your working tree. ``` dagger cloud rerun [--check NAME ...] [--failed | --all] ``` ### Options ``` --all Re-run every check, including ones that passed --check stringArray Re-run a specific check by name (repeatable; outermost checks only) --clean-slate Re-run without reusing cache (experimental; requires an org feature) --commit string Target a specific commit SHA instead of the current HEAD --dry-run Show which checks would be re-run without triggering anything --failed Re-run the failed checks (the default when no --check is given) --json Print JSON output --pr string Target a specific pull request number ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger cloud](#dagger-cloud) - Manage Dagger Cloud ## dagger generate Generate derived files for your project — code, SDKs, types, docs, etc. ### Synopsis Generate derived files for your project — code, SDKs, types, docs, etc. Examples: dagger generate # Generate all assets dagger generate -l # List all available generators dagger generate --no-apply # Show generated changes without applying them dagger generate go:bin # Generate by selecting the generator function dagger -W github.com/acme/ws generate go:bin # Generate against explicit workspace ``` dagger generate [options] [pattern...] ``` ### Options ``` -l, --list List available generators --no-apply Compute and show a summary of generated changes without applying them --require-load Fail if any workspace module cannot be loaded (default: report as a warning and generate the rest) ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers ## dagger install Install a module into your workspace ### Synopsis Install a module into the current workspace. If no workspace config is selected, this creates one at the workspace root first. Use --here to create the workspace config at the workspace cwd instead. With --env the module is recorded in that env's overlay (env.<name>.modules.*) and the env is created if missing. ``` dagger install [options] ``` ### Examples ``` dagger install github.com/shykes/daggerverse/hello@v0.3.0 ``` ### Options ``` --here Write workspace config at the selected workspace cwd -n, --name string Name to use for the module in the workspace. Defaults to the name of the module being installed. ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers ## dagger installed List installed modules ``` dagger installed ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers ## dagger llm Manage LLM configuration ### Synopsis Manage LLM provider configuration, API keys, and default models. ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers * [dagger llm add-key](#dagger-llm-add-key) - Add or update API key for a provider * [dagger llm config](#dagger-llm-config) - Display current LLM configuration * [dagger llm remove-key](#dagger-llm-remove-key) - Remove API key for a provider * [dagger llm reset](#dagger-llm-reset) - Reset LLM configuration (removes all stored credentials) * [dagger llm set-default](#dagger-llm-set-default) - Set default provider and optionally model * [dagger llm setup](#dagger-llm-setup) - Configure LLM authentication interactively * [dagger llm show-config](#dagger-llm-show-config) - Show raw LLM configuration (JSON) ## dagger llm add-key Add or update API key for a provider ### Synopsis Add or update API key for a provider. Supported providers: - openrouter: Unified access to 100+ models (https://openrouter.ai/keys) - anthropic: Claude models (https://console.anthropic.com/settings/keys) - openai: GPT models (https://platform.openai.com/api-keys) - google: Gemini models (https://aistudio.google.com/app/apikey) ``` dagger llm add-key ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger llm](#dagger-llm) - Manage LLM configuration ## dagger llm config Display current LLM configuration ``` dagger llm config ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger llm](#dagger-llm) - Manage LLM configuration ## dagger llm remove-key Remove API key for a provider ``` dagger llm remove-key ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger llm](#dagger-llm) - Manage LLM configuration ## dagger llm reset Reset LLM configuration (removes all stored credentials) ``` dagger llm reset ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger llm](#dagger-llm) - Manage LLM configuration ## dagger llm set-default Set default provider and optionally model ``` dagger llm set-default [model] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger llm](#dagger-llm) - Manage LLM configuration ## dagger llm setup Configure LLM authentication interactively ``` dagger llm setup ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger llm](#dagger-llm) - Manage LLM configuration ## dagger llm show-config Show raw LLM configuration (JSON) ``` dagger llm show-config ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger llm](#dagger-llm) - Manage LLM configuration ## dagger module Author a module: edit dependencies, engine version, etc. ### Synopsis Author a module: edit dependencies, engine version, etc. Operates on the dagger-module.toml reachable from the current directory. ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers * [dagger module deps](#dagger-module-deps) - Manage this module's dependencies * [dagger module engine](#dagger-module-engine) - Manage this module's required engine version * [dagger module init](#dagger-module-init) - Initialize a new module in the current workspace * [dagger module sdk](#dagger-module-sdk) - Run SDK-specific commands against this module's SDK ## dagger module deps Manage this module's dependencies ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger module](#dagger-module) - Author a module: edit dependencies, engine version, etc. * [dagger module deps add](#dagger-module-deps-add) - Add one or more dependencies to the module * [dagger module deps list](#dagger-module-deps-list) - List the current module's dependencies * [dagger module deps rm](#dagger-module-deps-rm) - Remove one or more dependencies from the module * [dagger module deps update](#dagger-module-deps-update) - Update one or more module dependencies ## dagger module deps add Add one or more dependencies to the module ``` dagger module deps add ... [flags] ``` ### Examples ``` dagger module deps add github.com/dagger/dagger/modules/wolfi ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger module deps](#dagger-module-deps) - Manage this module's dependencies ## dagger module deps list List the current module's dependencies ``` dagger module deps list [flags] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger module deps](#dagger-module-deps) - Manage this module's dependencies ## dagger module deps rm Remove one or more dependencies from the module ``` dagger module deps rm ... [flags] ``` ### Examples ``` dagger module deps rm wolfi ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger module deps](#dagger-module-deps) - Manage this module's dependencies ## dagger module deps update Update one or more module dependencies ### Synopsis Update one or more module dependencies. With no arguments, updates all non-local dependencies. ``` dagger module deps update [module]... [flags] ``` ### Examples ``` dagger module deps update wolfi@v0.20.2 ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger module deps](#dagger-module-deps) - Manage this module's dependencies ## dagger module engine Manage this module's required engine version ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger module](#dagger-module) - Author a module: edit dependencies, engine version, etc. * [dagger module engine require](#dagger-module-engine-require) - Set the module's required engine version * [dagger module engine require-current](#dagger-module-engine-require-current) - Set the module's required engine version to the currently running engine version * [dagger module engine require-latest](#dagger-module-engine-require-latest) - Set the module's required engine version to the latest released version * [dagger module engine required](#dagger-module-engine-required) - Print the module's required engine version ## dagger module engine require Set the module's required engine version ``` dagger module engine require [flags] ``` ### Examples ``` dagger module engine require v0.21.0 ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger module engine](#dagger-module-engine) - Manage this module's required engine version ## dagger module engine require-current Set the module's required engine version to the currently running engine version ``` dagger module engine require-current [flags] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger module engine](#dagger-module-engine) - Manage this module's required engine version ## dagger module engine require-latest Set the module's required engine version to the latest released version ``` dagger module engine require-latest [flags] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger module engine](#dagger-module-engine) - Manage this module's required engine version ## dagger module engine required Print the module's required engine version ``` dagger module engine required [flags] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger module engine](#dagger-module-engine) - Manage this module's required engine version ## dagger module init Initialize a new module in the current workspace ### Synopsis Initialize a new module in the workspace. <sdk> is an SDK installed in this workspace. Run `dagger sdk install ` to add more choices. The CLI is a thin wrapper around the engine's Workspace.withInitModule. The engine validates that <sdk> is installed as an SDK in dagger.toml and returns an updated workspace that the CLI previews and exports. What the engine does (atomically, in one Changeset): 1. Resolves <sdk> to an installed SDK entry and requires its as-sdk marker. 2. Generates the new module's dagger-module.toml + SDK-emitted source scaffold at <path>. 3. Records [[modules.<sdk-module>.as-sdk.modules]] authoring entry for <path>. 4. When --path is omitted, also installs the new module as [modules.<name>] so it's callable here. 5. Runs the SDK's generators scoped to <path>, so the new module is loadable without a separate 'dagger generate'. Pass --no-generate to skip this. When --path is omitted, the module is created under .dagger/modules/<name> beside the dagger.toml being edited. Pass --path to choose a location: it is relative to the current directory, and a leading "/" means the workspace root. A custom path skips the [modules.<name>] install (the user is managing workspace layout explicitly). ``` dagger module init [flags] ``` ### Examples ``` dagger sdk install go && dagger module init go my-module ``` ### Options ``` --no-generate Skip running the SDK's generators for the new module --path string Module path, relative to the current directory ("/" = workspace root; default: .dagger/modules/ beside dagger.toml) ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger module](#dagger-module) - Author a module: edit dependencies, engine version, etc. ## dagger module sdk Run SDK-specific commands against this module's SDK ### Synopsis Run SDK-specific commands against the current module's SDK. Reads the SDK from the module's dagger-module.toml and dispatches through "dagger api call <sdk>". Available subcommands depend entirely on the SDK in use — the wrapper is a thin forwarder. Examples: dagger module sdk python-version 3.13 dagger module sdk go-mod-tidy dagger module sdk python-version --help # SDK function help (dispatched) dagger module sdk --help # this wrapper's help ``` dagger module sdk [args...] [flags] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger module](#dagger-module) - Author a module: edit dependencies, engine version, etc. ## dagger sdk Install and manage SDKs (the modules that author other modules) ### Synopsis Install and manage SDKs that can create Dagger modules or generated API clients. Use an installed SDK with `dagger module init` or `dagger api client init`. ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers * [dagger sdk install](#dagger-sdk-install) - Install an SDK and mark it * [dagger sdk installed](#dagger-sdk-installed) - List installed SDKs * [dagger sdk search](#dagger-sdk-search) - Discover SDKs in the SDK registry * [dagger sdk uninstall](#dagger-sdk-uninstall) - Remove an SDK install ## dagger sdk install Install an SDK and mark it ### Synopsis Install an SDK into the current workspace and mark it with the [modules.<name>.as-sdk] table. Registry names and aliases resolve to their canonical SDK refs. For registry SDKs, the workspace install name is the canonical ref basename prefixed with "dagger-", and the user-facing name is persisted in [modules.<name>.as-sdk] name. Direct refs are installed by basename. Generic `dagger install ` does NOT mark anything as an SDK. The marker is opt-in via this verb. ``` dagger sdk install [options] [flags] ``` ### Examples ``` dagger sdk install typescript && dagger module init typescript --help && dagger api client init typescript --help ``` ### Options ``` --here Write to the workspace config directory at the workspace cwd -n, --name string Override the workspace install name (defaults to the registry repo basename prefixed with "dagger-", or the basename of a direct ref) ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger sdk](#dagger-sdk) - Install and manage SDKs (the modules that author other modules) ## dagger sdk installed List installed SDKs ### Synopsis List installs in the current workspace that carry the [modules.<name>.as-sdk] marker. ``` dagger sdk installed [flags] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger sdk](#dagger-sdk) - Install and manage SDKs (the modules that author other modules) ## dagger sdk search Discover SDKs in the SDK registry ### Synopsis List entries in the embedded SDK registry (sdks.json). With no query, prints all known SDKs and their aliases. With a query, filters by case-insensitive substring on name, description, alias, or repo. ``` dagger sdk search [query] [flags] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger sdk](#dagger-sdk) - Install and manage SDKs (the modules that author other modules) ## dagger sdk uninstall Remove an SDK install ### Synopsis Remove an SDK install from the current workspace. Refuses if anything is authored under the SDK (entries in [[modules.<name>.as-sdk.modules]] or [[modules.<name>.as-sdk.clients]]). Pass --force to override and remove anyway; the authored module/client files are left on disk untouched, only the workspace entries go away. ``` dagger sdk uninstall [options] [flags] ``` ### Options ``` --force Remove even if modules or clients are authored under this SDK --here Write to the workspace config directory at the workspace cwd ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger sdk](#dagger-sdk) - Install and manage SDKs (the modules that author other modules) ## dagger search Search for modules you can install ### Synopsis Search the module registry by name or description. With no query, lists all known modules. ``` dagger search [query] ``` ### Examples ``` dagger search wolfi ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers ## dagger settings Get, set, or unset module settings (use --env for an env overlay) ``` dagger settings [module] [key] [value...] ``` ### Options ``` -g, --global Store the setting in user-level config instead of the repository, keyed by the workspace's git remote --here Write workspace config at the selected workspace cwd -u, --unset Remove the setting from workspace config ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers ## dagger setup Ensure Dagger is properly set up and operational in the workspace ### Synopsis Ensure Dagger is properly set up and operational in the workspace. Starts with a Cloud login prompt, then takes one of two paths: • Workspace migrate — if a legacy dagger.json project is detected, convert it to the current workspace format. • Recommended modules — otherwise, suggest modules to install based on files present in the workspace. Migration and recommendations never run together: after applying a migration, run setup again to see recommendations for the migrated workspace. Declining the migration falls through to recommendations. Run from a module subdirectory (a dagger.json below the repository root), the migrate step converts just that module to dagger-module.toml: no workspace is created and module recommendations are skipped. If that config lists toolchains, they are installed into a dagger.toml at the repository root — never a nested one. A subdirectory config with a blueprint is left as legacy with a warning. Toolchains of a module with an SDK are also added as dependencies in the migrated dagger-module.toml, since 0.21 exposed toolchains to module code the same way as dependencies. Remove any the module code does not use. Idempotent: safe to run anytime. No-ops what's already in good shape. Each step can be skipped at the prompt. With --auto-apply, workspace changes and module recommendations are applied without prompting. Cloud login is skipped in non-interactive mode; run dagger login separately. ``` dagger setup ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers ## dagger terminal Open a terminal for a container or directory in your project ### Synopsis Open a terminal for a container or directory in your project. Examples: dagger terminal -l # List all available terminal targets dagger terminal go:dev # Open the go:dev terminal target dagger tty go:dev # Use the short command alias ``` dagger terminal [options] [pattern] ``` ### Options ``` -l, --list List available terminal targets ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers ## dagger uninstall Uninstall a module from your workspace ### Synopsis Uninstall a module from the current workspace, removing it from dagger.toml. With --env only the env's overlay entry is removed, never the base module. ``` dagger uninstall [options] ``` ### Examples ``` dagger uninstall hello ``` ### Options ``` --here Write workspace config at the selected workspace cwd ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers ## dagger up Run your project's services for local development — databases, APIs, dev servers, etc. ### Synopsis Run your project's services for local development — databases, APIs, dev servers, etc. Examples: dagger up # Start all services dagger up -l # List all available services dagger up web # Start only the 'web' service ``` dagger up [options] [pattern...] ``` ### Options ``` -l, --list List available services ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers ## dagger update Refresh installed-module state ### Synopsis Refresh installed-module state. Refreshes entries already recorded in dagger.lock. ``` dagger update ``` ### Examples ``` "dagger update" ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers ## dagger version Print dagger version ``` dagger version ``` ### Options ``` --check Check for updates -q, --quiet Print only the canonical build identifier ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers ## dagger workspace Inspect or configure your workspace (cwd, remotes, config, etc.) ### Synopsis Inspect or configure your workspace. A workspace is a project configured to use Dagger — a directory holding a dagger.toml that records installed modules, environment overlays, and settings. Most commands (install, check, generate, up, settings, ...) operate on the workspace reachable from the current directory. The -W flag selects a different workspace (local path or git ref); --env applies a named overlay; dagger.toml is the source of truth. Run with no subcommand to print a digest of workspace state (cwd, root, current remote, installed modules summary). ``` dagger workspace ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger](#dagger) - A tool to run composable workflows in containers * [dagger workspace config](#dagger-workspace-config) - Get or set workspace configuration * [dagger workspace config-file](#dagger-workspace-config-file) - Print the selected workspace config file * [dagger workspace cwd](#dagger-workspace-cwd) - Print the workspace cwd * [dagger workspace remote](#dagger-workspace-remote) - Print the selectable remote address for the current workspace * [dagger workspace remotes](#dagger-workspace-remotes) - List selectable remote workspace addresses * [dagger workspace root](#dagger-workspace-root) - Print the workspace root ## dagger workspace config Get or set workspace configuration ### Synopsis Get or set workspace configuration values in dagger.toml. With no arguments, prints the full configuration. With one argument, prints the value at the given key. With two arguments, sets the value at the given key. With one argument and --unset, removes the value at the given key. With --env, reads show the effective env-applied view while writes target that environment's overlay. Explicit env.* keys always address raw overlay storage. Local module source values are stored relative to dagger.toml. ``` dagger workspace config [key] [value] [flags] ``` ### Options ``` -g, --global Write to user-level config instead of the repository, keyed by the workspace's git remote --here Write workspace config at the selected workspace cwd -u, --unset Remove the value at the given key ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger workspace](#dagger-workspace) - Inspect or configure your workspace (cwd, remotes, config, etc.) ## dagger workspace config-file Print the selected workspace config file ``` dagger workspace config-file [flags] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger workspace](#dagger-workspace) - Inspect or configure your workspace (cwd, remotes, config, etc.) ## dagger workspace cwd Print the workspace cwd ``` dagger workspace cwd [flags] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger workspace](#dagger-workspace) - Inspect or configure your workspace (cwd, remotes, config, etc.) ## dagger workspace remote Print the selectable remote address for the current workspace ``` dagger workspace remote [flags] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger workspace](#dagger-workspace) - Inspect or configure your workspace (cwd, remotes, config, etc.) ## dagger workspace remotes List selectable remote workspace addresses ``` dagger workspace remotes [flags] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger workspace](#dagger-workspace) - Inspect or configure your workspace (cwd, remotes, config, etc.) ## dagger workspace root Print the workspace root ``` dagger workspace root [flags] ``` ### Options inherited from parent commands ``` -y, --auto-apply Automatically apply changes when a changeset is returned -d, --debug Show debug logs and full verbosity --env string Apply a named env overlay; writes target it, creating it if missing -i, --interactive Spawn a terminal on container exec failure --interactive-command string Change the default command for interactive mode (default "/bin/sh") -E, --no-exit Leave the TUI running after completion --org string Dagger Cloud org name for Cloud-scoped commands --progress string Progress output format (auto, plain, tty, dots, logs, report) (default "auto") -q, --quiet count Reduce verbosity (show progress, but clean up at the end) -s, --silent Do not show progress at all -v, --verbose count Increase verbosity (use -vv or -vvv for more) -w, --web Open trace URL in a web browser -W, --workspace string Select the workspace location to load from (local path or git ref) --x-release string Run an experimental release from a Dagger git ref ``` ### SEE ALSO * [dagger workspace](#dagger-workspace) - Inspect or configure your workspace (cwd, remotes, config, etc.) --- # Client libraries URL: https://docs.dagger.io/reference/client-libraries/index # Client libraries Most of the time you call the Dagger API through the CLI or from inside a [module](../sdks/index.mdx). A client is for your own program, whether a script, a service, or a test harness, that needs to talk to the engine directly. There are two ways to get one. ## Generated clients A generated client is a typed binding to one module's API, including the core API and every module it depends on. It lives in your workspace, `dagger.toml` records it, and `dagger generate` regenerates it along with everything else. Install the SDK for the language you want the client in, then initialize a client at a path, bound to a module: ```shell dagger sdk install typescript dagger api client init typescript ./lib/client .dagger/modules/api ``` `` is where the client goes, relative to the current directory. A leading `/` means the workspace root. `` is a workspace-relative path or a module ref. The engine records the client under the SDK in `dagger.toml` and the SDK's generators write the bindings. Pass `--no-generate` to record the client without generating yet. SDKs can add flags of their own; `dagger api client init --help` lists them. ```shell dagger api client list # clients recorded in this workspace dagger generate # regenerate bindings after the bound module changes ``` Only SDKs that implement the client contract can generate clients. Today that is [Go](../sdks/go.mdx), [TypeScript](../sdks/typescript.mdx), and [PHP](../sdks/php.mdx). The bindings pin the engine version the bound module requires, so a client and the module it came from stay in step. ## Standalone client libraries Each SDK also publishes a plain client library for the core API to its language's package registry. Use it when you don't need module-specific bindings, or in a language that has no generated clients yet. | Language | Package | Source | |---|---|---| | Go | `dagger.io/dagger` | [`sdk/go`](https://github.com/dagger/dagger/tree/main/sdk/go) | | TypeScript | `@dagger.io/dagger` (npm) | [`sdk/typescript`](https://github.com/dagger/dagger/tree/main/sdk/typescript) | | Python | `dagger-io` (PyPI) | [`sdk/python`](https://github.com/dagger/dagger/tree/main/sdk/python) | | PHP | `dagger/dagger` (Packagist) | [`sdk/php`](https://github.com/dagger/dagger/tree/main/sdk/php) | | Java | `io.dagger:dagger-java-sdk` (Maven) | [`sdk/java`](https://github.com/dagger/dagger/tree/main/sdk/java) | | Elixir | `dagger` (Hex) | [`sdk/elixir`](https://github.com/dagger/dagger/tree/main/sdk/elixir) | | Rust | `dagger-sdk` (crates.io) | [`sdk/rust`](https://github.com/dagger/dagger/tree/main/sdk/rust) | | .NET | `Dagger.SDK` | [`sdk/dotnet`](https://github.com/dagger/dagger/tree/main/sdk/dotnet) | A client library needs a session with the engine. The simplest way to get one is to run your program under `dagger api with-session`. It starts a session and sets `DAGGER_SESSION_PORT` and `DAGGER_SESSION_TOKEN` in the program's environment: ```shell dagger api with-session go run main.go dagger api with-session node index.mjs dagger api with-session python main.py ``` Every library reads those two variables. Progress renders in the same TUI as any other Dagger command, and the run shows up in Dagger Cloud like a `dagger check` would. ## Raw GraphQL The API is GraphQL underneath, so any HTTP client works. With a session from `dagger api with-session`, post queries to `http://127.0.0.1:$DAGGER_SESSION_PORT/query` with the token as the basic-auth username: ```shell jq -n '{query:"{container{id}}"}' | \ dagger api with-session sh -c 'curl -s \ -u $DAGGER_SESSION_TOKEN: \ -H "content-type:application/json" \ -d @- \ http://127.0.0.1:$DAGGER_SESSION_PORT/query' ``` The [API reference](../api/index.mdx) documents the schema. --- # dagger.toml URL: https://docs.dagger.io/reference/config-files/dagger-toml # dagger.toml A workspace is configured by a `dagger.toml` file at its root. It records the modules installed in the workspace, their settings, and any per-environment overrides. `dagger install` creates it on first install. The machine-readable schema is published at [dagger-workspace.schema.json](/reference/dagger-workspace.schema.json). ## Top level | Key | Type | Description | | --- | --- | --- | | `modules` | table | Installed modules, keyed by install name. See [`[modules.]`](#modulesname). | | `env` | table | Named environment overlays. See [`[env.]`](#envname). | | `ports` | table | Host port mappings for services. See [`[ports.]`](#portsname). | | `ignore` | array | Path patterns excluded when loading the workspace. | | `defaults_from_dotenv` | bool | Read module constructor defaults from a `.env` file. | | `check-generated` | bool | Run generators as checks during `dagger check`, failing when generated files are stale. Defaults to `true`; CLI flags override it. | Resolved image and Git lookups are pinned in `dagger.lock` alongside the config, and refreshed with `dagger update`. ## `[modules.]` ```toml [modules.eslint] source = "github.com/dagger/eslint@v0.3.0" [modules.eslint.settings] packageManager = "yarn" ``` | Key | Type | Description | | --- | --- | --- | | `source` | string | Module address — a workspace-relative path, or a Git ref such as `github.com/org/mod@version`. | | `pin` | string | Resolved version for `source`. | | `settings` | table | Module settings. Keys are defined by the module; set them with `dagger settings`. | | `entrypoint` | bool | Marks this module as the workspace entrypoint. | | `legacy-default-path` | bool | Compatibility flag recorded by workspace migration. | | `check` | table | `skip = [...]` — check functions to exclude from `dagger check`. | | `generate` | table | `skip = [...]` — generators to exclude from `dagger generate`. | | `up` | table | `skip = [...]` — services to exclude from `dagger up`. | | `as-sdk` | table | SDK-role data, for module entries that act as an SDK in this workspace. See [`as-sdk`](#as-sdk). | Settings can point at another module's output instead of a literal value — see [Module wiring](../../config/module-wiring.mdx). ## `as-sdk` | Key | Type | Description | | --- | --- | --- | | `name` | string | SDK name used by `dagger module init ` and `dagger api client init `. Defaults to the module entry name. | | `modules` | array | Workspace-local modules this SDK authors, each with a `path`. | | `clients` | array | Generated bindings this SDK produces, each with `path`, `module`, `pin`, and `options`. | ## `[env.]` An environment overlay carries module settings, and may install modules scoped to itself. See [Environments](../../config/environments.mdx). ```toml [env.staging.modules.eslint.settings] baseImageAddress = "node:22-alpine" ``` | Key | Type | Description | | --- | --- | --- | | `modules..settings` | table | Settings applied on top of the base configuration when the environment is selected. | | `modules..source` | string | Installs a module scoped to this environment. Mirrors `[modules.].source`. | | `modules..pin` | string | Resolved version for the scoped `source`. | ## `[ports.]` | Key | Type | Description | | --- | --- | --- | | `backendService` | string | Service that backs this host port. | | `backendPort` | int | Port on the backing service. | ## User-level file The same module settings can be set per-user, outside the repository, in `~/.config/dagger/config.toml`. See [User configuration](../../config/user.mdx). --- # Configuration files URL: https://docs.dagger.io/reference/config-files/index # Configuration files Schemas for the files that configure Dagger. | File | Configures | | --- | --- | | [`dagger.toml`](./dagger-toml.mdx) | A workspace: its installed modules, their settings, and environment overlays. | --- # Biome URL: https://docs.dagger.io/reference/modules/biomejs # Biome The Biome module runs Biome linting over your JavaScript and TypeScript source and can return a fixed version when Biome can repair issues. Reach for it when a project uses Biome as its main code quality tool, so a single combined tool handles both lint and format rules instead of a separate ESLint and Prettier pair. Official module: [dagger/biomejs](https://github.com/dagger/biomejs) ## Add it to your workspace ```bash dagger install github.com/dagger/biomejs ``` ## Run the check ```bash dagger check # run every check in the workspace dagger check biomejs:lint # run Biome against the workspace source ``` `biomejs:lint` installs dependencies and runs `biome check` over the whole workspace using the project's own `biome.json`. Biome's `check` covers both linting and formatting, which is why this single check replaces a separate ESLint and Prettier pair. ## Fix issues Biome also exposes a `fix` function that runs `biome check --write` and returns the repaired source as a changeset (covering `.js`, `.ts`, `.jsx`, `.tsx`). It is a regular function rather than a check, so it does not run during `dagger check`; call it with `dagger api call` (run `dagger api functions` to see available functions). ## Configure it List the current settings and their values with `dagger settings biomejs`, then set one with `dagger settings biomejs `. Settings are stored in `dagger.toml` under `[modules.biomejs.settings]`: - `baseImageAddress` (default `node:25-alpine`) is the Node base image Biome runs in. Pin it to the project's Node version, for example `node:22-alpine`. Biome installs with npm, so unlike the ESLint and Prettier modules there is no package-manager setting. ```toml [modules.biomejs.settings] baseImageAddress = "node:22-alpine" ``` ## Working with other modules Use Biome for projects that already have Biome config. If your project uses ESLint and Prettier separately, use those modules instead. --- # Deno URL: https://docs.dagger.io/reference/modules/deno # Deno The Deno module gives a Deno workspace one shared way to test, lint, format, and type-check. It scans the workspace for `deno.json`/`deno.jsonc` files, treats each as a Deno project, reads the `workspace` array to fan out across members, and exposes workspace-level functions that run across all of them. That makes it a good fit for monorepos and repos where every project should share one Deno version and the same CI checks. Rather than wrapping the `deno` CLI, it models a Deno project as a typed object graph and maps Deno's toolchain onto Dagger's first-class verbs, so the same checks run locally, in CI, and in Dagger Cloud. Official module: [dagger/deno](https://github.com/dagger/deno) ## Add it to your workspace ```bash dagger install github.com/dagger/deno ``` ## Run the checks ```bash dagger check # run every check in the workspace dagger check deno:test-all # deno test across every project dagger check deno:lint-all # deno lint across every project dagger check deno:type-check-all # deno check across every project dagger check deno:format-check-all # deno fmt --check across every project ``` The `-all` checks discover every `deno.json`/`deno.jsonc` in the workspace, treat each as a Deno project, and run against all of them. Deno permissions come from each project's `deno.json` (under `test.permissions` or `permissions.default`), not from flags. To run a check against a single project, call it directly: ```bash dagger call deno project --path . test dagger call deno project --path apps/api type-check ``` ## Format the source `format-check` only reports whether files are formatted; `format` rewrites them. Because formatting mutates the workspace, `format` returns a changeset. Dagger prints the diff and asks before writing. Add `-y` to apply it without prompting: ```bash dagger call deno project --path . format # preview the diff dagger -y call deno project --path . format # apply it ``` ## Compile a binary `compile` builds a standalone executable from an entrypoint and returns it as a file to export: ```bash dagger call deno project --path . \ compile --entrypoint main.ts --target x86_64-unknown-linux-gnu \ export --path ./bin/app ``` ## Configure it List the current settings with `dagger settings deno`, then change one with `dagger settings deno `. They live in `dagger.toml` under `[modules.deno.settings]`: - `version` (default `2.9.3`) is the Deno version used to build the check containers. Pin this so every project is tested, linted, and formatted against the same Deno release. - `base` is the base container image Deno runs in (for example `docker.io/denoland/deno:debian`). Override it to control the OS or runtime the toolchain runs on. `base` and `version` are mutually exclusive. When `base` is set it already pins a Deno release, so `version` is ignored. ```bash # Pin the Deno version for the whole workspace dagger settings deno version 2.9.3 ``` ```toml [modules.deno.settings] version = "2.9.3" base = "docker.io/denoland/deno:debian" ``` ## Working with other modules Reach for this module whenever the repo contains one or more Deno projects, especially when they should share the same Deno version and CI checks. It composes with the rest of your workspace. The `base` and `install` functions expose a Deno-ready container you can hand to other modules, and `version` prints the configured toolchain version. --- # ESLint URL: https://docs.dagger.io/reference/modules/eslint # ESLint The ESLint module checks JavaScript and TypeScript source with ESLint, running the same lint check locally and in CI so issues get caught before a PR lands. Reach for it when the repo already has ESLint config and you want linting to run as a Dagger check, with a repair workflow available for fixable issues. Official module: [dagger/eslint](https://github.com/dagger/eslint) ## Add it to your workspace ```bash dagger install github.com/dagger/eslint ``` ## Run the check ```bash dagger check # run every check in the workspace dagger check eslint:lint # run ESLint against the workspace source ``` `eslint:lint` installs dependencies and runs `eslint .` over the whole workspace using the project's own ESLint configuration, so the result matches what developers see locally and fails on lint errors. ## Fix issues ESLint also exposes a `fix` function that runs `eslint . --fix` and returns the repaired source as a changeset (excluding `node_modules`). It is a regular function rather than a check, so it does not run during `dagger check`; call it with `dagger api call` (run `dagger api functions` to see available functions). ## Configure it List the current settings and their values with `dagger settings eslint`, then set one with `dagger settings eslint `. Settings are stored in `dagger.toml` under `[modules.eslint.settings]`. - `packageManager` (default `npm`) is the package manager used to install dependencies before linting. Set it to `yarn` or `pnpm` to match the project, so the same lockfile and dependency versions are used. - `baseImageAddress` (default `node:25-alpine`) is the Node base image ESLint runs in. Pin it to the project's Node version, for example `node:22-alpine`. ```toml [modules.eslint.settings] packageManager = "pnpm" baseImageAddress = "node:22-alpine" ``` ## Working with other modules Use ESLint with Prettier when the project separates lint rules from formatting. Use Biome when the project has moved linting and formatting into one tool. --- # Go URL: https://docs.dagger.io/reference/modules/go # Go The Go module gives a Go workspace one shared way to test, lint, and run `go generate`. It scans the workspace for `go.mod` files, treats each one as a Go module, and exposes workspace-level functions that run across all of them. That makes it a good fit for monorepos, service repos, and libraries with generated code, especially when several modules should share one Go version and the same CI checks. Official module: [dagger/go](https://github.com/dagger/go) ## Add it to your workspace ```bash dagger install github.com/dagger/go ``` ## Run the checks ```bash dagger check # run every check in the workspace dagger check go:test-all # run Go tests across every module dagger check go:lint-all # run golangci-lint across every module ``` `test-all` and `lint-all` discover every `go.mod` in the workspace, treat each as a Go module, and run against all of them. Tests run through an OpenTelemetry-aware runner, so individual Go tests appear as spans in the Dagger TUI and Dagger Cloud. Lint runs a pinned `golangci-lint` and picks up each module's `.golangci.*` config. ## Generate code Run the generator when generated Go files are part of normal development, such as mocks, embedded assets, protobuf output, or anything produced by `go generate`: ```bash dagger generate go:generate-all ``` `generate-all` runs only in modules that contain a `//go:generate` directive, and returns the result as a changeset to review before applying. ## Configure it List the current settings with `dagger settings go`, then change one with `dagger settings go `. They live in `dagger.toml` under `[modules.go.settings]`: - `version` (default `1.26`) is the Go toolchain version used to build the test and generate containers (`golang:-alpine`). Set this so every module is tested and generated against the same Go version. Lint uses a pinned `golangci-lint` image and is unaffected. - `includeExtraFiles` (default empty) are extra workspace-root path patterns mounted alongside each module's Go source. Go source, `go.mod`/`go.sum`/`go.work`, and `testdata/` directories are already included automatically; use this for inputs those patterns miss, such as embedded non-Go assets, generator inputs, or fixtures kept outside `testdata/`. - `lint`, `test`, and `generate` (each defaults to `["**"]`) are module-root selector arrays for `lint-all`, `test-all`, and `generate-all`. A bare pattern includes modules, a `!`-prefixed pattern excludes them, and exclusions always win. `"**"` and `"*"` match every module; `"path"` and `"path/**"` match the module at `path` and any modules below it. With no positive pattern, every module is included unless excluded, so `["!**"]` disables that workflow everywhere. ```bash # Pin the Go version for the whole workspace dagger settings go version 1.25 ``` List-valued settings are edited directly in `dagger.toml`: ```toml [modules.go.settings] version = "1.25" includeExtraFiles = ["Makefile", "tools/**"] lint = ["!**"] # Disable linting for all modules test = ["**", "!legacy-service"] # Test all modules except legacy-service and modules below it ``` ## Working with other modules Reach for this module whenever the repo contains one or more Go modules, especially when they should share the same Go version and CI checks. To exclude a single module from a workflow, add a `!`-prefixed module path to the corresponding selector array rather than splitting the repo into separate check systems. --- # Helm URL: https://docs.dagger.io/reference/modules/helm # Helm The Helm module validates Helm charts across your workspace. It discovers charts, lints them, and checks that values files render with `helm template --dry-run=client`. That catches structural and templating problems before a PR ever reaches a cluster. Reach for it in any repo that ships Kubernetes applications with Helm, where it makes a strong PR check by validating chart changes before deploy tooling sees them, and it shares one pinned Helm version across the whole workspace. Official module: [dagger/helm](https://github.com/dagger/helm) ## Add it to your workspace ```bash dagger install github.com/dagger/helm ``` ## Run the checks ```bash dagger check # run every check in the workspace dagger check helm:lint # lint every discovered chart dagger check helm:assert-template # render discovered values files and fail on errors ``` The module discovers charts by finding every `Chart.yaml` in the workspace and treats the containing directory as the chart root, so templates, subcharts, CRDs, and files referenced through `.Files` are all available to Helm. You can see which charts the module finds with `charts`. `lint` runs `helm lint` against each chart's default values, and once more for each discovered values file. `assert-template` renders each values file with `helm template --dry-run=client` and fails if templating breaks; it intentionally skips the bare chart, since some charts only render with one of their explicit values files. ## Configure it List the current settings and their values with `dagger settings helm`, then set one with `dagger settings helm `. Settings are stored in `dagger.toml` under `[modules.helm.settings]`: - `version` (default `3.18.4`) is the Helm version used for `lint` and `template`. Pin it so local runs and CI use the same Helm release. The module resolves it as the Wolfi `helm~` package, which now tracks the 4.x line, so 3.x versions no longer resolve. - `valuesGlob` (default `ci/*-values.yaml`) is a glob, relative to each chart root, that selects the values files to check. Every matching file becomes a separate scenario in both `lint` and `assert-template`. The default follows Helm chart-testing's CI convention, so files like `ci/prod-values.yaml` are picked up automatically. ```bash dagger settings helm version 4.0.1 dagger settings helm valuesGlob "ci/*-values.yaml" ``` To check a chart under several configurations, add more values files that match the glob. With the default glob, the chart below is rendered and linted once per file under `ci/`: ``` charts/api/ Chart.yaml values.yaml ci/ prod-values.yaml minimal-values.yaml ``` ## Working with other modules Use this module for repos that ship Kubernetes applications with Helm. It is a strong PR check because it validates chart changes before deploy tooling sees them. --- # Modules URL: https://docs.dagger.io/reference/modules/index # Modules These guides walk through setting up the official Dagger modules in your project. They are the standard library of tools that give a workspace useful work to do: test code, run a test runner, lint and format source, or validate Helm charts. Reach for a module when you want a real tool that runs the same way locally, in CI, and in Dagger Cloud. Most expose checks, generators, or repair workflows, so the work stays consistent everywhere it runs. Add any module to your project with `dagger install`: ```bash dagger install github.com/dagger/go ``` Each guide explains what the module is for, which checks or generators to reach for first, the settings that tune it, and how it fits into your project. | Guide | What it covers | | --- | --- | | [Go](./go.mdx) | Test, lint, and run generators across every Go module in a workspace. | | [Deno](./deno.mdx) | Test, lint, format, and type-check every Deno project in a workspace. | | [Pytest](./pytest.mdx) | Run Python tests with Pytest. | | [Jest](./jest.mdx) | Run Jest tests for JavaScript and TypeScript. | | [Vitest](./vitest.mdx) | Run Vitest tests for JavaScript and TypeScript. | | [Playwright](./playwright.mdx) | Run Playwright browser tests, wired to the service under test. | | [ESLint](./eslint.mdx) | Lint JavaScript and TypeScript source. | | [Prettier](./prettier.mdx) | Check and rewrite source formatting. | | [Biome](./biomejs.mdx) | Lint and format JavaScript and TypeScript with one tool. | | [ShellCheck](./shellcheck.mdx) | Check shell scripts. | | [PSScriptAnalyzer](./psscriptanalyzer.mdx) | Check PowerShell scripts. | | [Helm](./helm.mdx) | Lint Helm charts and check rendered templates. | --- # Jest URL: https://docs.dagger.io/reference/modules/jest # Jest The Jest module runs Jest tests for JavaScript and TypeScript projects. Reach for it when Jest is already the test runner for the repo and you want those tests to become a Dagger check that runs in CI and Dagger Cloud, whether you're testing one app or package in a larger workspace or debugging which tests get discovered. Official module: [dagger/jest](https://github.com/dagger/jest) ## Add it to your workspace ```bash dagger install github.com/dagger/jest ``` ## Run the tests ```bash dagger check # run every check in the workspace dagger check jest:test # run the Jest suite ``` `jest:test` installs dependencies and runs the Jest suite over the workspace (excluding `node_modules`, `dist`, and `build`). It automatically registers an OpenTelemetry hook, so individual tests appear as spans in the Dagger TUI and Dagger Cloud without changing the project's Jest config. ## Test options The `jest:test` check runs with default options. Call the `test` function directly with `dagger api call` to override them: - `files` limits the run to specific test files. - `build` runs the project's build script before testing. - `useEnv` uses the project's own Jest environment instead of the module's automatic OpenTelemetry environment. - `flags` are extra flags passed through to `jest`. Use `list` to print the tests Jest discovers when test selection is unclear. ## Configure it List the current settings and their values with `dagger settings jest`, then set one with `dagger settings jest `. Settings are stored in `dagger.toml` under `[modules.jest.settings]`: - `packageManager` (default `npm`) is the package manager used to install dependencies before testing. Set it to `yarn` or `pnpm` to match the project. - `baseImageAddress` (default `node:25-alpine`) is the Node base image tests run in. Pin it to the project's Node version, for example `node:22-alpine`. ```toml [modules.jest.settings] packageManager = "pnpm" baseImageAddress = "node:22-alpine" ``` ## Working with other modules Use this module when Jest is the test runner. Use Vitest instead for projects built around Vitest or Vite-first test workflows. --- # Playwright URL: https://docs.dagger.io/reference/modules/playwright # Playwright The Playwright module runs your [Playwright](https://playwright.dev) browser tests in a container whose browsers always match your Playwright version, the same way locally, in CI, and in Dagger Cloud. Its distinctive feature is first-class [module wiring](../../config/module-wiring.mdx). If another module in your workspace serves your app, one line of configuration points the tests at it. No glue module, no port juggling. Official module: [dagger/playwright](https://github.com/dagger/playwright) ## Add it to your workspace ```bash dagger install github.com/dagger/playwright ``` Pin your project's `@playwright/test` version exactly (or commit a lockfile). The module runs your tests in the `mcr.microsoft.com/playwright` image matching the version installed per `package-lock.json`. Without a lockfile it uses the version declared in `package.json`, where a floating range like `^1.58.2` can install a newer Playwright than the image's browsers. ## Run the check ```bash dagger check # run every check in the workspace dagger check playwright:test # just the Playwright suite ``` `playwright:test` finds the directory containing `playwright.config.*`, installs your project's dependencies, and runs `npx playwright test`. If your config declares a [`webServer`](https://playwright.dev/docs/test-webserver), Playwright starts your app inside the container exactly as it does on your machine, with no further setup needed. ## Wire in the service under test If another module already serves your app, wire it into the tests instead of duplicating that knowledge in `webServer`. Two steps: **1. Set the `service` setting to a module reference.** That is the install name of another module in your `dagger.toml`, and a function on it that returns a `Service`. Run `dagger up -l` to list the candidates in copyable form: ```toml [modules.playwright.settings] service = "myapp:serve" ``` **2. Add `PLAYWRIGHT_BASE_URL` to your `playwright.config`.** The module binds the service into the test container and communicates its address through this environment variable. If your config doesn't read it, your tests will ignore the wired service and keep targeting whatever `baseURL` hardcodes: ```js use: { baseURL: process.env.PLAYWRIGHT_BASE_URL || 'http://localhost:3000', }, ``` Keep your local URL as the fallback so the same config works on your machine. By default the service is bound as `frontend`; set `serviceHostname` if your tests need a different hostname. ### Secure contexts (service workers, WebCrypto, PWA testing) Browser APIs that require a secure context don't work against `http://frontend:`, since only `localhost` or HTTPS origins qualify. If any of your tests exercise service workers, WebCrypto, or other secure-context APIs, enable the localhost proxy: ```toml [modules.playwright.settings] service = "myapp:serve" localhostProxy = true ``` Then point those tests at `PLAYWRIGHT_LOCALHOST_BASE_URL`, which the proxy sets, for example as the `baseURL` of a dedicated project in your config: ```js { name: 'chromium-pwa', use: { ...devices['Desktop Chrome'], baseURL: process.env.PLAYWRIGHT_LOCALHOST_BASE_URL || 'http://localhost:3000', }, }, ``` ## Prepare your config for the container The module sets `CI=true`, so review what your `playwright.config` keys off `process.env.CI`, such as `retries`, `forbidOnly`, and especially `workers`: - **Replace a `workers: process.env.CI ? 1 : undefined` clamp with a bounded value like `4`.** The container is isolated, so the usual shared-CI reason to serialize doesn't apply, and a `1` clamp can make the suite many times slower. Don't go unbounded either, since too many workers starve the browsers and blow test timeouts. - **Remove branded-browser projects or exclude them with the `args` setting.** Those browsers (`channel: 'msedge'`, `channel: 'chrome'`) are not present in the Playwright images; the bundled `chromium` covers the same engine. ## Configure it List the current settings with `dagger settings playwright`, then change one with `dagger settings playwright `. They live in `dagger.toml` under `[modules.playwright.settings]`: - `sourcePath` (default: discover) is the workspace path of the Playwright project. Set it when the workspace holds more than one `playwright.config.*`. - `service` is the module reference (`"module:function"`) of the service under test. - `serviceHostname` (default `frontend`) is the hostname the service is bound as inside the test container. - `baseImageAddress` (default: derive) overrides the derived `mcr.microsoft.com/playwright:v-noble` image. - `baseCtr` is a full `Container` override. It is also wireable, e.g. `baseCtr = "base-images:chromium"`. - `packageManager` (default `npm`) is the package manager used to install dependencies. Set it to `yarn`, `pnpm`, or `bun` to match your project. - `localhostProxy` (default `false`) enables the localhost proxy described under secure contexts above. - `args` (default `[]`) are extra `playwright test` arguments, e.g. `["--project", "chromium"]`. - `shards` (default `1`) splits the check across that many parallel containers. Shards run concurrently against the same wired service and fail fast on the first failure. ```toml [modules.playwright.settings] service = "myapp:serve" shards = 4 ``` ## Get the HTML report To inspect a failing run, call `report`. It runs the suite tolerating failures and returns the HTML report directory. Include the `html` reporter in your config, then export the report to your machine: ```bash dagger api call playwright report -o ./playwright-report ``` ## Working with other modules Playwright covers browser-level end-to-end testing; pair it with [Jest](./jest.mdx) or [Vitest](./vitest.mdx) for unit tests. Any module whose function returns a `Service` can be the app under test. That's the [wiring contract](../../config/module-wiring.mdx), not a special integration. --- # Prettier URL: https://docs.dagger.io/reference/modules/prettier # Prettier The Prettier module keeps formatting boring, consistent, and enforced before code review. It checks formatting locally, in CI, and in Dagger Cloud, and can rewrite source to match, always using your project's own Prettier config. Keep it alongside a linter so formatting policy stays separate from lint rules. Official module: [dagger/prettier](https://github.com/dagger/prettier) ## Add it to your workspace ```bash dagger install github.com/dagger/prettier ``` ## Run the check ```bash dagger check # run every check in the workspace dagger check prettier:check # just check formatting ``` `prettier:check` installs dependencies and runs `prettier --check .` across the workspace, failing if any file isn't formatted. ## Fix formatting Prettier also exposes a `write` function that runs `prettier --write .` across the workspace and returns the reformatted source as a changeset (everything except `node_modules`). Which files it touches is governed by your project's own Prettier configuration and ignore files. It's a regular function, not a check, so it doesn't run during `dagger check`. Call it directly: ```bash dagger api call prettier write ``` ## Configure it List the current settings with `dagger settings prettier`, then change one with `dagger settings prettier `. They live in `dagger.toml` under `[modules.prettier.settings]`: - `packageManager` (default `npm`) is the package manager used to install dependencies before checking. Set it to `yarn` or `pnpm` to match the project. - `baseImageAddress` (default `node:25-alpine`) is the Node base image Prettier runs in. Pin it to your project's Node version, e.g. `node:22-alpine`. ```toml [modules.prettier.settings] packageManager = "pnpm" baseImageAddress = "node:22-alpine" ``` ## Working with other modules Prettier pairs well with ESLint. ESLint checks code quality, Prettier owns formatting. If your project uses Biome for both, use the [Biome](./biomejs.mdx) module instead. --- # PSScriptAnalyzer URL: https://docs.dagger.io/reference/modules/psscriptanalyzer # PSScriptAnalyzer The PSScriptAnalyzer module checks PowerShell scripts with PSScriptAnalyzer, applying the same review bar to your `.ps1`, `.psm1`, and `.psd1` files as you would to application code. Reach for it whenever PowerShell is part of the project and you want to enforce style, safety, and ruleset expectations in CI and Dagger Cloud. Its workspace alias is `ps-analyzer`, so its check and settings use that name. Official module: [dagger/PsScriptAnalyzer](https://github.com/dagger/PsScriptAnalyzer) ## Add it to your workspace ```bash dagger install github.com/dagger/PsScriptAnalyzer ``` ## Run the check ```bash dagger check # run every check in the workspace dagger check ps-analyzer:check # run PSScriptAnalyzer on discovered PowerShell scripts ``` `ps-analyzer:check` finds every `.ps1`, `.psm1`, and `.psd1` file in the workspace and runs `Invoke-ScriptAnalyzer` recursively, failing on any diagnostic it reports. ## Configure it List the current settings and their values with `dagger settings ps-analyzer`, then set one with `dagger settings ps-analyzer `. They live in `dagger.toml` under `[modules.ps-analyzer.settings]`: - `version` (default `1.22.0`) is the PSScriptAnalyzer release to install. Pin it so the same ruleset and analyzer behavior run locally and in CI. - `exclude` (default: none) is a list of script paths to skip. - `includeExtraFiles` (default empty) are extra non-PowerShell paths to mount, for scripts that read data files or other project context during analysis. ```bash dagger settings ps-analyzer version 1.22.0 ``` The list-valued settings are edited directly in `dagger.toml`: ```toml [modules.ps-analyzer.settings] version = "1.22.0" exclude = ["tests/"] includeExtraFiles = ["data/"] ``` ## Working with other modules Use this module for repos with PowerShell automation, Windows support scripts, or PowerShell modules. It complements ShellCheck in mixed shell workspaces. --- # Pytest URL: https://docs.dagger.io/reference/modules/pytest # Pytest The Pytest module runs your Python tests with Pytest, the same way locally, in CI, and in Dagger Cloud. Reach for it when your workspace already has Python tests and you want a single test check that runs from a standard source directory, or from a custom Python container when the default environment is not enough. Official module: [dagger/pytest](https://github.com/dagger/pytest) ## Add it to your workspace ```bash dagger install github.com/dagger/pytest ``` ## Run the tests ```bash dagger check # run every check in the workspace dagger check pytest:test # run Pytest against the project source ``` `pytest:test` injects `pytest_otel` automatically, so individual Python tests appear as spans in the Dagger TUI and Dagger Cloud with no project changes. The module installs dependencies from the project itself: `uv run` for `pyproject.toml` projects, or `pip install -r requirements.txt` for requirements-based projects. ## Test options The `pytest:test` check runs with default options. Call the `test` function directly with `dagger api call` to override them: - `version` (default `3.14`) is the Python version the default container provisions, such as `3.13` or `3.12`. Ignored when a custom `container` is set, since that container's Python is used as-is. - `args` (default `["-v"]`) are arguments passed straight to `pytest`, such as `["-x", "--tb=short"]`. Keep this module focused on tests; use separate modules for formatting, linting, shell scripts, or generated files. ## Configure it List the current settings and their values with `dagger settings pytest`, then set one with `dagger settings pytest `. Settings are stored in `dagger.toml` under `[modules.pytest.settings]`: - `source` (default: workspace root) is the directory containing the Python project to test. Point it at a subdirectory when the project is not at the workspace root. - `container` (default: none) is a custom container that already has Python and `uv` installed. By default the module uses an Alpine base and provisions Python with `uv`; set a container when tests need system packages, a private index, or other setup the default image lacks. ```toml [modules.pytest.settings] source = "./service" ``` ## Working with other modules This module is a good first check for Python repos. Once it passes locally, it is a natural candidate for autocheck and PR validation. --- # ShellCheck URL: https://docs.dagger.io/reference/modules/shellcheck # ShellCheck The ShellCheck module finds shell scripts in your workspace and checks them with ShellCheck, catching quoting, portability, and safety issues in CI and Dagger Cloud. Reach for it when scripts are part of the project and should be treated like code, not as untested glue. Deployment scripts, local dev scripts, and CI helpers all benefit. Official module: [dagger/shellcheck](https://github.com/dagger/shellcheck) ## Add it to your workspace ```bash dagger install github.com/dagger/shellcheck ``` ## Run the check ```bash dagger check # run every check in the workspace dagger check shellcheck:check # run ShellCheck on discovered shell scripts ``` `check` finds every `.sh` file in the workspace and runs ShellCheck on each one, so a script must use the `.sh` extension to be discovered. Use `scripts` to see exactly which files the module found. ## Configure it List the current settings and their values with `dagger settings shellcheck`. The `exclude` setting is list-valued, so set it in `dagger.toml` under `[modules.shellcheck.settings]`: - `exclude` (default: none) is a list of script paths to skip. Use it for vendored or generated scripts the repo does not own. ```toml [modules.shellcheck.settings] exclude = ["vendor/", "third_party/"] ``` Keep the exclude list narrow so new scripts are checked automatically. ## Working with other modules This module is small and high value. It is a good default check for repos that contain deployment scripts, local dev scripts, or CI helper scripts. --- # Vitest URL: https://docs.dagger.io/reference/modules/vitest # Vitest The Vitest module runs Vitest tests for JavaScript and TypeScript projects. Reach for it when the project uses Vitest, especially Vite apps and modern frontend packages, whether you want to run the suite as a workspace check, validate frontend packages and libraries, or list discovered tests when test selection is unclear. Official module: [dagger/vitest](https://github.com/dagger/vitest) ## Add it to your workspace ```bash dagger install github.com/dagger/vitest ``` ## Run the tests ```bash dagger check # run every check in the workspace dagger check vitest:test # run the Vitest suite ``` `vitest:test` installs dependencies and runs the Vitest suite over the workspace (excluding `node_modules`, `dist`, and `build`). It automatically registers an OpenTelemetry hook, so individual tests appear as spans in the Dagger TUI and Dagger Cloud without changing the project's Vitest config. ## Test options The `vitest:test` check runs with default options. Call the `test` function directly with `dagger api call` to override them: - `files` limits the run to specific test files. - `build` runs the project's build script before testing. - `flags` are extra flags passed through to `vitest`. Use `list` to print the tests Vitest discovers when test selection is unclear. ## Configure it List the current settings and their values with `dagger settings vitest`, then set one with `dagger settings vitest `. They live in `dagger.toml` under `[modules.vitest.settings]`: - `packageManager` (default `npm`) is the package manager used to install dependencies before testing. Set it to `yarn` or `pnpm` to match the project; with `pnpm`, the module enables Corepack automatically. - `baseImageAddress` (default `node:25-alpine`) is the Node base image tests run in. Pin it to the project's Node version, for example `node:22-alpine`. ```toml [modules.vitest.settings] packageManager = "pnpm" baseImageAddress = "node:22-alpine" ``` ## Working with other modules Use this module when Vitest is the test runner. Use Jest instead for projects that already depend on Jest conventions and config. --- # Dang SDK URL: https://docs.dagger.io/reference/sdks/dang import { daggerVersion } from '../../partials/version.js'; # Dang SDK Dang is Dagger's native DSL. It maps directly to the Dagger API, so what you write is what runs. There is no codegen, no generated client files to commit, no build step, and no language runtime to carry around. In the common case a Dang module is one `main.dang` file plus a `dagger-module.toml`. Use Dang when your module mostly orchestrates the Dagger API: containers, files, directories, services, secrets, and other modules. If you need external libraries (a Go parser, a Python ML library, a Node.js bundler API), use the [Go](./go.mdx), [Python](./python.mdx), or [TypeScript](./typescript.mdx) SDK instead. Those give you a full host language alongside the Dagger client. Every SDK shares a few platform concepts. Read these first if they are new to you: - [SDKs overview](./index.mdx) explains what a module is and how it fits into a workspace. - [Types](../api/index.mdx) covers the types your functions accept and return. - [Generating code](../../using/generating.mdx) shows how Dagger represents file diffs. `init` and generators both use them. ## A note on tooling: Dang is delivered as a Dagger module The tooling for developing Dang modules lives in a Dagger module of its own, `github.com/dagger/dang-sdk`, not in the `dagger` CLI. Install it into your workspace once. From then on you scaffold and maintain Dang modules by calling functions on that module by name: ```shell # Install the Dang SDK into your workspace (once) dagger install github.com/dagger/dang-sdk # Then call its functions dagger api call dang-sdk [args] ``` The functions you will use most often: | Function | Purpose | |---|---| | `init` | Create a new Dang SDK module. Returns a [changeset](../../using/generating.mdx) of files to write. | | `mod` | Resolve the Dang module at or above a workspace path; entry point for `deps`, `generate`, `engine`, `path`. | | `mod deps` | Add, remove, list, and update module dependencies. | | `mod generate` | Regenerate module metadata. For Dang this is close to a no-op, since there are no client bindings to regenerate. | | `mod engine` | Read or set the required Dagger engine version. | | `generate-all` | Generate every discovered Dang SDK module in the workspace. | | `modules` | List every Dagger module in the workspace whose `runtime.source` is `"dang"`. | | `templates` | List the init templates this version of `dang-sdk` ships. | ## Create a module :::note Run these commands from inside a Git repository. That is where Dagger creates the new module. ::: Install the Dang SDK into your workspace, then create a new module with its `init` function. By default `init` creates the module under the nearest `.dagger` directory visible from your current workspace path: ``` /modules/ ``` ```shell dagger install github.com/dagger/dang-sdk dagger api call dang-sdk init --name my-ci ``` `init` returns a [changeset](../../using/generating.mdx). Dagger shows it to you for review before writing any files into your workspace. `init` takes these arguments: - `--name` is required. It sets the module name. - `--path` puts the module somewhere else. The target path must not already contain a Dagger module. - `--template` writes files from `templates/