Applications

The applications array in .greyhound/applications.yaml defines which repositories greyhound should import and how to track them. Each entry represents a primary application — a GitHub repository containing a .greyhound/config.yaml that greyhound will use to build the deployment topology.

Defining an Application

At minimum, an application needs a name, a repository, and a branch or tag to track:

applications:
  - name: api
    repository: your-org/api
    branch: main

Field	Description
name	Unique identifier for the application (RFC 1123 compliant)
repository	GitHub repository in owner/repo format (min 3 characters per segment)
branch	Git branch to track — mutually exclusive with tag
tag	Git tag to track — mutually exclusive with branch

Config Source

By default, greyhound looks for .greyhound/config.yaml in the repository root. Override this with config_source:

applications:
  - name: api
    repository: your-org/api
    branch: main
    config_source: .greyhound/api-config.yaml

Default Cluster

Set default_cluster to specify which EKS cluster environments should be provisioned to by default. Environments can override this with their own cluster field:

applications:
  - name: api
    repository: your-org/api
    branch: main
    default_cluster: shared-nonprod-eks

Deployment Behavior

Control how and when deployments happen:

applications:
  - name: api
    repository: your-org/api
    branch: main
    auto_deploy: true
    same_namespace: true
    redeploy_all_children: false

Field	Default	Description
auto_deploy	true	Automatically deploy environments after provisioning
same_namespace	true	Run all services in the same Kubernetes namespace
redeploy_all_children	—	When set, any push to this repository redeploys every child service

Child Applications

Applications can depend on other services that live in separate repositories. These are declared as additional_applications (required) or optional_applications (may be skipped by environments).

Required Children

Required child applications are always included when an environment imports this application:

applications:
  - name: api
    repository: your-org/api
    branch: main
    additional_applications:
      - name: auth-service
        repository: your-org/auth
        branch: main
        redeploy_with_any_change: true
      - name: notification-service
        repository: your-org/notifications
        branch: main

Each child application supports the same repository, branch, tag, and config_source fields as the parent. The redeploy_with_any_change flag (defaults to true) controls whether pushes to the parent repository also redeploy this child.

Optional Children

Optional child applications may be excluded by specific environments using removed_services:

applications:
  - name: api
    repository: your-org/api
    branch: main
    optional_applications:
      - name: debug-tools
        repository: your-org/debug-tools
        branch: main

Database Pools

Attach Aurora database pools to an application. These pools are automatically associated with all environments that import this application, unless the environment overrides them:

applications:
  - name: api
    repository: your-org/api
    branch: main
    default_database_pools:
      - shared-aurora-pool
      - analytics-pool

Resource Shares

Share resources (services, rules, endpoints, environment variables) between environments. This is useful when one environment needs to reference resources deployed in another:

applications:
  - name: api
    repository: your-org/api
    branch: main
    resource_shares:
      - source_environment: staging
        target_environment: dev
        resource_type: Endpoint
        resource_name: api-endpoint
        exposed_as: upstream-api

Each resource share supports:

Field	Description
source_environment	Environment exporting the resource
target_environment	Environment receiving the resource
resource_type	Service, Rule, Endpoint, or EnvironmentVariable
resource_name	Name of the resource being shared
exposed_as	Optional alias in the target environment
fallback_value	Value to use if the source resource is unavailable
fallback_environment	Alternative source environment to try

Variable Overrides

Override environment variables for specific services during provisioning:

applications:
  - name: api
    repository: your-org/api
    branch: main
    variable_overrides:
      - service_name: api
        variable_name: LOG_LEVEL
        variable_value: debug
        priority: 5

Field	Default	Description
service_name	—	Service to apply the override to
variable_name	—	Environment variable name
variable_value	—	Value to set
fallback_value	—	Fallback if the primary value can't be resolved
priority	10	Lower numbers take precedence when multiple overrides target the same variable

Schema Reference

See the App Imports schema for the full configuration reference.