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 five example manifests for Guarded Entrypoint, and the deployment settings that go with the truststore examples. Each manifest is complete 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.

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: Each Guardener capability has its own release stage, listed in Optional Features. The GitHub capabilities are 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 or Docker, 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:

Chainguard Checks examples

Thu, 12 Nov 2026 14:46:46 +0000

This page gives complete Chainguard Checks configurations for common kinds of projects. Copy the one closest to your project, then change its packages, commands, and network access to match. Each example passes chainctl checks validate. For what each key does, refer to the Chainguard Checks configuration reference, and for services and caches, refer to Variations, inputs, services, and caches.

Keep the following in mind when you adapt an example:

A check reaches only the hosts in its network.egress list. If your build downloads from somewhere else, such as a private package registry, add that host. Refer to Find the hosts a check needs.
A cache does nothing until your default branch’s .chainguard/ci/identities.yaml file defines cache pools, as described in Set up cache pools. The examples that use caches also run after merging, with trigger: [presubmit, postsubmit], so that runs on your default branch fill the cache that pull requests start from.
Chainguard Workspaces sessions can use these files for their packages, but they don’t start services or mount caches other than gobuild. Refer to Configure a Chainguard Workspaces session’s environment.

Java with Maven

This file installs a JDK and Maven, and runs the build’s tests with mvn verify:

Workload identities and trust in Chainguard Checks

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

A check that must authenticate to Google Cloud, AWS, Azure, or 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.

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, how to read them with the GitHub API, and how to use them to protect your branches. To watch a pull request’s checks pass, fail, and pass again after a fix, follow the tutorial Fix a failing check with Claude Code.

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’s package repositories: your organization’s Private APK Repository and the public Wolfi and Extra Packages repositories. 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. When you return to a session that you opened from a local directory, chainctl reminds you of the change. 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

Chainguard Checks examples

Java with Maven

Workload identities and trust in Chainguard Checks

Use Chainguard Checks on GitHub

Configure a Chainguard Workspaces session's environment

Manage Chainguard Workspaces session credentials

The `.chainguard/` directory