Skip to main content

FAQ

Do I have to use Homebrew to install Zarf?

No, the Zarf binary and init package can be downloaded from the Releases Page. Zarf does not need to be installed or available to all users on the system, but it does need to be executable for the current user (i.e. chmod +x zarf for Linux/Mac).

What dependencies does Zarf have?

Zarf is statically compiled and written in Go and Rust, so it has no external dependencies. For Linux, Zarf can bring a Kubernetes cluster using K3s. For Mac and Windows, Zarf can leverage any available local or remote cluster the user has access to. Currently, the K3s installation Zarf performs does require a Systemd based system and root access.

What license is Zarf under?

Zarf is under the Apache License 2.0. This is one of the most commonly used licenses for open source software.

What is the Zarf Agent?

The Zarf Agent is a Kubernetes Mutating Webhook that is installed into the cluster during the zarf init operation. The Agent is responsible for modifying Kubernetes PodSpec objects Image fields to point to the Zarf Registry. This allows the cluster to pull images from the Zarf Registry instead of the internet without having to modify the original image references. The Agent also modifies Flux GitRepository objects to point to the local Git Server.

Why doesn't the Zarf Agent create secrets it needs in the cluster?

During early discussions and subsequent decision to use a Mutating Webhook, we decided to not have the Agent create any secrets in the cluster. This is to avoid the Agent having to have more privileges than it needs as well as avoid collisions with Helm. The Agent today simply responds to requests to patch PodSpec and GitRepository objects.

The Agent does not need to create any secrets in the cluster. Instead, during zarf init and zarf package deploy, secrets are automatically created as Helm Postrender Hook for any namespaces Zarf sees. If you have resources managed by Flux that are not in a namespace managed by Zarf, you can either create the secrets manually or include a manifest to create the namespace in your package and let Zarf create the secrets for you.

How can a Kubernetes resource be excluded from the Zarf Agent?

Resources can be excluded at the namespace or resources level by adding the zarf.dev/agent: ignore label.

What happens to resources that exist in the cluster before zarf init?

During the zarf init operation, the Zarf Agent will patch any existing namespaces with the zarf.dev/agent: ignore label to prevent the Agent from modifying any resources in that namespace. This is done because there is no way to guarantee the images used by pods in existing namespaces are available in the Zarf Registry.

What is YOLO Mode and why would I use it?

YOLO Mode is a special package metadata designation that be added to a package prior to zarf package create to allow the package to be installed without the need for a zarf init operation. In most cases this will not be used, but it can be useful for testing or for environments that manage their own registries and Git servers completely outside of Zarf. This can also be used as a way to transition slowly to using Zarf without having to do a full migration.

note

Typically you should not deploy a Zarf package in YOLO mode if the cluster has already been initialized with Zarf. This could lead to an ImagePullBackOff if the resources in the package do not include the zarf.dev/agent: ignore label and are not already available in the Zarf Registry.