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.
Waypoint will automatically run your operations remotely if all these conditions are met, and that you have a runner profile configured.
# let waypoint choose to run your operation remotely if possible (recommended): $ waypoint up ... # or, force it to run locally on your development machine: $ waypoint up -local ...
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 two
users attempt run
waypoint up at the same time, even if they add the
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.