Type '/' to Search

»Application Lifecycle

Waypoint has an opinionated view on the minimum application lifecycle: build, deploy, and release. These are the core elements that Waypoint orchestrates during a waypoint up.

These stages can also be broken down to the individual commands waypoint build, waypoint deploy, and waypoint release. This allows customization of the application lifecycle by inserting your own phases into the Waypoint workflow.

»Overview

  • A build takes application source and converts it to an artifact. The build process may also include an optional push operation to push the built artifact to a registry so that it is available for the deployment platform.

  • A deploy takes a previously built artifact and stages it onto the target deployment platform and is available via deployment URLs or other internal means.

  • A release activates a previously staged deployment and opens it to general traffic.

»History

Waypoint maintains a history of all operations. You can view this history in the UI as well as the CLI. The operation history shows when it was requested, whether it succeeded or failed, the output of its run, and more.

History in the CLI is done via the various subcommands beneath waypoint artifact and waypoint deployment. The CLI has less listing capabilities than the UI. All of this information is also available via the API.

»Build

A build takes application source and converts it to an artifact. An artifact is the packaged form of an application required for deployment on your target platform: a container image, VM image, or maybe a simple zip file. The build process may also include an optional push operation to push the built artifact to a registry so that it is available for the deployment platform.

The Build page explains more including using Docker and Buildpacks.

»Deploy

A deploy takes a previously built artifact and stages it onto the target deployment platform and is available via deployment URLs or other internal means.

"Stage" in this context means that the application should be ready to receive traffic, but is not yet open to public traffic. For example, the application should not be added to the load balancer, DNS should not be updated, etc.

Not all platforms support the concept of "staging" a deployment or this behavior may not be desirable. Waypoint does not enforce this requirement and some deployment plugins may not support it.

The Deploy page explains more including using Docker, Kubernetes and Nomad.

»Release

A release activates a previously staged deployment and opens it to general traffic.

This step may involve adding a deployment to a load balancer, updating DNS, configuring a service mesh, etc.

The Release page explains more.

»Hooks

A hook is a customizable command that executes before or after the build, registry, deploy, or release operations. Hooks execute on the Waypoint Runner, which is typically the Waypoint CLI. Hooks can be useful to do things such as perform a security scan on an image, run database migrations on a deploy, etc.

The Hooks page explains more.