Waypoint 0.8 Adds Secret Values for Input Variables

HashiCorp Waypoint 0.8 introduces targetable runners, secret values for input variables, and a new command line tool that adds new insight to Waypoint operations.

We are excited to announce the general availability of HashiCorp Waypoint 0.8. Waypoint is an application deployment tool that aims to deliver a PaaS-like experience for Kubernetes, Amazon ECS, and other platforms.

This release adds several significant new features, including secret values for input variables, targetable runners, runner adoption, instance counts in deployment status reports, and a Waypoint job command line tool for job introspection:

»Secret Values for Input Variables

Waypoint 0.8 brings additional enhancements to Waypoint’s input variables system. Users will now see the final set of input variable values used as part of the output for a build, deploy, release, or up operation. To ensure that sensitive values are not so easily displayed, Waypoint now allows marking a variable as sensitive in the variable-declaration block. Sensitive variables will have their values displayed as a SHA256 hashed value, composed of the server cookie as the salt along with the set value. Therefore, the user running an operation can verify whether the expected value was used by verifying the outputted SHA256 hashed value.

Marking a variable sensitive in the waypoint.hcl definition looks like this:

variable "auth_email" {
  sensitive   = true
  type        = string
  default    = “myemail@mycorp.com”

Here is the resulting output value displayed:

Waypoint secret output

To retrieve the server cookie, use the waypoint server cookie command:

$ waypoint server cookie

Then verify by combining the cookie with the value you expected Waypoint to use:

$ echo -n "WPC01FZ1FB3FQ1BYABXVN67FAPXJEmyemail@mycorp.com" | sha256sum

»Targetable Runners

With Waypoint 0.8, users can target specific remote runners for an application or project, using a runner ID or labels. This allows for significantly more complex workflows involving multiple regions, environments, and clusters; as well as greater customization and control over how Waypoint launches on-demand runners. Runner and runner profile management via the command line (runner list, runner inspect, runner profile list, and runner profile inspect) will also reflect these changes with new information about runner labels and target runners.

Users can define runner profiles, which contain the configurations necessary to launch a runner. With Waypoint 0.7, we introduced the ability to give a name to a runner profile, and use that name to choose which set of runner configurations to use for an application or project; however, any remote runner could use any runner profile, which may result in namespace and service account errors in multi-cluster environments. With Waypoint 0.8, users can not only specify the runner profile to use, they can also choose which runner can use that profile, either by targeting a specific runner by ID or any available runner that matches all of a set of runner labels.

For example, Waypoint users can target runners in a specific Kubernetes cluster and just provide those runners with Kubernetes service account authentication, while other runners do not need network access or credentials to the Kubernetes cluster.

Example waypoint.hcl:

project = "example"
app "example" {
  runner {
    profile = {
      "default"  = "dev"
      "prod" = "prod"


Example runner profile setup:

runner profile set -plugin-type=kubernetes -name=dev -target-runner-label=env=dev -env-var=

Example runner inspect:

$ waypoint runner inspect test
» Runner:
  ID: test
  Adoption State: pending
  Kind: remote
  Labels: map[env:dev]
  Online: false

»Runner Adoption

Waypoint runners now must be formally adopted before they are assigned any work. Prior to Waypoint 0.8, Waypoint runners utilized a "pre-shared key" to immediately authenticate. Now, runners are able to launch without any secrets and a Waypoint administrator can see metadata about pending runners and adopt them into the cluster (or reject them).

This makes it much easier to automate runner deployments, since they don't require authentication information. As part of this work, we also expose more metadata about a runner so that administrators can be confident knowing what a specific runner is used for.

All runners can be seen using the waypoint runner list command and can be adopted or rejected using the waypoint runner adopt command. A runner can also be rejected after it is adopted in case a runner is compromised or decommissioned.

»Instance Counts in Deployment Status Reports

With Waypoint 0.8, status reports will now include information on the number of instances currently connected to the Waypoint server via Entrypoint. Each status report contains a deployment summary, which will now include the count of connected instances that are using Entrypoint for features such as logs, configuration, or waypoint exec.

»Waypoint Job Command Line Tool for Job Introspection

With this new command line tool, debugging job failures in Waypoint has never been easier. This release introduces additional introspection into the job system of Waypoint through waypoint job. Prior to the 0.8 release, it was difficult to see the status of operations in Waypoint without digging through the server or runner logs and finding the exact job details. The new job command line tool supports listing and filtering existing job data from the Waypoint server, inspecting the state and result of an existing job, or safely canceling a running job.

Whenever an operation like running waypoint up locally or remotely fails, or if you wish to gain more insight into what the job system is doing for automated GitOps deployments, waypoint job list is there to help you debug. If there’s a job in the list that you wish to know more about, running waypoint job inspect <job-id> will reveal details such as the kind of configuration that was used, the job's current status, or any error messages that resulted in the job failing.

In the list of jobs below, you can see that a few of them are in the error state. If you list again, filtering using the -state flag on error, you can see only “error” jobs. Then, if you copy that failing job ID and run waypoint job inspect <job-id>, you can see exactly why that job failed.

$ waypoint job list
» Waypoint Jobs
              ID             |  OPERATION   |  STATE  | TIME COMPLETED |       TARGET RUNNER        | WORKSPACE |      PROJECT       | APPLICATION
  01FZZSQ6BAG46301BN2J809EPR | StatusReport | Success | 27 seconds ago | 01FZZSPSVK6FKWZWJ0EKRM2RTR | default   | k8s-tetris-project | tetris
  01FZZSQ5TBS2V5SHM8CT8RNM89 | Release      | Success | 27 seconds ago | 01FZZSPSVK6FKWZWJ0EKRM2RTR | default   | k8s-tetris-project | tetris
  01FZZSQ5JYWX9G2WY1SM84EAG5 | StatusReport | Success | 27 seconds ago | 01FZZSPSVK6FKWZWJ0EKRM2RTR | default   | k8s-tetris-project | tetris
  01FZZSPTBMPJWAM7S3YWSRJ4E9 | Deploy       | Success | 28 seconds ago | 01FZZSPSVK6FKWZWJ0EKRM2RTR | default   | k8s-tetris-project | tetris
  01FZZSPPQ60HBKCAHTW8WEWRFM | Deploy       | Error   | 41 seconds ago | 01FZZSPP75D2E81G86ZE0BT8KB | default   | k8s-tetris-project | tetris
  01FZZSPGQZ2S30PJXFZDK408Q5 | Build        | Success | 46 seconds ago | 01FZZSPG7Z5JMJGE3BH14Q4Z9K | default   | k8s-tetris-project | tetris
  01FZZSPAVASRQ7RG1CQ3HR9YGV | Build        | Error   | 53 seconds ago | 01FZZSPAB9F2NH6P56P1VYJYT9 | default   | k8s-tetris-project | tetris
  01FZZSC259R3GDR63QMEJJY228 | Up           | Success | 5 minutes ago  | 01FZZSC1NAGJ7SZKSY4F679XFD | default   | k8s-tetris-project | tetris
$ waypoint job list -state=Error
» Waypoint Jobs
              ID             | OPERATION | STATE | TIME COMPLETED |       TARGET RUNNER        | WORKSPACE |      PROJECT       | APPLICATION
  01FZZSPPQ60HBKCAHTW8WEWRFM | Deploy    | Error | 52 seconds ago | 01FZZSPP75D2E81G86ZE0BT8KB | default   | k8s-tetris-project | tetris
  01FZZSPAVASRQ7RG1CQ3HR9YGV | Build     | Error | 1 minute ago   | 01FZZSPAB9F2NH6P56P1VYJYT9 | default   | k8s-tetris-project | tetris
$ waypoint job inspect 01FZZSPPQ60HBKCAHTW8WEWRFM
» Job Configuration
      Operation: Deploy
  Target Runner: 01FZZSPP75D2E81G86ZE0BT8KB
      Workspace: default
        Project: k8s-tetris-project
    Application: tetris
» Job Results
           State: Error
   Complete Time: 1 minute ago
     Cancel Time: 1 minute ago
  Error Message: context canceled

»Next Steps

The complete list of new features and improvements in Waypoint 0.8 is too long to detail here. For a complete listing of changes in Waypoint 0.8, please see the CHANGELOG. Finally, don’t miss these Waypoint resources:

We hope you enjoy Waypoint 0.8!

Sign up for the latest HashiCorp news