New Interested in participating in the HCP Waypoint Private Beta Program? Apply here
  • 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
      • Upgrade to 0.3.0
      • Upgrade to 0.4.0
      • Upgrade to 0.5.0
      • Upgrade to 0.6.0
      • Upgrade to 0.7.0
      • Upgrade to 0.8.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
      • Tokens
      • 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
      • ConfigSourcer
      • 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

»path Variables

Path variables are used to construct an absolute path to reference files or directories that may be used within your Waypoint configuration. For example, path variables may be used with the Docker builder to specify the path to the Dockerfile to build.

»path.app

Placementapp

The directory of the application being built or deployed with Waypoint.

If path is not set for the app, this will always equal path.project. If you are referencing app-relative data, you should always use path.app in case you move the application in the future.

Example:

dockerfile = "${path.app}/Dockerfile"
dockerfile = "${path.app}/Dockerfile"

»path.project

Placement* (global)

The directory that contains the waypoint.hcl. This is the recommended variable to use when referencing files relative to the waypoint.hcl file.

Unlike path.pwd, this will always point to the directory where the waypoint.hcl is. If you execute Waypoint from a subdirectory and it loads a waypoint.hcl file in some parent directory, that directory will be the value of path.project. When executing the waypoint CLI in the same directory as the waypoint.hcl file, path.pwd and path.project are equivalent.

Example:

dockerfile = "${path.project}/Dockerfile"
dockerfile = "${path.project}/Dockerfile"

»path.pwd

Placement* (global)

The working directory for the CLI. This is equivalent to the result of pwd in the shell.

When executed from a subdirectory, Waypoint will search parent directories for a waypoint.hcl. In this case, the path.pwd variable will point to the subdirectory where you executed Waypoint, not the directory where the waypoint.hcl is.

Example:

dockerfile = "${path.pwd}/Dockerfile"
dockerfile = "${path.pwd}/Dockerfile"

path.pwd is not recommended. You almost always want path.project or path.app instead. Using path.pwd makes Waypoint execution dependent on the current working directory when executing waypoint, which can be surprising to users.

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