Waypoint 0.7 Reimagines UI and Extends Deployment Workflows

We are pleased to announce the general availability of HashiCorp Waypoint 0.7. Waypoint is an application deployment tool that aims to deliver a PaaS-like experience for Kubernetes, Amazon ECS, and other platforms. This release of Waypoint is a significant step forward in enhancing the user experience around securing, configuring, and extending Waypoint for your organization.

Here are some of the significant features in this release:

• UI redesign: Many new user experience workflows have been added by refactoring the Waypoint UI. New UX items include a dropdown for environment selection, icon updates, and a timeline associated with building, deployment, and release information.
• Triggers: The Waypoint CLI now supports scripting and continuous integration (CI) lifecycle operations using triggers. When a trigger is loaded, it executes a specific Waypoint operation for a specific project. This release supports running triggers through the gRPC library, and a future Waypoint release will support running triggers through HTTP.
• External data fetching: The waypoint.hcl file can now fetch data from external systems such as HashiCorp Vault, HashiCorp Terraform Cloud, Kubernetes ConfigMaps, and more. For example, it is now possible to source certificate ARNs directly from Terraform Cloud rather than hardcoding them into the waypoint.hcl file.
• Workspace-scoped configuration: Teams can scope plugin configuration to target a specific workspace. For example, you can now change the Kubernetes namespace, Docker image name, etc., depending on the current workspace. You can even change complete plugin types: Docker for development, Kubernetes for production, etc.

This release includes many new features, workflow enhancements, general improvements, and bug fixes. The Waypoint 0.7 changelog contains a detailed list of all changes in this release.

»UI Redesign

Waypoint focuses on allowing teams to deploy, manage, and observe their applications through the command-line interface (CLI) and user interface (UI) within a web browser.

Notable changes for the Waypoint UI include displaying individual artifacts in a panel beside a sidebar list that contains the same artifact types, like in a list of deployments, which persists instead of redirecting to a different page for each artifact.

The new UI for Waypoint’s deployments list

Timelines show on an artifact’s details page and help teams see which artifacts relate to build, deployment, and release steps.

Waypoint’s updated timeline view

Teams can now use waypoint exec within the Waypoint browser UI. exec in the UI allows for commands to be run within a deployment to help with operations like troubleshooting, running database migrations, or checking application configuration.

waypoint exec in the Waypoint UI

The Waypoint UI now supports OpenID Connect (OIDC) login flows. The server-side components existed in Waypoint 0.6, but the 0.7 release adds functionality to the UI by allowing teams to sign in with OIDC via their browser.

The OpenID connect sign in

»Triggers

Waypoint 0.7 introduces a new core piece of functionality called triggers. Triggers are pre-configured Waypoint lifecycle operations used for execution inside continuous integration environments. Users can configure operations like deploying the latest build, running a status report on all applications in a project, running a waypoint up operation on all applications in a project, and more.

Triggers can be invoked directly inside an environment with a gRPC request that tells Waypoint to execute the pre-configured action. Trigger configurations are project-scoped, where their actions can operate on every application defined in a project or target a single application inside a project.

With this first iteration in Waypoint 0.7, the Waypoint server will support only executing triggers through gRPC. However, in upcoming versions of Waypoint, HTTP requests will initiate running Triggers, making Waypoint use in CI even more accessible than it is today.

Triggers can be created via the Waypoint CLI as shown here:

Once created, the CLI command will print out the generated trigger id, which is usable in any environment to trigger that operation. For example, you can run a trigger with grpcurl:

When you execute a trigger, it will return a list of job IDs queued to run with the Waypoint server as soon as possible.

You can also use the Waypoint CLI to list current trigger configurations:

Or you can inspect a specific trigger configuration, like the “deploy-statusreport” trigger that will regenerate a status report on the latest deployment for an application:

Learn more about triggers in the documentation.

»External Data Fetching

Waypoint 0.7 introduces the ability to fetch and use external data in your waypoint.hcl configuration using the dynamic function. This data can be sourced from Vault, Terraform Cloud, AWS Secrets Manager, and more.

Below is an example of using an AWS ACM certificate ARN from a Terraform Cloud output value:

Waypoint is extendable using plugins to support additional data sources, and we plan to continue to expand the list of officially supported data sources.

Learn more about fetching external data in the Waypoint documentation.

»Workspace-Scoped Configuration

Waypoint 0.7 enables users to alter their plugin configuration based on the active workspace. Workspaces have been a mechanism to simulate environments and other organizational constructs since Waypoint 0.1, and we've been expanding the functionality of workspaces over time.

An example use case is to change the Kubernetes namespace of a deployment depending on the workspace and to be able to try a different plugin type in a separate workspace:

In this example, "my-app" will deploy into the "default" Kubernetes namespace by default and into the "production" namespace if the currently active Waypoint workspace is "production". Workspace-scoped configuration helps to change configuration based on environments.

The configuration also introduces unique behavior when the "new-platform" workspace uses HashiCorp Nomad and shows how workspace-scoped configuration potentially enables migration or experimentation with new systems. Consult Waypoint’s documentation for more information about workspace and label scoping.

»What’s Next for Waypoint?

The complete list of new features and improvements in Waypoint 0.7 is too long to detail in this post. For a complete listing of changes in Waypoint 0.7, please see the CHANGELOG.

One of our primary focuses is improving workflows around multiple environments (staging, production, etc.) in future Waypoint releases. Working with various environments using Kubernetes is a manual and error-prone process. We hope to bring significant automation and opinionated workflows to streamline this process better.

We hope you enjoy Waypoint 0.7!

»Next Steps

• Download Waypoint 0.7 from the project website.
• Learn more about Waypoint with tutorials on the HashiCorp Learn site.
• Contribute to the Waypoint project and participate in its community.
• Extend Waypoint by creating a plugin.