June 20-22 Announcing HashiConf Europe full schedule: keynotes, sessions, labs & more Register Now
  • Infrastructure
    • terraform
    • packer
  • Networking
    • consul
  • Security
    • vault
    • boundary
  • Applications
    • nomad
    • waypoint
    • vagrant
  • HashiCorp Cloud Platform

    A fully managed platform to automate infrastructure on any cloud with HashiCorp products.

    • consul
    • terraform
    • vault
    • packerbeta
    Visit cloud.hashicorp.com
  • Overview
  • Tutorials
  • Docs
  • CLI
  • Plugins
  • Community
GitHub
Download
    • Overview
      • Overview
      • Helm
      • Heroku, Vercel, etc.
      • Kubernetes
  • Getting Started
    • Overview
    • Compatibility Promise
    • Protocol Version Table
    • Release Notifications
      • Overview
      • Upgrade to 0.2.0

    • Install
    • Externally Built Images
    • Building Container Images
    • Helm Deployment
    • YAML-Free Deployment
    • YAML Directory Deployment
    • Resource Status
    • ConfigMaps and Secrets

    • Overview
    • Git Integration
    • Remote Operations
    • Overview
    • Build
    • Deploy
    • Release
    • Hooks
    • Labels
    • Workspace and Label Scoping
    • Overview
      • Overview
      • Input Variables
      • External Data
      • artifact
      • deploy
      • entrypoint
      • labels
      • path
      • workspace
      • Overview
      • Full Reference
      • Templating
      • Overview
      • Expressions
      • JSON Syntax
    • app
    • build
    • config
    • deploy
    • hook
    • plugin
    • registry
    • release
    • runner
    • url
    • use
    • variable
  • URL Service
  • Logs
  • Exec
    • Overview
    • Dynamic Values
    • Files
    • Internal Values
    • Workspace and Label Scoping
    • Overview
      • Overview
      • OIDC
      • Overview
      • Maintenance
      • Production
      • Security
    • Express Server Install
    • Overview
    • Configuration
    • Profiles
    • On-Demand Runner
    • Additional Runners
  • Workspaces
  • Plugins
  • Triggers

    • Overview
      • Overview
      • Registering Plugin Components
      • Handling Configuration
      • Implementing the Builder Interface
      • Compiling the Plugin
      • Creating an Example Application
      • Testing the Plugin
    • Initializing the SDK
    • Passing Values Between Components
      • Overview
      • Authenticator
      • Configurable
      • ConfigurableNotify
      • Builder
      • Registry
      • Platform
      • ReleaseManager
      • Destroy
      • Status
      • Default Parameters
      • Overview
    • Overview
    • Disable
    • Overview
    • GitHub Actions
    • GitLab CI/CD
    • CircleCI
    • Jenkins
  • Troubleshooting
  • Glossary

    • Overview
    • Architecture
    • Operation Execution
  • Roadmap
Type '/' to Search

»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:

  • At least one runner is installed and running. Waypoint automatically installs a runner with waypoint install.
  • 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.

»Usage

»CLI

# 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
...
# 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 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 two users attempt run waypoint up at the same time, even if they add the -local flag, 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.

github logoEdit this page

Using Waypoint

The best way to understand what Waypoint can enable for your projects is to give it a try.

Waypoint tutorials
Waypoint documentation
Tutorial

Get Started - Kubernetes

Build, deploy, and release applications to a Kubernetes cluster.

View
Tutorial

Introduction to Waypoint

Waypoint enables you to publish any application to any platform with a single file and a single command.

View

Waypoint is maintained by HashiCorp, Inc.

View Code of Conduct
DocumentationCLI ReferenceTutorialsIntegrations
All systems normal