How to enable developer self-service at scale with Terraform and Waypoint

Most applications are long-lived and require frequent updates to stay relevant, secure and competitive. Infrastructure tooling is often not a core competency for most companies. Yet developers are expected to understand:

• Terraform
• Argo CD, Jenkins, and/or GitHub Actions
• Grafana and/or Prometheus
• MySQL, MongoDB, and/or Kafka
• and many more operations tools

While developers may understand the basics, they’re often not experts in these tools. They make mistakes when asked to do too many complex workflows with them. And it’s a waste of their time, which could be spent on development — not operations.

This is why platform engineering has been gaining a lot of traction. Gartner predicts that by 2026, 80% of large software engineering organizations will establish platform engineering teams as internal providers of reusable services, components and tools for application delivery. We’ve seen this trend grow as well — many of our customers have been early adopters of platform engineering practices.

This blog post will illustrate how HCP Waypoint can help platform teams put comprehensive self-service (golden) workflows into practice.

»Platform teams

Platform teams typically codify validated application and infrastructure patterns, then publish them as reusable modules for application teams to consume. Developers can then use these modules to get their applications up and running quickly, without ticket-heavy review processes where operational specialists become a bottleneck.

While platform teams aim to standardize on a few runtime platforms (EC2, Kubernetes, Lambda), it is impractical for an organization to achieve total standardization. They also want to retain the flexibility to evolve over time.

Many organizations already have the surrounding tooling for APM, logging, tracing, and CI/CD. The goal for platform teams is not to replace those systems, but to provide an integrated, abstracted experience across them for application teams.

»Why Waypoint?

Waypoint accommodates tooling flexibility while still enforcing organizational best practices. It integrates with these systems to provide a unified experience for application teams without replacing what’s already working.

Besides runtime platforms, there is also a wide range of application dependencies that need to be made available. Many customers use Terraform to provision and manage dependencies such as MySQL, MongoDB, Redis, and Kafka. Platform teams prefer not to train developers on Terraform or expose them to its full capabilities. Instead, they prefer curating a set of modules for the most common dependencies and exposing them to developers in an opinionated way. This approach reduces risks and speeds up provisioning.

Waypoint adds greater workflow abstraction so that platform teams can define golden patterns and workflows to enable a self-service experience for internal developers.

It orchestrates a self-service layer on top of Terraform to provide a user-friendly interface and streamlined workflows that enable developers and other non-infrastructure specialists to provision and manage cloud infrastructure without needing deep Terraform or cloud expertise. This abstraction aims to empower application developers with autonomy while maintaining organizational guardrails for security, compliance, and cost management.

»Building a self-service EKS workflow with Terraform and Waypoint

Let’s go through a real world example of an end-to-end workflow that uses everything we’ve learned from our series of posts. This will walk through a common scenario where a team has various EKS-based Kubernetes deployments on AWS and wants to build a self-service workflow for their developers.

»Step 1: Create credentials and an environment sandbox with HCP Terraform projects

Before HCP Waypoint can launch anything, it needs somewhere to launch from. In HCP Terraform, you can use a project, which is a collection of isolated workspaces. Think of it like putting your automation into a dedicated part of your AWS account. Everything Waypoint creates for this tutorial’s Kubernetes stack will happen inside this project.

The project carries its own credentials. You give it a variable set with AWS OIDC settings using HCP Terraform’s dynamic credentials for AWS. That’s your one sign-in. When Terraform runs, it assumes the IAM role you’ve set (TFC_AWS_PROVIDER_AUTH=true, TFC_AWS_RUN_ROLE_ARN=…), gets short-lived tokens, and can talk to AWS immediately. The same identity can also be recognized by your EKS cluster once you map the role with EKS access entries, so later steps can apply Kubernetes changes without setting up new secrets.

This variable set scope above makes it clear the configuration is tied to the project and automatically applies to any workspace inside it.

Now the groundwork is done. Every workspace Waypoint creates here will already have the right credentials to deploy into AWS and, after the access entry is in place, update your EKS cluster all without long-lived keys or per-workspace secrets.

Next, we’ll set up the Kubernetes runtime so those deployments have a consistent cluster to land in.

»Step 2: Bootstrap your EKS cluster and global config

Kubernetes is the stage; your apps are the actors. The stage comes first. Give the cluster and its base a home of its own: one repo wired to one HCP Terraform workspace in the same project you set up in Step 1.

Keep this workspace focused on slower-moving pieces such as EKS, networking, node groups, and any cluster-level add-ons, so application workspaces and Waypoint are not tied to Day 0 infrastructure. Use the VCS-driven workflow so changes are reviewed and applied the same way every time.

The workspace above is using the VCS-driven workflow, which communicates “one repo, one workspace, source-controlled platform” without provider-specific details.

With the runtime in its own workspace, everything else points at a consistent destination. Platform changes are versioned and reviewable through VCS (no ad hoc kubectl), and the essentials your app stacks need can be published once and read by others through Terraform’s built-in terraform_remote_state. If you are on EKS, map your project’s AWS role to cluster role-based access controls (RBAC) using EKS access entries so the same run identity can reach the Kubernetes API during later runs.

Now that the cluster exists and is managed like code, we can hand developers a clean on-ramp.

»Step 3: Create HCP Terraform no-code modules for new applications

Waypoint hands developers a template, and that template points at a no-code module that lets teams provision approved infrastructure without writing HCL (Terraform’s domain language). Publish the module to your org’s private registry and mark a version no-code ready so it is available through HCP Terraform’s guided provisioning workflow (Plus/Premium).

A no-code module is a root module. Put resources at the repository root so it can run with a plain terraform apply. Declare the required providers in the module itself. Those two requirements allow HCP Terraform to inspect inputs and create a workspace on demand. When someone provisions it, HCP Terraform creates the workspace, starts a run, and uses the credentials you configured at the project level in Step 1. For design details, see Design no-code modules.

Put the module in its own repo, tag a version, and let the registry ingest it through VCS. On the module’s page, enable no-code ready so teams can use the guided workflow instead of writing a configuration file.

Now that the module is published and flagged no-code, we will wrap it in an HCP Waypoint template so developers can create applications by filling in a few fields, without Terraform files.

»Step 4: Create HCP Waypoint templates for your no-code modules

Within HCP Waypoint, a template is the on-ramp. A template points at an HCP Terraform no-code module and presents it as a short, curated form. Behind the scenes, HCP Waypoint provisions with Terraform. See templates.

Connect HCP Waypoint to HCP Terraform so it can read your modules and create workspaces in the project from Step 1. Use the guided flow in Configure HCP Terraform integration and scope access to only what the project needs. Then create the template. Select your no-code module from the private registry, choose the project, and set a few sensible defaults and a short description so developers know exactly what they are launching.

Once the template is saved, developers stay in HCP Waypoint. They pick the template, fill in a few fields, and create an application. HCP Waypoint handles the Terraform workspace and run under the hood.

Next, we will switch to the developer view and create an application from this template so the path from “new app” to “running in Kubernetes” is concrete.

»Step 5: Create applications in HCP Waypoint

This is the developer moment. They open HCP Waypoint, pick a template, name the application, set a couple of inputs, and choose Create application. The template abstracts the infrastructure, so developers stay in HCP Waypoint and do not touch Terraform. The flow is documented in Use a Waypoint template.

Behind the scenes, HCP Waypoint uses your HCP Terraform integration to create a new workspace in the project from Step 1 and to start a run automatically. If the plan succeeds, HCP Waypoint applies and tracks status in the application view. There is no need for developers to log in to HCP Terraform.

The payoff is speed with guardrails. Developers choose from a curated path, and your platform remains consistent and policy-compliant because Waypoint provisions through HCP Terraform. If a developer changes inputs later, Waypoint starts another run and rolls the update forward in the same place.

Next, we will flip to the platform view in HCP Terraform to see the new workspace and its runs.

»Step 6: Monitor changes in HCP Terraform

Even when developers stay in Waypoint, every application they create from a template appears as a workspace and a run in your HCP Terraform project. Open the project, click the new workspace, then use the Runs tab to review current and past plans and applies, logs, and diffs. The UI details are in Manage and view runs.

Because provisioning flows through HCP Terraform, your guardrails apply automatically. Policies evaluate between the plan and apply phases with Sentinel. Drift, health, and validation checks can be triggered between runs. External scanners and cost or security tools plug in as run tasks. None of this changes the developer flow in Waypoint.

That gives platform teams a clear, auditable record of every change while developers move fast inside Waypoint.

Next, we will cover Day 2 changes from the developer side and adjust an existing application without requiring the attention of the platform team for every minor change.

»Step 7: Make changes in HCP Waypoint

Applications evolve. Teams need safe ways to update what is running without pulling a platform engineer into every change process. In HCP Waypoint, there are two paths for this: add-ons for supporting infrastructure and actions for controlled operations.

Add-ons let a developer attach packaged infrastructure to an application at any time — for example a database, a bucket, or a dashboard. Platform engineers create add-on definitions that reference Terraform no-code modules. When an add-on is installed, HCP Waypoint creates a Terraform workspace from that module, passes standard context variables (waypoint_add_on, waypoint_add_on_definition, waypoint_application), and runs it. If the add-on is uninstalled later, HCP Waypoint deletes the associated workspace and resources. You can learn more by reading about how to use an add-on.

Actions expose Day 2 operations as one-click buttons for developers. You define an action, assign it to a template, and then any application created from that template automatically inherits the action. Developers can then execute the action directly from the application’s Actions tab. There are two types of actions:

1. Custom (HTTP): Sends a request to a URL (no custom port)
2. Agent: Runs on an HCP Waypoint agent that you manage, communicating securely over gRPC with TLS for private environments. See Create and manage actions for more detail on Waypoint agents.

Together, add-ons and actions give developers self-service change capabilities while the platform teams maintain consistent patterns and permissions. Add-ons run through HCP Terraform, preserving the visibility and guardrails established in step 6, and action runs are logged alongside the application for full auditability.

»Setting the stage to unlock end-to-end self service

Terraform sets the standard for infrastructure as code and Waypoint simplifies cloud infrastructure provisioning and management. This powerful combination allows developers to provision infrastructure without deep expertise, while maintaining organizational guardrails for security, compliance, and cost management.

To learn more about how platform teams use Waypoint to create golden workflows, visit the Waypoint page. You can also request a demo.