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
    • v0.8.x (latest)
    • v0.7.x
    • v0.6.x
    • v0.5.x
    • v0.4.x
    • v0.3.x
    • v0.2.x
    • v0.1.x
    • 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

»ConfigMaps and Secrets

Waypoint provides multiple options for accessing ConfigMap and Secret resources within your deployed application. This can be used or instead of Waypoint's native application configuration functionality.

This page will focus on Waypoint-specific mechanisms for injecting configuration into your application, and it all requires the Waypoint Entrypoint to be injected and configured. Please note that if you're using the Helm or kubernetes-apply deployment plugins, you do not need to use the Waypoint entrypoint and you can access ConfigMaps and Secrets using standard Kubernetes practices. Even if you are using Helm or raw YAML, you can also mix in any of the techniques noted below as well.

»Environment Variables

You can set environment variables for your application directly in the waypoint.hcl file using the config stanza. Static environment variables like this can also be set using the web UI or CLI.

config {
  env = {
    MY_API_KEY = "abcd1234"
  }
}

app "my-app" {
  // ...
}
config {
  env = {
    MY_API_KEY = "abcd1234"
  }
}

app "my-app" {
  // ...
}

But, it's not a good idea to put something like an API key directly in your Waypoint configuration. A better idea would be to use a Kubernetes Secret and access it from there. Waypoint lets you do this with dynamic configuration:

config {
  env = {
    MY_API_KEY = dynamic("kubernetes", {
      name   = "my-secret" # Secret name
      key    = "apiKey"
      secret = true
    })
  }
}

app "my-app" {
  // ...
}
config {
  env = {
    MY_API_KEY = dynamic("kubernetes", {
      name   = "my-secret" # Secret name
      key    = "apiKey"
      secret = true
    })
  }
}

app "my-app" {
  // ...
}

»Files

You can also create files from configuration values. For example, if we wanted to create a JSON file with our API key from the environment variable example above, we can do the following:

config {
  internal = {
    MY_API_KEY = dynamic("kubernetes", {
      name   = "my-secret" # Secret name
      key    = "apiKey"
      secret = true
    })
  }

  file = {
    "config/config.json" = templatefile("${path.project}/config.json", {
      api_key = config.internal.MY_API_KEY,
    })
  }
}

app "my-app" {
  // ...
}
config {
  internal = {
    MY_API_KEY = dynamic("kubernetes", {
      name   = "my-secret" # Secret name
      key    = "apiKey"
      secret = true
    })
  }

  file = {
    "config/config.json" = templatefile("${path.project}/config.json", {
      api_key = config.internal.MY_API_KEY,
    })
  }
}

app "my-app" {
  // ...
}
{
  "api_key": "${api_key}"
}
{
  "api_key": "${api_key}"
}

This example shows two new concepts: internal variables for creating intermediary values that can be used in other configuration values and files for creating configuration files.

The file config/config.json will be written relative to your application deployment path. You could also specify an absolute path if you want the file to be written in an exact location. The files are written by a user with the same permissions as the running application when deployed, so ensure it is a path you have permission to write to.

»File Change Notification

If an input to a configuration file changes while the application is deployed, Waypoint will send a signal to the deployed application (by default SIGUSR2). The application can listen for this signal to reload configuration.

For example, if you change the my-secret secret (as used in the example above) after you had already deployed your application, Waypoint would detect the change, update the file, and then send a SIGUSR2 signal to your running application.

This is a big improvement over native Kubernetes mechanisms which update the file but depend on the running application to watch the filesystem for changes. For more information, including how to change the signal Waypoint sends, see the reference documentation.

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