---
layout: docs
page_title: Operation Execution
description: |-
  This page documents how operations such as build, deploy, and release execute within Waypoint. This helps explain what components need access to what systems and how information flows within Waypoint.
---

# Operation Execution

This page documents how operations such as build, deploy, and release
execute within Waypoint. This helps explain what components need access to
what systems and how information flows within Waypoint.

Operation execution in Waypoint always flows through three components: the
**client** enqueues a job request with the **server**, the **server** assigns
the job to a **runner**, and the **runner** executes the job and streams
logs and output back to the **server** and the **client** through the server.
We will show a diagram of this happening.

To improve the user experience, Waypoint simplifies what is required and
automatically runs certain components as needed. We will cover all of these
cases on this page.

## Most Common: CLI and a Remote Server

In most cases, you use a CLI directly with a Waypoint server. In this
model, there are no standalone "runner" processes running. This is the
usage style in the getting started guide that we introduce to new users of
Waypoint.

For this execution, the CLI transparently spins up a runner in-process.
This runner registers with the server like any other runner process but
advertises that it can only accept jobs that are directly assigned to it.
The CLI queues a job with the server for the operation and directly assigns
this to the runner it is running in-process. See the diagram below.
The dotted
boxes represent process boundaries (perhaps on different computers) and
the white boxes are logical components within a single process.

![CLI and a Remote Server](/img/execution-cli-server.png)

## Most Advanced: CLI, Remote Server, Remote Runner

The most advanced case is using a CLI to execute an operation that
is executed on a remote runner. This scenario is most common to try to
hide credentials, access internal systems the CLI may not be able to, etc.

For this style of execution, the CLI queues the job with the server, the server
assigns the job to a runner, and the job executes it.
The dotted
boxes represent process boundaries (perhaps on different computers) and
the white boxes are logical components within a single process.

![CLI and a Remote Server](/img/execution-remote.png)

In this mode, the CLI does not need to remain attached to the server
after queueing the job. The CLI may exit and the job will continue
executing in the background.

## Most Limited: CLI, No Server

The most limited scenario is using a CLI with no remote server. This
is also known as "local mode" execution.

For this execution, the CLI transparently spins up both a runner and
server in-process. The CLI then follows the standard pattern of queueing
and executing a job, but this all happens within a single process boundary.
The dotted
boxes represent process boundaries (perhaps on different computers) and
the white boxes are logical components within a single process.

![Local Mode Execution](/img/execution-local.png)
