Blog
Business
6
minutes

Hashicorp Waypoint vs Heroku: What is the best PaaS for your team?

This week, Hashicorp announced the launch of their new product - Waypoint - aiming to simplify the way developers build and run apps in the Cloud and on any platform (like Kubernetes). The project is open source and is well adapted by the dev community. As CEO and co-founder of Qovery, I am enthusiastic to see this product live. At Qovery, we believe in making the developer’s life more accessible, and seeing big Open Source companies moving in this direction is a good thing for all of us. In this article, I will compare and contrast Hashicorp Waypoint to Heroku. Why? Because Hashicorp created Waypoint to provide an alternative to PaaS (Platform as a Service) like Heroku. Which is, in my opinion targeting two different types of developers. Let’s go TLDR; For devs, Waypoint is a higher-level of abstraction than Terraform, but it's not as simple as Heroku.
September 26, 2025
Romaric Philogène
CEO & Co-founder
Summary
Twitter icon
linkedin icon

Getting Started

Waypoint

To get started with Waypoint, you need to install the Waypoint CLI. Then, you need to start the waypoint server locally (you need Docker) and type "waypoint init" at the root of your project to create a waypoint.hcl file indicating how to build and where to deploy your app.

The structure of the file looks like this.

# The name of your project. A project typically maps 1:1 to a VCS repository.
# This name must be unique for your Waypoint server. If you're running in
# local mode, this must be unique to your machine.
project = "my-project"

# Labels can be specified for organizational purposes.
# labels = { "foo" = "bar" }

# An application to deploy.
app "web" {
# Build specifies how an application should be deployed. In this case,
# we'll build using a Dockerfile and keeping it in a local registry.
build {
use "docker" {}

# Uncomment below to use a remote docker registry to push your built images.
#
# registry {
# use "docker" {
# image = "registry.example.com/image"
# tag = "latest"
# }
# }

}

# Deploy to Docker
deploy {
use "docker" {}
}
}

Then we start the waypoint server to deploy our app locally.

~/I/my-nodejs-app (main|…) $ waypoint init
+ Configuration file appears valid
+ Connection to Waypoint server was successful
+ Project "my-project" and all apps are registered with the server.
+ Plugins loaded and configured successfully
+ Authentication requirements appear satisfied.

Project initialized!

You may now call 'waypoint up' to deploy your project or
commands such as 'waypoint build' to perform steps individually.
~/I/my-nodejs-app (main|…) $ waypoint up

» Building...
+ Initializing Docker client...
+ Building image...
│ run npm audit fix to fix them, or npm audit for details
│ ---> 00f8bf931db5
│ Step 6/7 : EXPOSE 3000
│ ---> Running in 4b97b6969c0a
│ ---> ba8df281ebd0
│ Step 7/7 : CMD node ./bin/www
│ ---> Running in 244d76788fd1
│ ---> 4f4703ddfb7c
│ Successfully built 4f4703ddfb7c
│ Successfully tagged waypoint.local/web:latest
+ Injecting Waypoint Entrypoint...

My first impression

  1. I have 10 years of experience in DevOps and back-end development; I understand how Waypoint will work.hcl file looks similar to what you need to provide in the most popular CI (pipelines). Still, I am not sure that an average developer will understand why Waypoint requires all of that to deploy their app.
  2. Starting locally, the waypoint server to test and deploy your app is an extra step, but checking that my app will work as expected is convenient.
  3. Cool to see that the local deployment provides a public URL with Waypoint.run. This is publicly accessible and easy to share. However, I didn't figure out to make it work.

Compared to Heroku

To get started with Heroku, you only need to push your code on Git, and that's it. This is straightforward, whatever the experience of the developer. The downside is that Heroku force you to use their Git repository to deploy your app. This is counterintuitive if you are using Github, for instance.

And I think this is the main difference between Waypoint and Heroku; Waypoint doesn't care how you version your code. You can use Git, SVN, Mercurial, or whatever. It will work, but you will need to make the glue between your VCS and Waypoint yourself. On the other side, Heroku wants to be as close as possible in the developer's environment, meaning being integrated into Git.

The Waypoint philosophy

Heroku is a Platform as a Service existing for 13 years. The main goal was to help any developers easily deploy and host their apps. It is still popular for devs and companies that want to focus on what they build. Heroku makes companies production-ready in hours. Waypoint doesn’t host any app for you. You need to integrate it into your existing infrastructure or provide at least an AWS, GCP, or Azure account. Waypoint doesn’t remove the need to understand what’s going on behind the scenes. It simplifies the “Go To Deployment”. This is a huge difference in philosophy between Heroku and Waypoint.

It’s not only deploying a single app

This is where Heroku and Waypoint miss the point. Making app deployment seamless is not only simplifying the deployment of a single app. When I interviewed 200 CTOs, I noticed that 100% of them manage from dozens to thousands of apps, from development to production. It’s an assumed choice of Mitchell Hashimoto (Co-founder at Hashicorp) that didn’t want to create an opinionated product.

Mitchell Hashimoto announced the launch of Waypoint on Twitter and explain the difference with Heroku (click on image to go to the tweet)

Opinionated products help developers and companies to gain productivity. That's why Heroku is so popular and well adopted - still 13 years later.

Low level of abstraction

Hashicorp did great work in the DevTools and infrastructure ecosystem. They have launched dozens of popular Open Source products, and no doubt they know to make them. Waypoint is at a higher level of abstraction than Terraform (Infrastructure as Code) to manage infrastructure; however, it is still at a lower level of abstraction than Heroku. The goal of a PaaS (Heroku) is to abstract all the build, deployment, and underlying infrastructure. With Waypoint, you still need to understand (at a higher level, I admit) how all those parts are working together.

Total cost ownership (TCO)

Heroku, you pay (a lot) compared to what you get, but you remove the need to manage your infrastructure, and you maximize your impact on the product you’re building. Putting your hands on Waypoint required spending time understanding how it can fit into your infrastructure and organization. Open source projects are free to install, not to maintain. Choosing between Open Source or Proprietary is the Build vs. Buy trade-off.

Conclusion

Waypoint and Heroku respond to the need for different personas. Heroku answers the need of individual developers and companies that want to focus on their product, where Waypoint gives the ability to DevOps to gain in productivity to build a deployment system.

Waypoint is an excellent move into the simplification of app deployments for companies. Still, it does not solve all the problems that organizations face - how do they manage multiple dozens to thousands of apps in development, staging, and production environments? Plus, today, the entry barrier seems too high for the new generation of developers coming from boot camps like IronHack, AppAcademy, and Le Wagon.

I don’t think Heroku will disappear due to the apparition of Waypoint. They serve two different purposes.

Feel free to reach out to find what would be the best option for your team.

Thanks for reading

Share on :
Twitter icon
linkedin icon
Tired of fighting your Kubernetes platform?
Qovery provides a unified Kubernetes control plane for cluster provisioning, security, and deployments - giving you an enterprise-grade platform without the DIY overhead.
See it in action

Suggested articles

AI
Compliance
 minutes
Agentic AI infrastructure: moving beyond Copilots to autonomous operations

The shift from AI copilots to autonomous agents is redefining infrastructure requirements. Discover how to build secure, stateful, and compliant Agentic AI systems using Kubernetes, sandboxing, and observability while meeting EU AI Act standards

Mélanie Dallé
Senior Marketing Manager
Kubernetes
8
 minutes
The 2026 guide to Kubernetes management: master day-2 ops with agentic control

Effective Kubernetes management in 2026 demands a shift from manual cluster building to intent-based fleet orchestration. By implementing agentic automation on standard EKS, GKE, or AKS clusters, enterprises eliminate operational weight, prevent configuration drift, and proactively control cloud spend without vendor lock-in, enabling effective scaling across massive fleets.

Mélanie Dallé
Senior Marketing Manager
Kubernetes
 minutes
Building a single pane of glass for enterprise Kubernetes fleets

A Kubernetes single pane of glass is a centralized management layer that unifies visibility, access control, cost allocation, and policy enforcement across § cluster in an enterprise fleet for all cloud providers. It replaces the fragmented practice of switching between AWS, GCP, and Azure consoles to govern infrastructure, giving platform teams a single source of truth for multi-cloud Kubernetes operations.

Mélanie Dallé
Senior Marketing Manager
Kubernetes
 minutes
How to deploy a Docker container on Kubernetes (and why manual YAML fails at scale)

Deploying a Docker container on Kubernetes requires building an image, authenticating with a registry, writing YAML deployment manifests, configuring services, and executing kubectl commands. While necessary to understand, executing this manual workflow across thousands of clusters causes severe configuration drift. Enterprise platform teams use agentic platforms to automate the entire deployment lifecycle.

Mélanie Dallé
Senior Marketing Manager
Kubernetes
Terraform
 minutes
Managing Kubernetes deployment YAML across multi-cloud enterprise fleets

At enterprise scale, managing provider-specific Kubernetes YAML across multiple clouds creates crippling configuration drift and operational toil. By adopting an agentic Kubernetes management platform, infrastructure teams abstract cloud-specific configurations (like ingress controllers and storage classes) into a single, declarative intent that automatically reconciles across 1,000+ clusters.

Mélanie Dallé
Senior Marketing Manager
Kubernetes
Cloud
AI
FinOps
 minutes
GPU orchestration guide: How to auto-scale Kubernetes clusters and slash AI infrastructure costs

To stop GPU costs from destroying SaaS margins, teams must transition from static to consumption-based infrastructure by utilizing Karpenter for dynamic provisioning, maximizing hardware density with NVIDIA MIG, and leveraging Qovery to tie scaling directly to business metrics.

Mélanie Dallé
Senior Marketing Manager
Product
AI
Deployment
 minutes
Stop Guessing, Start Shipping. AI-Powered Deployment Troubleshooting

AI is helping developers write more code, faster than ever. But writing code is only half the story. What happens after? Building, deploying, debugging, scaling. That's where teams still lose hours.We're building Qovery for this era. Not just to deploy your code, but to make everything that comes after writing it just as fast.

Alessandro Carrano
Head of Product
AI
Developer Experience
Kubernetes
 minutes
MCP Server is the future of your team's incident’s response

Learn how to use the Model Context Protocol (MCP) to transform static runbooks into intelligent, real-time investigation tools for Kubernetes and cert-manager.

Romain Gérard
Staff Software Engineer

It’s time to change
the way you manage K8s

Turn Kubernetes into your strategic advantage with Qovery, automating the heavy lifting while you stay in control.