Helm values

Values for the oci://ghcr.io/loopholelabs/architect-chart chart. The console install flow sets the required ones for you. Run helm show values oci://ghcr.io/loopholelabs/architect-chart to print the live defaults.

Required

Authentication

Provide the token inline with machineToken, or reference a Secret that holds it with secretRef. Prefer secretRef for any non-interactive or GitOps install: --set machineToken writes the token into your shell history and into the stored Helm release values (helm get values), whereas a referenced Secret keeps it out of both (and works with External Secrets, Sealed Secrets, and similar).

Cluster

Persistent checkpoint storage (S3)

Optional. Enables the daemon to store checkpoints for the start-from-persistent-checkpoint annotation in an S3-compatible bucket. Set s3Bucket and s3Region to turn it on; everything else depends on where the bucket lives and how you authenticate. When secretRef is unset, these values are written into the chart-created Secret.

Credentials

The daemon picks its credential source from what you set:

• Static keys — set s3AccessKeyID and s3SecretAccessKey. Required for S3-compatible stores (MinIO, Garage) and works against AWS S3.
• Workload identity — leave both keys empty and the daemon resolves credentials via the AWS SDK default chain (IRSA, EKS Pod Identity, instance profile, environment). Use this on EKS when a policy forbids long-lived keys. The daemon logs the resolved credential mode at startup.

Because leaving the keys empty now means "use ambient credentials" rather than "S3 off", a bucket set with keys half-configured is treated as enabled and would fail at the first upload rather than at startup. Set both keys or neither.

For IRSA, attach the role ARN to the daemon ServiceAccount via architectdServiceAccountAnnotations:

architectdServiceAccountAnnotations:
  eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/architect-s3

For EKS Pod Identity, no chart change is needed: create the Pod Identity association on the AWS side against the architectd-installer-daemon ServiceAccount in the release namespace.

The IAM role (IRSA or Pod Identity) needs these actions on the bucket and its objects, since the transfer manager does concurrent multipart transfers:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:PutObject",
    "s3:DeleteObject",
    "s3:AbortMultipartUpload",
    "s3:ListMultipartUploadParts",
    "s3:ListBucketMultipartUploads"
  ],
  "Resource": [
    "arn:aws:s3:::my-bucket",
    "arn:aws:s3:::my-bucket/*"
  ]
}

Service account

Placement and sizing

Each component (architectd, architectAdmissionController, architectControlPlane) takes a node selector, tolerations, and resource requests/limits.

Images

Each component image can be overridden; leave blank to use the pinned default.

Self-test

The self-test component deploys short-lived workloads into a dedicated testing namespace and runs core-functionality checks on demand from the Console. It is enabled by default; set architectSelfTestEnabled: false to opt out. See Testing your application for how to use it.

Experimental