---
layout: docs
page_title: Application Lifecycle
description: |-
  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`.
---

# 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`.

**Each stage in Waypoint is optional.** Waypoint doesn't need to own or run
each stage. For example, your builds may happen in CI using other tools.
Waypoint can use the result of that build to perform only the "deploy"
and "release" steps. Any combination can be mixed.

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](/docs/url#per-deployment-urls)
  or other internal means.

- A **release** activates a previously staged _deployment_ and opens it
  to general traffic.

## Operation 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](/docs/lifecycle/build) 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](/docs/url#per-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](/docs/lifecycle/deploy) 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](/docs/lifecycle/release) 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](/docs/internals/execution#most-common-cli-and-a-remote-server),
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](/docs/lifecycle/hooks) explains more.
