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.

Romaric Philogène

Romaric Philogène

October 18, 2020 · 5 min read
Hashicorp Waypoint vs Heroku: What is the best PaaS for your team? - Qovery
Written byRomaric Philogène

Romaric Philogène

CEO and co-founder of Qovery. Romaric has 10+ years of experience in R&D. From the Ad-Tech to the financial industry, he has deep expertise in highly-reliable and performant systems.

See all articles

Getting Started


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)
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.


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