### Importing MarkdownGuideNav Component (JavaScript)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/stable-25-04/guides/getting-started/overview/index.mdx

This line imports the MarkdownGuideNav component from a local path within the project. This component is likely used for navigation within markdown-based guides or documentation pages.

```JavaScript
import MarkdownGuideNav from "@/components/markdown/MarkdownGuideNav";
```

--------------------------------

### Define GitHub Actions Test Workflow (YAML)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/stable-25-04/guides/addons/github-actions/installing/index.mdx

This YAML configuration defines a simple GitHub Actions workflow named 'Example'. It is triggered manually via 'workflow_dispatch'. The single job 'test' is configured to run on a self-hosted runner specified by 'runs-on: default'. The job contains one step that executes a basic 'echo "Hello World"' command using the bash shell. This workflow is used to verify the self-hosted runner setup.

```YAML
name: Example
on:
  workflow_dispatch: # This enables you to launch the workflow manually in the GitHub UI
jobs:
  test:
    runs-on: default # This should be the name of your runner in the `runners` input when you created it in the previous section
    steps:
      - name: "Hello world"
        shell: bash
        run: 'echo "Hello World"'
```

--------------------------------

### Example config.yaml (YAML)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/reference/configuration/kubernetes/index.mdx

Provides an example of the `config.yaml` file content, showing how to list the relative paths to AWS EKS modules within the `environments_dir` directory. This file guides the `pf-update-kube --build` process.

```yaml
clusters:
  - module: production/us-east-2/aws_eks
  - module: development/us-east-1/aws_eks
  - module: development/us-east-2/aws_eks
```

--------------------------------

### Configure Terragrunt for Kyverno Policies Deployment

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/guides/bootstrapping/policy-controller/index.mdx

This Terragrunt configuration file defines how to deploy the Kyverno policies module. It includes settings from a parent `panfactum.hcl`, specifies the Terraform source for the module, sets up a dependency on the `kube_kyverno` module, and defines inputs (though none are used in this basic example).

```HCL
include "panfactum" {
   path   = find_in_parent_folders("panfactum.hcl")
   expose = true
}

terraform {
   source = include.panfactum.locals.pf_stack_source
}

dependency "kyverno" {
   config_path  = "../kube_kyverno"
   skip_outputs = true
}

inputs = {}
```

--------------------------------

### Example GitHub Actions Workflow (YAML)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/edge/guides/addons/github-actions/installing/index.mdx

This YAML configuration defines a simple GitHub Actions workflow. It is triggered manually via `workflow_dispatch`, runs on a self-hosted runner specified by `runs-on: default`, and executes a single step that prints 'Hello World' using a bash shell.

```yaml
name: Example
on:
  workflow_dispatch: # This enables you to launch the workflow manually in the GitHub UI
jobs:
  test:
    runs-on: default # This should be the name of your runner in the `runners` input when you created it in the previous section
    steps:
      - name: "Hello world"
        shell: bash
        run: 'echo "Hello World"'
```

--------------------------------

### Configure .dockerignore for Build Context

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/edge/guides/addons/buildkit/installing/index.mdx

Sets up a `.dockerignore` file to control which files are sent to the BuildKit server as part of the build context. The example shows an ignore-by-default pattern with an exception.

```Text
# Ignore-by-default
*
# Example of including a specific file or directory
!some/path
```

--------------------------------

### Configure Kyverno Terragrunt Module

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/guides/bootstrapping/policy-controller/index.mdx

This Terragrunt configuration file defines the setup for the kube_kyverno module. It includes a parent configuration, specifies the Terraform source, and declares a dependency on the kube_cilium module, which is required before deploying Kyverno.

```HCL
include "panfactum" {
   path   = find_in_parent_folders("panfactum.hcl")
   expose = true
}

terraform {
   source = include.panfactum.locals.pf_stack_source
}

dependency "cilium" {
   config_path  = "../kube_cilium"
   skip_outputs = true
}

inputs = {}
```

--------------------------------

### Define GitHub Actions Test Workflow (YAML)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/guides/addons/github-actions/installing/index.mdx

This YAML configuration defines a simple GitHub Actions workflow named 'Example'. It is triggered manually via 'workflow_dispatch' and runs a single job 'test' on a self-hosted runner named 'default'. The job contains one step that prints 'Hello World' using a bash shell.

```yaml
name: Example
on:
  workflow_dispatch: # This enables you to launch the workflow manually in the GitHub UI
jobs:
  test:
    runs-on: default # This should be the name of your runner in the `runners` input when you created it in the previous section
    steps:
      - name: "Hello world"
        shell: bash
        run: 'echo "Hello World"'
```

--------------------------------

### Example config.yaml Configuration (YAML)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/edge/reference/configuration/kubernetes/index.mdx

Provides a YAML example of the `config.yaml` file content, illustrating how to list multiple cluster modules by their relative paths. This configuration guides the `pf-update-kube --build` command in locating cluster infrastructure definitions.

```yaml
clusters:
  - module: production/us-east-2/aws_eks
  - module: development/us-east-1/aws_eks
  - module: development/us-east-2/aws_eks
```

--------------------------------

### Example Output of pf-buildkit-build

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/guides/addons/buildkit/installing/index.mdx

This is an example of the expected output when running the `pf-buildkit-build` command successfully. It shows the scaling of BuildKit instances, the build process for both arm64 and amd64 architectures, pushing layers and manifests to ECR, exporting cache, and the final multi-platform digest.

```shellsession
statefulset.apps/buildkit-arm64 scaled
statefulset.apps/buildkit-amd64 scaled
arm64: Waiting 599 seconds for at least one BuildKit replica to become available...
amd64: Waiting 599 seconds for at least one BuildKit replica to become available...
arm64: Waiting 589 seconds for at least one BuildKit replica to become available...
amd64: #1 [internal] load build definition from ./Dockerfile
amd64: #1 transferring dockerfile: 29B 0.1s
arm64: #1 [internal] load build definition from ./Dockerfile
arm64: #1 transferring dockerfile: 54B 0.2s done
amd64: #1 transferring dockerfile: 54B 0.2s done
arm64: #1 DONE 0.2s
arm64:
arm64: #2 [internal] load metadata for docker.io/ubuntu/nginx:latest
amd64: #1 DONE 0.2s
amd64:
amd64: #2 [internal] load metadata for docker.io/ubuntu/nginx:latest
arm64: #2 DONE 0.4s
amd64: #2 DONE 0.4s
...
amd64: #6 exporting to image
amd64: #6 pushing layers 1.1s done
amd64: #6 pushing manifest for 891377197483.dkr.ecr.us-east-2.amazonaws.com/test:test-amd64@sha256:b6e2ca2f347b515a158fdb18bd1cb2f4c7b69ac5f9be9fa037bff62df2b7ffd1
arm64: #6 pushing manifest for 891377197483.dkr.ecr.us-east-2.amazonaws.com/test:test-arm64@sha256:b501fac8d78b9db276549bab5cc38784e0bfd7758062741f0716abbbbd690740 0.1s done
arm64: #6 DONE 1.1s
arm64:
arm64: #8 exporting cache to Amazon S3
arm64: #8 preparing build cache for export 0.1s done
arm64: #8 DONE 0.1s
amd64: #6 pushing manifest for 891377197483.dkr.ecr.us-east-2.amazonaws.com/test:test-amd64@sha256:b6e2ca2f347b515a158fdb18bd1cb2f4c7b69ac5f9be9fa037bff62df2b7ffd1 0.1s done
amd64: #6 DONE 1.1s
amd64:
amd64: #8 exporting cache to Amazon S3
amd64: #8 preparing build cache for export 0.1s done
amd64: #8 DONE 0.1s
Digest: sha256:3e2cb9822cabdb580c825d5bf3ec53e52df9d18871f1a0a1086f17d57b01f020 710
Closing build processes...
```

--------------------------------

### Vault Operator Init Output (Shell)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/edge/guides/bootstrapping/vault/index.mdx

Example output from the `vault operator init` command, showing the generated recovery keys and initial root token. These are required for unsealing and initial access.

```shellsession
Recovery Key 1: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Initial Root Token: hvs.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Success! Vault is initialized

Recovery key initialized with 1 key shares and a key threshold of 1. Please
securely distribute the key shares printed above.
```

--------------------------------

### Deploying Argo Event Bus Components using HCL

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/stable-25-04/guides/addons/event-bus/installing/index.mdx

This HCL snippet shows how to define the `event_bus`, `event_source`, and `sensor` modules to deploy an Argo Event Bus setup. It includes an example configuration for a webhook Event Source with multiple endpoints and a Sensor configured with dependencies to filter GitHub push events to the main branch and a log trigger.

```hcl
module "event_bus" {
  source =   "${var.pf_module_source}kube_argo_event_bus${var.pf_module_ref}"

  namespace = local.namespace
}

module "event_source" {
  source = "${var.pf_module_source}kube_argo_event_source${var.pf_module_ref}"

  name        = "example"
  namespace   = local.namespace
  vpa_enabled = var.vpa_enabled

  # For Active-Active EventSources, we recommend setting the replica count to 2.
  # For Active-Passive EventSources, we recommend setting the replica count to 1.
  # See https://argoproj.github.io/argo-events/eventsources/ha/
  replicas = 2

  event_source_spec = {

    # Note that this is just an example of one of the many types of EventSource specifications.
    # In this case, we are creating a webhook.
    # For the full list, see your these docs: https://argoproj.github.io/argo-events/eventsources/setup/amqp/
    #
    # Note that you can add multiple sources to a single EventSource object which
    # we recommend over creating multiple discrete EventSource objects as it reduces overall resource utilization.
    # See https://argoproj.github.io/argo-events/eventsources/multiple-events/
    webhook = {
      example = {
        active = true
        port = "12000"
        endpoint = "/example"
        method = "POST"
      }
      example2 = {
        active = true
        port = "12000"
        endpoint = "/example2"
        method = "POST"
      }
    }

    # For sources that receive messages over the network (e.g., webhooks), the EventSource will create
    # the necessary Kubernetes Service for you. You can re-use this single Service across multiple sources
    # (just ensure that you set different endpoints).
    #
    # That said, you will need to create your own Ingress. You can use our kube_ingress submodule for this.
    service = {
      ports = [
        {
          name = "default"
          port = 12000
          targetPort = 12000
        }
      ]
    }
  }
}

module "sensor" {
  source = "${var.pf_module_source}kube_argo_sensor${var.pf_module_ref}"

  name = "example"
  namespace = local.namespace
  vpa_enabled = var.vpa_enabled

  # The dependencies array lists all the events that the sensor will subscribe to.
  # It can contain multiple different filters for selecting only certain events:
  # https://argoproj.github.io/argo-events/sensors/filters/intro/
  #
  # This particular example assumes the events are GitHub webhook payloads and filters
  # for events generated when someone pushes to the main branch of a repository.
  dependencies = [
    {
      name = "push-to-main"
      eventSourceName = "example"
      eventName = "example" # This is the name of the source in the EventSource spec (i.e., the name of the webhook in this particular example)
      filters = {
        data = [
          {
            path = "body.X-GitHub-Event"
            type = "string"
            value = ["push"]
          },
          {
            path = "body.ref"
            type = "string"
            value = ["refs/heads/main"]
          }
        ]
      }
    }
  ]

  # Triggers are the actual actions that will get fired when an event is matched.
  # You can have many triggers on the same sensor, but this sensor just has one, a Log trigger (prints the event to stdout)
  # There are many different types of triggers available:
  # https://argoproj.github.io/argo-events/sensors/triggers/log/
  triggers = [
    {
      template = {

        # The conditions field controls which events will activate the trigger based on the filters provided
        # in the indicated dependencies. This supports boolean logic. See more here:
        # https://argoproj.github.io/argo-events/sensors/trigger-conditions/
        conditions = "push-to-main"

        name = "log"
        log = {
          intervalSeconds = 1
        }
      }
    }
  ]
}

```

--------------------------------

### Example NGINX Status Output (Shellsession)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/edge/guides/bootstrapping/inbound-networking/index.mdx

Example output from querying the internal 'nginx-status' service via a bastion tunnel using `curl localhost:3030/nginx_status`. This shows the active connections, server statistics, and current state (Reading, Writing, Waiting).

```shellsession
Active connections: 1
server accepts handled requests
 28680 28680 13962
Reading: 0 Writing: 1 Waiting: 0
```

--------------------------------

### Scaffolding Terragrunt Environment Config (Example)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/stable-25-04/guides/bootstrapping/configuring-infrastructure-as-code/index.mdx

An example demonstrating the use of the `pf-env-scaffold` script to set up Terragrunt configuration for 'management', 'production', and 'development' environments. This command creates the necessary directory structure and initial files.

```Shell
pf-env-scaffold -e management,production,development
```

--------------------------------

### Creating a Simple Dockerfile

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/guides/addons/buildkit/installing/index.mdx

Create a simple Dockerfile (`Dockerfile`) in the root of your repository. This example uses the `ubuntu/nginx` base image.

```dockerfile
FROM ubuntu/nginx
```

--------------------------------

### Configure Terragrunt for Kyverno Policies (HCL)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/edge/guides/bootstrapping/policy-controller/index.mdx

This Terragrunt configuration file defines the setup for deploying Kyverno policies. It includes a parent configuration, specifies the Terraform source for the module, and declares a dependency on the `kube_kyverno` module located in the parent directory. This setup ensures the policies are applied after Kyverno is installed.

```hcl
include "panfactum" {
   path   = find_in_parent_folders("panfactum.hcl")
   expose = true
}

terraform {
   source = include.panfactum.locals.pf_stack_source
}

dependency "kyverno" {
   config_path  = "../kube_kyverno"
   skip_outputs = true
}

inputs = {}
```

--------------------------------

### Building and Starting Local Website (bash)

Source: https://github.com/panfactum/stack/blob/main/packages/scraper/README.md

Runs the build process for the local website using next build and then starts the built application using next start, preparing the site for scraping.

```bash
npx next build && npx next start
```

--------------------------------

### Example BuildKit config.yaml

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/edge/reference/configuration/buildkit/index.mdx

This snippet provides an example configuration for the `.buildkit/config.yaml` file. It demonstrates how to specify the `bastion` for SSH connection and the relative path to the `kube_buildkit` module deployment.

```yaml
bastion: production-primary
module: production/us-east-2/kube_buildkit
```

--------------------------------

### Define Simple Dockerfile

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/edge/guides/addons/buildkit/installing/index.mdx

Creates a basic Dockerfile that uses the `ubuntu/nginx` image as its base. This file defines the steps to build the container image.

```Dockerfile
FROM ubuntu/nginx
```

--------------------------------

### Install Linkerd Viz Extension (Bash)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/guides/bootstrapping/service-mesh/index.mdx

Installs the Linkerd Viz debugging and visualization extension by piping the output of `linkerd viz install` to `kubectl apply`.

```bash
linkerd viz install | kubectl apply -f -
```

--------------------------------

### Bootstrapping Guide Navigation Component (JSX)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/guides/bootstrapping/inbound-networking/index.mdx

A JSX component used for navigation within the bootstrapping guide documentation, providing links to the previous and next steps.

```JSX
<BootstrappingGuideNav backHref={"/docs/main/guides/bootstrapping/autoscaling"} forwardHref={"/docs/main/guides/bootstrapping/maintenance-controllers"} stepNumber={16} />
```

--------------------------------

### Example config.yaml Configuration

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/stable-25-04/reference/configuration/buildkit/index.mdx

This YAML snippet provides a concrete example of the `config.yaml` file. It shows how to specify the 'bastion' name for SSH connection and the relative 'module' path to the kube_buildkit deployment.

```YAML
bastion: production-primary
module: production/us-east-2/kube_buildkit
```

--------------------------------

### Installing Linkerd Viz Extension (Bash)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/stable-25-04/guides/bootstrapping/service-mesh/index.mdx

Run this command to install the temporary Linkerd Viz debugging suite by piping the output of `linkerd viz install` directly to `kubectl apply -f -`, deploying the necessary components into the cluster.

```bash
linkerd viz install | kubectl apply -f -
```

--------------------------------

### Example NGINX Ingress Controller Logs

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/guides/bootstrapping/inbound-networking/index.mdx

Provides example log entries from the NGINX ingress controller, showing details of incoming HTTP requests to the Vault domain. Each log entry is a JSON object containing information like TLS version, cipher, URL, status code, method, host, user agent, timestamp, remote address, response length, duration, and request ID.

```Shell
ingress-nginx-controller-c87487976-gd9cn controller {"tls.version": "TLSv1.3", "tls.cipher": "TLS_AES_256_GCM_SHA384", "http.url": "/v1/sys/seal-status", "http.version": "HTTP/2.0", "http.status_code": "200", "http.method": "GET", "http.referer": "", "http.origin": "", "http.host": "vault.prod.panfactum.com", "http.useragent":"Mozilla/5.0 (X11; Linux x86_64; rv:122.0) Gecko/20100101 Firefox/122.0", "time":"2024-03-26T20:58:54+00:00", "remote_addr": "X.X.X.X", "remote_user": "", "response_length": 667, "duration": 0.003, "request_id": "b2718b569ed881072fbe7682a2cc635d", "request_length": 29, "response_content_type": "application/json", "x_forwarded_for": "X.X.X.X"}
ingress-nginx-controller-c87487976-gd9cn controller {"tls.version": "TLSv1.3", "tls.cipher": "TLS_AES_256_GCM_SHA384", "http.url": "/v1/sys/health?standbycode=200&sealedcode=200&uninitcode=200&drsecondarycode=200&performancestandbycode=200", "http.version": "HTTP/2.0", "http.status_code": "200", "http.method": "GET", "http.referer": "", "http.origin": "", "http.host": "vault.prod.panfactum.com", "http.useragent":"Mozilla/5.0 (X11; Linux x86_64; rv:122.0) Gecko/20100101 Firefox/122.0", "time":"2024-03-26T20:58:54+00:00", "remote_addr": "X.X.X.X", "remote_user": "", "response_length": 638, "duration": 0.004, "request_id": "dca72e8c51d359bcfcd4c702c53d85a8", "request_length": 90, "response_content_type": "application/json", "x_forwarded_for": "X.X.X.X"}
ingress-nginx-controller-c87487976-gd9cn controller {"tls.version": "TLSv1.3", "tls.cipher": "TLS_AES_256_GCM_SHA384", "http.url": "/v1/sys/seal-status", "http.version": "HTTP/2.0", "http.status_code": "200", "http.method": "GET", "http.referer": "", "http.origin": "", "http.host": "vault.prod.panfactum.com", "http.useragent":"Mozilla/5.0 (X11; Linux x86_64; rv:122.0) Gecko/20100101 Firefox/122.0", "time":"2024-03-26T20:59:04+00:00", "remote_addr": "X.X.X.X", "remote_user": "", "response_length": 667, "duration": 0.020, "request_id": "7296f3e527c7dab1e2868b81e6252c32", "request_length": 29, "response_content_type": "application/json", "x_forwarded_for": "X.X.X.X"}
```

--------------------------------

### Allow Direnv Environment Loading (shellsession)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/stable-25-04/guides/getting-started/boot-developer-environment/index.mdx

This command is executed in the terminal to grant `direnv` permission to load the `.envrc` file in the current directory. Running this command is necessary to proceed with the automated setup and installation defined in the `.envrc`.

```shellsession
direnv allow
```

--------------------------------

### Example config.yaml Configuration

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/stable-25-04/reference/configuration/aws/index.mdx

Illustrates a sample `config.yaml` file demonstrating the configuration of SSO settings, default region, module path, and an example entry for `extra_roles`.

```yaml
sso_start_url: https://panfactum.awsapps.com/start
sso_region: us-east-2
default_aws_region: us-east-2
module: management/global/aws_iam_identity_center_permissions
extra_roles:
  - account_name: test
    account_id: 1234567
    roles: ["TestRole1", "TestRole2"]
```

--------------------------------

### Example cluster_info File Format

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/stable-25-04/reference/configuration/kubernetes/index.mdx

Example content of the `cluster_info` file. This space-delimited file is generated by `pf-update-kube --build` and contains essential metadata for each cluster: name, region, API server URL, and the MD5 hash of the CA certificate data.

```yaml
production-primary us-east-2 https://83063DDB274B2A04B6A7DC29DCB1740E.gr7.us-east-2.eks.amazonaws.com 44f5cb46f1d07e4f3806f26cc4424d97
development-primary us-east-2 https://6B4CCB112AD882D9331473BA90CB8F80.yl4.us-east-2.eks.amazonaws.com b56614e34b012836c761ac2c1b816ada
```

--------------------------------

### Example config.user.yaml (YAML)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/reference/configuration/kubernetes/index.mdx

Provides an example of the `config.user.yaml` file content, showing how a user specifies which clusters they need access to and which AWS profile should be used for authentication with each. This file is used by `pf-update-kube`.

```yaml
clusters:
  - name: "production-primary"
    aws_profile: "production-superuser"
```

--------------------------------

### Installing Linkerd Viz Extension (Shell)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/edge/guides/bootstrapping/service-mesh/index.mdx

Installs the Linkerd Viz extension, a debugging and visualization suite, by piping the output of `linkerd viz install` directly into `kubectl apply -f -`. This deploys the necessary Kubernetes resources for the Viz dashboard and related components.

```shell
linkerd viz install | kubectl apply -f -
```

--------------------------------

### Example cluster_info file content

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/reference/configuration/kubernetes/index.mdx

Shows an example of the `cluster_info` file content. This file is generated by `pf-update-kube --build` and contains space-delimited metadata for each cluster, including name, region, API server URL, and CA certificate hash.

```yaml
production-primary us-east-2 https://83063DDB274B2A04B6A7DC29DCB1740E.gr7.us-east-2.eks.amazonaws.com 44f5cb46f1d07e4f3806f26cc4424d97
development-primary us-east-2 https://6B4CCB112AD882D9331473BA90CB8F80.yl4.us-east-2.eks.amazonaws.com b56614e34b012836c761ac2c1b816ada
```

--------------------------------

### Deploying Argo Event Bus Components using HCL

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/edge/guides/addons/event-bus/installing/index.mdx

This HCL snippet demonstrates the recommended pattern for deploying the Argo Event Bus, Event Source, and Sensor components using pre-defined modules. It shows how to configure the event bus, define an event source (specifically a webhook example), and set up a sensor with dependencies and triggers to react to specific events.

```HCL
module "event_bus" {
  source =   "${var.pf_module_source}kube_argo_event_bus${var.pf_module_ref}"

  namespace = local.namespace
}

module "event_source" {
  source = "${var.pf_module_source}kube_argo_event_source${var.pf_module_ref}"

  name        = "example"
  namespace   = local.namespace
  vpa_enabled = var.vpa_enabled

  # For Active-Active EventSources, we recommend setting the replica count to 2.
  # For Active-Passive EventSources, we recommend setting the replica count to 1.
  # See https://argoproj.github.io/argo-events/eventsources/ha/
  replicas = 2

  event_source_spec = {

    # Note that this is just an example of one of the many types of EventSource specifications.
    # In this case, we are creating a webhook.
    # For the full list, see your these docs: https://argoproj.github.io/argo-events/eventsources/setup/amqp/
    #
    # Note that you can add multiple sources to a single EventSource object which
    # we recommend over creating multiple discrete EventSource objects as it reduces overall resource utilization.
    # See https://argoproj.github.io/argo-events/eventsources/multiple-events/
    webhook = {
      example = {
        active = true
        port = "12000"
        endpoint = "/example"
        method = "POST"
      }
      example2 = {
        active = true
        port = "12000"
        endpoint = "/example2"
        method = "POST"
      }
    }

    # For sources that receive messages over the network (e.g., webhooks), the EventSource will create
    # the necessary Kubernetes Service for you. You can re-use this single Service across multiple sources
    # (just ensure that you set different endpoints).
    #
    # That said, you will need to create your own Ingress. You can use our kube_ingress submodule for this.
    service = {
      ports = [
        {
          name = "default"
          port = 12000
          targetPort = 12000
        }
      ]
    }
  }
}

module "sensor" {
  source = "${var.pf_module_source}kube_argo_sensor${var.pf_module_ref}"

  name = "example"
  namespace = local.namespace
  vpa_enabled = var.vpa_enabled

  # The dependencies array lists all the events that the sensor will subscribe to.
  # It can contain multiple different filters for selecting only certain events:
  # https://argoproj.github.io/argo-events/sensors/filters/intro/
  #
  # This particular example assumes the events are GitHub webhook payloads and filters
  # for events generated when someone pushes to the main branch of a repository.
  dependencies = [
    {
      name = "push-to-main"
      eventSourceName = "example"
      eventName = "example" # This is the name of the source in the EventSource spec (i.e., the name of the webhook in this particular example)
      filters = {
        data = [
          {
            path = "body.X-GitHub-Event"
            type = "string"
            value = ["push"]
          },
          {
            path = "body.ref"
            type = "string"
            value = ["refs/heads/main"]
          }
        ]
      }
    }
  ]

  # Triggers are the actual actions that will get fired when an event is matched.
  # You can have many triggers on the same sensor, but this sensor just has one, a Log trigger (prints the event to stdout)
  # There are many different types of triggers available:
  # https://argoproj.github.io/argo-events/sensors/triggers/log/
  triggers = [
    {
      template = {

        # The conditions field controls which events will activate the trigger based on the filters provided
        # in the indicated dependencies. This supports boolean logic. See more here:
        # https://argoproj.github.io/argo-events/sensors/trigger-conditions/
        conditions = "push-to-main"

        name = "log"
        log = {
          intervalSeconds = 1
        }
      }
    }
  ]
}

```

--------------------------------

### Example Linkerd Viz Tap Output

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/edge/guides/bootstrapping/service-mesh/index.mdx

Shows example output from a `linkerd viz tap` session monitoring traffic between a cert-manager pod and a Vault pod. It demonstrates how the service mesh sidecar handles TLS (`tls=true`) even if the application isn't configured for it.

```shell
req id=0:0 proxy=in  src=10.0.186.223:40976 dst=10.0.232.215:8200 tls=true :method=POST :authority=vault-active.vault.svc.cluster.local:8200 :path=/v1/auth/kubernetes/login
rsp id=0:0 proxy=in  src=10.0.186.223:40976 dst=10.0.232.215:8200 tls=true :status=200 latency=69451µs
end id=0:0 proxy=in  src=10.0.186.223:40976 dst=10.0.232.215:8200 tls=true duration=57µs response-length=763B
req id=0:1 proxy=in  src=10.0.186.223:40976 dst=10.0.232.215:8200 tls=true :method=POST :authority=vault-active.vault.svc.cluster.local:8200 :path=/v1/pki/internal/sign/vault-issuer
rsp id=0:1 proxy=in  src=10.0.186.223:40976 dst=10.0.232.215:8200 tls=true :status=200 latency=56146µs
end id=0:1 proxy=in  src=10.0.186.223:40976 dst=10.0.232.215:8200 tls=true duration=210µs response-length=3914B
```

--------------------------------

### Integrate Panfactum devShell using Nix

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/guides/bootstrapping/installing-devshell/index.mdx

Create a `flake.nix` file at the root of your repository to define a Nix flake that uses `flake-utils` and the `panfactum` input to create a development shell (`devShell`) compatible with all default systems. This shell automatically installs necessary tooling.

```Nix
{
  inputs = {
     # Utility for generating flakes that are compatible with all operating systems
    flake-utils.url = "github:numtide/flake-utils";

    # Make sure this matches your version of the Panfactum Stack
    panfactum.url = "github:panfactum/stack/__PANFACTUM_VERSION_MAIN__"; 
  };

  outputs = { panfactum, flake-utils, ... }@inputs:
    flake-utils.lib.eachDefaultSystem
    (system:
      {
        devShell = panfactum.lib.${system}.mkDevShell { };
      }
    );
}
```

--------------------------------

### Example config.user.yaml Configuration (YAML)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/edge/reference/configuration/kubernetes/index.mdx

Provides a YAML example of `config.user.yaml`, showing how to specify a target cluster by its name and the AWS profile to use for authentication. This file is essential for `pf-update-kube` to configure user access based on permissions.

```yaml
clusters:
  - name: "production-primary"
    aws_profile: "production-superuser"
```

--------------------------------

### Example BuildKit Registry Authentication Config (JSON5)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/stable-25-04/guides/addons/buildkit/building-images/index.mdx

Provides an example of the `config.json` file used by BuildKit for authenticating with private container registries. It includes sections for `auths` (for specific registry credentials) and `credHelpers` (for using external credential helpers like 'panfactum' for ECR).

```json5
{
	"auths": {
		"ghcr.io": {
			"auth": "some auth token"
		}
	},
	"credHelpers": {
		"<buildkit-account-id>.dkr.ecr.<buildkit-region>.amazonaws.com": "panfactum",
		"public.ecr.aws": "panfactum"
	}
}
```

--------------------------------

### Example AWS Config YAML File

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/reference/configuration/aws/index.mdx

Provides a concrete example of the `config.yaml` file structure. It demonstrates how to configure AWS IAM Identity Center (SSO) settings, set a default AWS region, specify an optional module path, and define static `extra_roles` for specific accounts with associated permission sets.

```YAML
sso_start_url: https://panfactum.awsapps.com/start
sso_region: us-east-2
default_aws_region: us-east-2
module: management/global/aws_iam_identity_center_permissions
extra_roles:
  - account_name: test
    account_id: 1234567
    roles: ["TestRole1", "TestRole2"]
```

--------------------------------

### Running pf-buildkit-build Command

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/guides/addons/buildkit/installing/index.mdx

Use the `pf-buildkit-build` utility to automatically submit your builds to BuildKit. This command handles scaling BuildKit instances, selecting the best instance, establishing a secure tunnel, building for multiple platforms (arm64 and amd64), setting up cache, pushing to ECR, and generating the multi-platform manifest.

```shell
pf-buildkit-build --repo=test --tag=test --context=. --file=./Dockerfile
```

--------------------------------

### Importing RootDocumentLandingPage Component (JSX)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/guides/index.mdx

Imports the `RootDocumentLandingPage` component from the local `./index.tsx` file, making it available for use within this document.

```JSX
import { RootDocumentLandingPage } from "./index.tsx";
```

--------------------------------

### Running the Built Image Locally with Podman

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/guides/addons/buildkit/installing/index.mdx

Pull and run the built multi-platform image locally using Podman. Replace the example registry URI with your actual ECR registry name. Running this command from inside the repository will leverage the devShell for automatic registry authentication.

```shell
podman run --rm -it 891377197483.dkr.ecr.us-east-2.amazonaws.com/test:test
```

--------------------------------

### Rendering RootDocumentLandingPage Component (JSX)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/guides/index.mdx

Renders the imported `RootDocumentLandingPage` component using a self-closing JSX tag, displaying the main content defined by that component.

```JSX
<RootDocumentLandingPage />
```

--------------------------------

### Starting Local Development Server (pnpm)

Source: https://github.com/panfactum/stack/blob/main/packages/website/README.md

This command uses pnpm to start a local development server for the Panfactum website. The server will typically be accessible at http://localhost:4321, allowing developers to preview changes in real-time.

```Shell
pnpm run dev
```

--------------------------------

### Rendering RootDocumentLandingPage Component - JSX

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/edge/guides/index.mdx

Renders the imported RootDocumentLandingPage component. This is the primary element displayed on the page, responsible for presenting the landing page content.

```JSX
<RootDocumentLandingPage />
```

--------------------------------

### Importing RootDocumentLandingPage Component - JavaScript/TypeScript

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/stable-25-04/guides/index.mdx

Imports the RootDocumentLandingPage component from the local ./index.tsx file. This component is likely used to render the main content of the landing page.

```JavaScript
import { RootDocumentLandingPage } from "./index.tsx";
```

--------------------------------

### Example cluster_info File Content (YAML)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/edge/reference/configuration/kubernetes/index.mdx

Shows an example of the `cluster_info` file content, which is a space-delimited file generated by `pf-update-kube --build`. Each line contains metadata for a cluster, including its name, region, API server URL, and the MD5 hash of the CA certificate data. This file is a prerequisite for running `pf-update-kube` to generate user kubeconfigs.

```yaml
production-primary us-east-2 https://83063DDB274B2A04B6A7DC29DCB1740E.gr7.us-east-2.eks.amazonaws.com 44f5cb46f1d07e4f3806f26cc4424d97
development-primary us-east-2 https://6B4CCB112AD882D9331473BA90CB8F80.yl4.us-east-2.eks.amazonaws.com b56614e34b012836c761ac2c1b816ada
```

--------------------------------

### Rendering RootDocumentLandingPage Component - JSX

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/stable-25-04/guides/index.mdx

Renders the imported RootDocumentLandingPage component as a self-closing JSX element. This is the primary way the component is used within the page's structure.

```JSX
<RootDocumentLandingPage />
```

--------------------------------

### Example BuildKit Build Output (shellsession)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/stable-25-04/guides/addons/buildkit/installing/index.mdx

Shows typical output from the `pf-buildkit-build` command, indicating the scaling of BuildKit instances, build progress for different architectures (arm64, amd64), pushing layers and manifests to ECR, and exporting build cache.

```shellsession
statefulset.apps/buildkit-arm64 scaled
statefulset.apps/buildkit-amd64 scaled
arm64: Waiting 599 seconds for at least one BuildKit replica to become available...
amd64: Waiting 599 seconds for at least one BuildKit replica to become available...
arm64: Waiting 589 seconds for at least one BuildKit replica to become available...
amd64: #1 [internal] load build definition from ./Dockerfile
amd64: #1 transferring dockerfile: 29B 0.1s
arm64: #1 [internal] load build definition from ./Dockerfile
arm64: #1 transferring dockerfile: 54B 0.2s done
amd64: #1 transferring dockerfile: 54B 0.2s done
arm64: #1 DONE 0.2s
arm64:
arm64: #2 [internal] load metadata for docker.io/ubuntu/nginx:latest
amd64: #1 DONE 0.2s
amd64:
amd64: #2 [internal] load metadata for docker.io/ubuntu/nginx:latest
arm64: #2 DONE 0.4s
amd64: #2 DONE 0.4s
...
amd64: #6 exporting to image
amd64: #6 pushing layers 1.1s done
amd64: #6 pushing manifest for 891377197483.dkr.ecr.us-east-2.amazonaws.com/test:test-amd64@sha256:b6e2ca2f347b515a158fdb18bd1cb2f4c7b69ac5f9be9fa037bff62df2b7ffd1
arm64: #6 pushing manifest for 891377197483.dkr.ecr.us-east-2.amazonaws.com/test:test-arm64@sha256:b501fac8d78b9db276549bab5cc38784e0bfd7758062741f0716abbbbd690740 0.1s done
arm64: #6 DONE 1.1s
arm64:
arm64: #8 exporting cache to Amazon S3
arm64: #8 preparing build cache for export 0.1s done
arm64: #8 DONE 0.1s
amd64: #6 pushing manifest for 891377197483.dkr.ecr.us-east-2.amazonaws.com/test:test-amd64@sha256:b6e2ca2f347b515a158fdb18bd1cb2f4c7b69ac5f9be9fa037bff62df2b7ffd1 0.1s done
amd64: #6 DONE 1.1s
amd64:
amd64: #8 exporting cache to Amazon S3
amd64: #8 preparing build cache for export 0.1s done
amd64: #8 DONE 0.1s
Digest: sha256:3e2cb9822cabdb580c825d5bf3ec53e52df9d18871f1a0a1086f17d57b01f020 710
Closing build processes...
```

--------------------------------

### Importing RootDocumentLandingPage Component - TypeScript

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/edge/guides/index.mdx

Imports the RootDocumentLandingPage component from the local ./index.tsx file. This component is likely used to render the main content and layout of the landing page.

```TypeScript
import { RootDocumentLandingPage } from "./index.tsx";
```

--------------------------------

### Example Stack Repository Layout (TXT)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/guides/iac/first-party-modules/index.mdx

Illustrates the typical directory structure for a stack repository, showing the organization of environments, regions, and infrastructure modules.

```txt
environments/
   - development/
     - environment.yaml
     - us-east-2/
        - module1/
        - module2/
   - staging/
     - environment.yaml
     - us-east-2/
        - module1/
        - module2/
   - production/
     - environment.yaml
     - us-east-2/
        - module1/
        - module2/
     - us-west-2/
        - region.yaml
        - module1/
        - module2/
infrastructure/
   - module1/
   - module2/
```

--------------------------------

### Example Stack Repository Layout

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/stable-25-04/guides/iac/first-party-modules/index.mdx

Illustrates the typical directory structure of a stack repository, showing the organization of environments, regions, and infrastructure modules.

```txt
environments/
   - development/
     - environment.yaml
     - us-east-2/
        - module1/
        - module2/
   - staging/
     - environment.yaml
     - us-east-2/
        - module1/
        - module2/
   - production/
     - environment.yaml
     - us-east-2/
        - module1/
        - module2/
     - us-west-2/
        - region.yaml
        - module1/
        - module2/
infrastructure/
   - module1/
   - module2/
```

--------------------------------

### Define Simple Nginx Docker Image (Dockerfile)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/stable-25-04/guides/addons/buildkit/installing/index.mdx

Creates a basic Dockerfile that uses the `ubuntu/nginx` image as its base. This file defines the steps to build the container image.

```dockerfile
FROM ubuntu/nginx
```

--------------------------------

### Execute Multi-Platform Build with pf-buildkit-build

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/edge/guides/addons/buildkit/installing/index.mdx

Runs the `pf-buildkit-build` utility to initiate a remote multi-platform build using BuildKit. Specifies the repository name, tag, build context, and Dockerfile location.

```Shell
pf-buildkit-build --repo=test --tag=test --context=. --file=./Dockerfile
```

--------------------------------

### Clean Up Cilium Test Resources

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/guides/bootstrapping/policy-controller/index.mdx

This command is used to delete the Kubernetes namespace and all resources created by the Cilium connectivity test after the test has completed.

```Shell
kubectl delete ns cilium-test
```

--------------------------------

### Vault Operator Members Output (Shell)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/edge/guides/bootstrapping/vault/index.mdx

Example output from the `vault operator members` command, listing the nodes in the Vault cluster and their status (active/standby).

```shellsession
Host Name    API Address                 Cluster Address                        Active Node    Version    Upgrade Version    Redundancy Zone    Last Echo
---------    -----------                 ---------------                        -----------    -------    ---------------    ---------------    ---------
vault-2      http://10.0.114.250:8200    https://vault-2.vault-internal:8201    false          1.15.2     1.15.2             n/a                2024-03-19T15:04:52Z
vault-0      http://10.0.178.10:8200     https://vault-0.vault-internal:8201    true           1.15.2     1.15.2             n/a                n/a
vault-1      http://10.0.212.45:8200     https://vault-1.vault-internal:8201    false          1.15.2     1.15.2             n/a                2024-03-19T15:04:52Z
```

--------------------------------

### Example Repository Layout for First-Party Modules (txt)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/main/guides/iac/first-party-modules/index.mdx

Illustrates a typical repository layout showing environment-specific Terragrunt configurations alongside the first-party infrastructure modules, explaining the default sourcing behavior.

```txt
environments/
   - development/
     - us-east-2/
        - module1/
          - terragrunt.hcl
          - module.yaml
infrastructure/
   - module1/
   - module2/
```

--------------------------------

### Vault Operator Unseal Output (Shell)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/edge/guides/bootstrapping/vault/index.mdx

Example output from the `vault operator unseal` command, showing the status of the Vault node. The `Sealed` field indicates whether the node is operational.

```shellsession
Key                      Value
---
Recovery Seal Type       shamir
Initialized              true
Sealed                   false
Total Recovery Shares    1
Threshold                1
Version                  1.15.2
Build Date               2023-11-06T11:33:28Z
Storage Type             raft
Cluster Name             vault-cluster-0d4df53a
Cluster ID               ecc7f4ba-0c8e-3eca-2ad6-515ff027202e
HA Enabled               true
HA Cluster               https://vault-0.vault-internal:8201
HA Mode                  active
Active Since             2024-03-19T14:36:28.434643111Z
Raft Committed Index     58
Raft Applied Index       58
```

--------------------------------

### Direnv DevShell Building Output (shellsession)

Source: https://github.com/panfactum/stack/blob/main/packages/website/src/content/docs/stable-25-04/guides/getting-started/boot-developer-environment/index.mdx

This output indicates that `direnv` is actively processing the `.envrc` file and setting up the defined development shell environment. It signifies the start of the automated installation and configuration process for the required tooling.

```shellsession
direnv: loading ~/repos/your-repo/.envrc
Building shell ...
```