Custom Configuration

While Halyard handles the majority of Spinnaker configuration, there will always be feature flags and properties either too new or niche to be supported by Halyard. Furthermore, some users will be more comfortable forgoing Halyard’s configuration generation, or will want to port their old Spinnaker configuration into Halyard. For these users & use-cases, Halyard supports custom Profiles, and custom Service Settings.

Custom Profiles

If you want to supply custom Profiles, for a particular Deployment ($DEPLOYMENT, typically default) place them in ~/.hal/$DEPLOYMENT/profiles/. The will override any profiles generated by Halyard, and will be copied over by Profile name.

For example, if you want to supply a different clouddriver.yml, you can do so by placing it in ~/.hal/$DEPLOYMENT/profiles/clouddriver.yml, and running hal deploy apply.

For any of the Spring based services, any profile matching ${SERVICENAME}-.*\.yml will be copied and applied to $SERVICENAME. Since this approach will completely overwrite the generated service, and you may want to only supply a few flags, you can instead provide them in ${SERVICENAME}-local.yml, which will always be loaded by $SERVICENAME with no further configuration needed. Further Spring Profiles can be activated by configuring their env to include SPRING_PROFILES_ACTIVE entries for your desired service. See the below Custom Service Settings for more information.

You can validate that your Custom Profiles have been picked up and applied to their services by checking ~/.hal/$DEPLOYMENT/history/service-profiles.yml.

Custom Service Settings

For each service, $SERVICENAME, you can supply a file ~/.hal/$DEPLOYMENT/service-settings/$SERVICENAME.yml to override any settings as found in ~/.hal/$DEPLOYMENT/history/service-settings.yml. For example, if you wanted Echo to listen on port 443 with the JAVA_OPTS="-Xms256m -Xmx512m" environment variables set, you create the following file:


port: 443
  JAVA_OPTS: "-Xms256m -Xmx512m"

If you wanted to specify a secure connection to redis, you would create the following file:


overrideBaseUrl: redis://someuser:[email protected]:6379

Tweakable Service Settings

Below are all the Service Settings you can configure. Keep in mind the ones generated by Halyard are generally best and are all that we test, so there is no guarantee making changes to these will result in a working Spinnaker cluster.

Value Description
address The address other services will use to lookup this service; e.g. localhost or redis.service.spinnaker.consul.
artifactId A fully-qualified identifier for the Artifact this service is to run - see your Service Settings output path for examples, since this varies by platform/deployment environment.
basicAuthEnabled Whether or not to enable HTTP basic auth for this service.
enabled Whether or not this service is enabled. Be careful, since disabling critical services like consul-client can make your entire installation unusable and un-upgradable.
env Environment variables to make available to this Service. Supplied as YAML key-value pairs.
healthEndpoint The HTTP endpoint that can be queried for health status. Leave empty if you want Halyard to simply check that a TCP connection is openable. This information is typically transmitted to the platform’s discovery system.
host The host that this service will bind to. will always work, but more restrictive bindings may be more secure.
kubernetes You can add Kubernetes specific service settings, see details below.
location The Spinnaker “location” this will be installed in. This is a namespace in Kubernetes, and a zone in GCE.
monitored Whether or not this has monitoring endpoints exposed and understood by spinnaker-monitoring.
overrideBaseUrl The baseURL this service is reachable on. This is already made configurable for Deck & Gate via hal config security, since these are both public-facing and may service from different hosts than they are discoverable on internal to Spinnaker.
port The port number this service is bound to, and will accept requests on.
safeToUpdate Whether or not this service can be shutdown, and spun on a new VM/container. This protects datastores like Vault & Redis from being taken down from Halyard.
scheme The URI scheme used to address this service, e.g. http vs. https.
skipLifeCycleManagement Whether or not Halyard should skip managing a service’s life cycle.
targetSize The initial number of nodes this service will be created with. This is only respected on the initial deployment, and further edits will be rejected in favor of the prior service version’s size.


The following Kubernetes specific setting can be specified


If making use of custom artifactIds from an authenticated docker registry imagePullSecrets must be made available in the replicaset definition. To specify imagePullSecrets to custom artifactIds they can be specified as follows:

  - desired-image-pull-secret1
  - desired-image-pull-secret2


Annotations can often be used to specify special behavior within Kubernetes. To apply annotations to the Pods for a particular service, use the following configuration:

    example/annotation-2: halyard


by default halyard deploys services with an exec based health check in order to improve compatibility with istio. This however can break functionality for implementations of Load Balancer service types and Ingress Controllers that rely on having a http health check to validate. Setting kubernetes.useExecHealthCheck: false will switch the check method to be http based for such use cases.