»Remote Operations

Waypoint operations such as waypoint up, build, deploy, etc. can be executed remotely using runners. This enables a variety of useful functionality and patterns:

  • GitOps where builds, deploys, etc. are triggered by Git.
  • Users don't need to have credentials for build or deployment targets, only the runners do. For example, if you're deploying an application AWS, only the runners need AWS credentials. Users only need a token for the Waypoint server to queue the deployment job.
  • Private resource access. Every client only needs access to the Waypoint server. The runners can run on a private network to access internal resources.

»Requirements

Remote operations require:

»Usage

»CLI

To execute a remote operation via the CLI, specify the project and application:

$ waypoint up my-project/web

If you have the local source checked out and your terminal working directory is in your project source code, you can omit the project name and use the -remote flag:

$ waypoint up -remote

You can substitute any operation for up such as build, deploy, release, etc.

Both of these approaches will queue a job with the server and remotely execute that job on the runner. Execution output will stream to the client, but all logic is executing remotely.

»Concurrency

Waypoint only allows a single operation per distinct (workspace, project, app) combination. This applies to both local and remote operations. Therefore, if one user runs waypoint up locally and another runs waypoint up -remote, one of the operations will wait for the other to complete before continuing.

However, if a second user runs waypoint up in a different project or different application in the same project or different workspace, that operation will run concurrently so long as there is available runner capacity.