Waypoint operations such as
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.
Remote operations require:
At least one runner is installed and running. Waypoint automatically installs a runner with
Your project is configured with a data source so that the runners can clone the project source code.
Your project has remote operations enabled.
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
$ waypoint up -remote
You can substitute any operation for
up such as
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.
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.