Configuration on

Guarded Entrypoint for Custom Assembly

Tue, 06 Oct 2026 17:41:00 +0000

Note: Guarded Entrypoint is in beta. To use it, contact Chainguard customer support to enable it for your organization.

Guarded Entrypoint lets a Custom Assembly image run startup logic without a derived image build. You declare the logic as part of your Custom Assembly configuration. Chainguard builds it into the image and signs the result.

This page explains what Guarded Entrypoint is and how to turn it on. The other pages in this section cover the details:

Guarded Entrypoint examples

Tue, 06 Oct 2026 17:41:00 +0000

Note: Guarded Entrypoint is in beta. To use it, contact Chainguard customer support to enable it for your organization.

This page has four example manifests for Guarded Entrypoint. Each one is a complete manifest for chainctl images repos build edit or chainctl images repos build apply. None of them contains a literal secret. Each secret is a reference that the wrapper resolves when the container starts.

Applying a manifest replaces the repo’s stored configuration. If your repo already has other customizations, such as packages, add the Guarded Entrypoint keys to your existing manifest instead of replacing it.

Managing Chainguard App connections

Mon, 03 Aug 2026 00:00:00 +0000

Guardener acts on your GitHub repositories on behalf of your Chainguard organization. The bridge between the two is a connection: a Chainguard App installation on a GitHub organization, linked to a Chainguard organization. This page explains how connections work and how to set up, inspect, change, and remove them.

For a first-time walkthrough, refer to Getting started. This page is the fuller reference for managing connections over time.

Note: Guardener is in beta. Available to organizations that have installed and linked the Chainguard App.

Chainguard Checks configuration reference

Thu, 08 Oct 2026 00:00:00 +0000

You define your checks in YAML configuration files in your repository’s .chainguard/ directory. This page describes the file format: where the files go, the packages and commands each check gets, and the options that control when and how checks run. For variations, inputs and outputs, services, and caches, refer to Variations, inputs, services, and caches.

The same files also set up Chainguard Workspaces sessions, and run-ci in a session runs the checks they define.

Configuring Guardener

Wed, 08 Jul 2026 00:00:00 +0000

Guardener is configured entirely through files committed to a .chainguard/ directory — either in each repository, or once at the organization level in your .github repository. This page explains the configuration model that all Guardener features share. For the specific options of each feature, refer to its dedicated page.

The `.chainguard/` directory

Guardener reads its configuration from the .chainguard/ directory at the root of each repository. Every feature has its own file:

Variations, inputs, services, and caches in Chainguard Checks

Mon, 12 Oct 2026 00:00:00 +0000

Most checks need only the keys that the Chainguard Checks configuration reference describes. This page describes the keys for checks that need more: running a check once for each of several variations, passing files between checks, starting services such as a database, running as an unprivileged account, and reusing build output from earlier runs.

Run a check once per variation

The foreach key runs a check once for each entry in a list, each in its own VM. All of a check’s variations report as one GitHub check. For example, this check runs three variations, two at a time:

Workload identities and trust in Chainguard Checks

Mon, 12 Oct 2026 00:00:00 +0000

A check that must authenticate to Google Cloud or to Chainguard, such as to read a Cloud Storage bucket or to pull private images from cgr.dev, can use a workload identity: short-lived credentials that Chainguard Checks gives the check while it runs. This page explains how workload identities work, how to declare and set one up, how to limit which pull requests get one, and how to revoke access.

How workload identities work

A check’s VM holds no long-lived credentials. When a check uses a workload identity, Chainguard Checks issues the check an OpenID Connect (OIDC) token that lasts five minutes, renews the token while the check runs, and keeps the real credentials outside the VM:

Use Chainguard Checks on GitHub

Thu, 08 Oct 2026 00:00:00 +0000

Chainguard Checks runs on your GitHub repositories through the Chainguard App and reports its results as GitHub checks. This page explains when Chainguard Checks runs, how its results appear on GitHub, and how to use them to protect your branches.

When Checks runs

Chainguard Checks runs on a repository when the Chainguard App is installed on the repository, its GitHub account is linked to a Chainguard organization with access to Chainguard Checks, and the repository has a .chainguard/ci.yaml file or a .chainguard/ci/ directory. For a pull request, Chainguard Checks looks for the configuration on the pull request’s branch and on its base branch.

Configure a Chainguard Workspaces session's environment

Thu, 08 Oct 2026 00:00:00 +0000

A Chainguard Workspaces session’s environment is the set of packages installed in its VM and the network access it has. Packages come from Chainguard OS, the same packages behind Chainguard Containers. This page explains where a session’s environment comes from and how to change it.

A session’s environment is fixed when the session is created. If your repository’s .chainguard/develop.yaml or .chainguard/ci.yaml file changes afterward, existing sessions keep the environment they started with, and chainctl reminds you when you return to them. To use the new environment, open a new session with chainctl develop --new.

Manage Chainguard Workspaces session credentials

Thu, 08 Oct 2026 00:00:00 +0000

A Chainguard Workspaces session holds no long-lived credentials: its VM stores no API keys, tokens, or registry logins. Instead, the session reaches each service through a local hostname, and the credential is added to the request outside the VM. This page explains what a session can reach by default, how to change it, and which credentials a session can’t supply.

A check in Chainguard Checks can get short-lived credentials through a workload identity, which a session can’t use. Refer to Workload identities and trust.

Configuration on

Guarded Entrypoint for Custom Assembly

Guarded Entrypoint examples

Managing Chainguard App connections

Chainguard Checks configuration reference

Configuring Guardener

The .chainguard/ directory

Variations, inputs, services, and caches in Chainguard Checks

Run a check once per variation

Workload identities and trust in Chainguard Checks

How workload identities work

Use Chainguard Checks on GitHub

When Checks runs

Configure a Chainguard Workspaces session's environment

Manage Chainguard Workspaces session credentials

The `.chainguard/` directory