Hi HN! We are Alexander, Justin, and Trevor from Porter. We're building a Kubernetes-based Platform as a Service (PaaS) that deploys applications on your own cloud provider. Specifically, Porter provisions a Kubernetes cluster in your own cloud account and lets you deploy and manage applications on it through a Heroku-like PaaS layer. And although applications deployed via Porter run on Kubernetes, no knowledge of Kubernetes is necessary to use Porter. Here is our repository (https://github.com/porter-dev/porter) and website (https://getporter.dev). There was also an HN thread about us a few weeks ago, posted by someone who discovered us (https://news.ycombinator.com/item?id=26587637 - thank you OP!).
We have known each other since high school/college and have been working on projects together full-time since 2020. When YC funded us in S20, we were building a remote development platform for teams on Kubernetes (kinda like repl.it but for microservices in particular). This was a more enterprisey product and we got burnt out by the slow sales/iteration cycle (we had zero experience with sales, let alone enterprises). So we decided to pivot a few months after demo day.
When we were struggling to get traction with the original direction, we learned a ton by talking to engineering teams that are using Kubernetes (k8s). One thing we noticed is that there's an increasing number of startups who start on a PaaS like Heroku and end up migrating to k8s later as their applications “grow out” of Heroku, due to constraints in networking, performance, security, etc.
While Kubernetes is great, it incurs a ton of engineering overhead. For teams who don’t know k8s at all, learning everything from scratch is daunting and time-consuming. Even if there are devops engineers on the team who are familiar with kubernetes, adopting k8s slows down developer velocity because other developers always need the devops engineers’ help to troubleshoot the slightest application issues. While we were working on our previous product, we discovered that some companies even built internal development platforms (IdP) that are much like Porter, in order to help developers deploy and troubleshoot their applications without help from the devops engineers. Our goal with Porter is to create a platform that is truly as easy to use as Heroku, without compromising the flexibility of k8s.
There are many self-hosted PaaS's that came before Porter, such as Flynn, Tsuru, Dokku, and CapRover, which were all created before Kubernetes changed the DevOps landscape. While these are great lightweight options for smaller projects, a PaaS built on top of the k8s ecosystem comes with many benefits such as scalability, stability, configurability and interoperability across cloud providers. We believe that k8s is the best system to deliver a PaaS on, and we’re not alone - many of the new hosted PaaS’s are also built on top of k8s, although that’s an implementation detail that is usually not advertised to the user. We want to not only deliver the PaaS experience on top of Kubernetes, but also give users full ownership/control of the underlying k8s cluster by running it in their own cloud.
How it works: we spin up a k8s cluster in your own AWS/GCP/DO account and let you deploy and manage applications on it through a Heroku-like abstraction layer. For teams using a PaaS like Heroku, Porter can be a drop-in replacement that you don’t “grow out” of. And although our abstraction layer covers most use cases, we let those who want to customize go freely under the hood to interact with the underlying cluster. In each cloud provider, we provision the standard managed k8s offering (e.g. EKS/GKE/DigitalOcean Kubernetes), so the clusters we provision are perfectly compatible with kubectl and any other k8s tooling out there. It’s even possible to connect Porter to an existing k8s cluster—this isn’t the primary use case we’re building for at the moment, but we’d love to discuss it in the comments if anyone is interested.
In terms of implementation, we’ve built Porter around the Helm ecosystem, and every application you deploy is packaged as a Helm chart. For those who want more visibility, we’ve built features like “devops mode” that lets you visualize and manage the Helm charts and its underlying k8s objects.
We’ve published Porter to be fully open source under the MIT license. We provide a hosted version that is currently in open beta, but it's also possible to run Porter locally. It’s worth clarifying that on the hosted version, the applications you deploy through Porter still run in your own cloud. What is hosted by us is only the PaaS layer, not your applications. We plan to release a self-hostable version of the PaaS layer itself in the near future, packaged as a Helm chart. We do not support this yet because self-hosting the PaaS layer inevitably incurs devops overhead and requires some knowledge of k8s, and we are currently focused on those who just want the Heroku experience without having to deal with k8s in any way.
In terms of pricing, we are still figuring out the specifics. Our goal is to not charge individual developers/small startups but instead draw revenue from larger teams based on usage, and with premium features that are geared towards collaboration. Existing PaaS’s like Heroku/Netlify have solid examples of such premium features - review apps, pipelines, and Role Based Access Control are a few examples that we also consider to be potential premium features on Porter. That said, we are currently focused on laying out the stable foundation of the platform, so these premium features are further down on our roadmap.
Thank you so much for reading and we'd love it if you could give it a try: https://github.com/porter-dev/porter. We'll be hanging out in the comments to hear any ideas and feedback you may have. If you have any experiences related to what we’ve built, we would love it if you could share them below. Very much looking forward to learning from you!
We have known each other since high school/college and have been working on projects together full-time since 2020. When YC funded us in S20, we were building a remote development platform for teams on Kubernetes (kinda like repl.it but for microservices in particular). This was a more enterprisey product and we got burnt out by the slow sales/iteration cycle (we had zero experience with sales, let alone enterprises). So we decided to pivot a few months after demo day.
When we were struggling to get traction with the original direction, we learned a ton by talking to engineering teams that are using Kubernetes (k8s). One thing we noticed is that there's an increasing number of startups who start on a PaaS like Heroku and end up migrating to k8s later as their applications “grow out” of Heroku, due to constraints in networking, performance, security, etc.
While Kubernetes is great, it incurs a ton of engineering overhead. For teams who don’t know k8s at all, learning everything from scratch is daunting and time-consuming. Even if there are devops engineers on the team who are familiar with kubernetes, adopting k8s slows down developer velocity because other developers always need the devops engineers’ help to troubleshoot the slightest application issues. While we were working on our previous product, we discovered that some companies even built internal development platforms (IdP) that are much like Porter, in order to help developers deploy and troubleshoot their applications without help from the devops engineers. Our goal with Porter is to create a platform that is truly as easy to use as Heroku, without compromising the flexibility of k8s.
There are many self-hosted PaaS's that came before Porter, such as Flynn, Tsuru, Dokku, and CapRover, which were all created before Kubernetes changed the DevOps landscape. While these are great lightweight options for smaller projects, a PaaS built on top of the k8s ecosystem comes with many benefits such as scalability, stability, configurability and interoperability across cloud providers. We believe that k8s is the best system to deliver a PaaS on, and we’re not alone - many of the new hosted PaaS’s are also built on top of k8s, although that’s an implementation detail that is usually not advertised to the user. We want to not only deliver the PaaS experience on top of Kubernetes, but also give users full ownership/control of the underlying k8s cluster by running it in their own cloud.
How it works: we spin up a k8s cluster in your own AWS/GCP/DO account and let you deploy and manage applications on it through a Heroku-like abstraction layer. For teams using a PaaS like Heroku, Porter can be a drop-in replacement that you don’t “grow out” of. And although our abstraction layer covers most use cases, we let those who want to customize go freely under the hood to interact with the underlying cluster. In each cloud provider, we provision the standard managed k8s offering (e.g. EKS/GKE/DigitalOcean Kubernetes), so the clusters we provision are perfectly compatible with kubectl and any other k8s tooling out there. It’s even possible to connect Porter to an existing k8s cluster—this isn’t the primary use case we’re building for at the moment, but we’d love to discuss it in the comments if anyone is interested.
In terms of implementation, we’ve built Porter around the Helm ecosystem, and every application you deploy is packaged as a Helm chart. For those who want more visibility, we’ve built features like “devops mode” that lets you visualize and manage the Helm charts and its underlying k8s objects.
We’ve published Porter to be fully open source under the MIT license. We provide a hosted version that is currently in open beta, but it's also possible to run Porter locally. It’s worth clarifying that on the hosted version, the applications you deploy through Porter still run in your own cloud. What is hosted by us is only the PaaS layer, not your applications. We plan to release a self-hostable version of the PaaS layer itself in the near future, packaged as a Helm chart. We do not support this yet because self-hosting the PaaS layer inevitably incurs devops overhead and requires some knowledge of k8s, and we are currently focused on those who just want the Heroku experience without having to deal with k8s in any way.
In terms of pricing, we are still figuring out the specifics. Our goal is to not charge individual developers/small startups but instead draw revenue from larger teams based on usage, and with premium features that are geared towards collaboration. Existing PaaS’s like Heroku/Netlify have solid examples of such premium features - review apps, pipelines, and Role Based Access Control are a few examples that we also consider to be potential premium features on Porter. That said, we are currently focused on laying out the stable foundation of the platform, so these premium features are further down on our roadmap.
Thank you so much for reading and we'd love it if you could give it a try: https://github.com/porter-dev/porter. We'll be hanging out in the comments to hear any ideas and feedback you may have. If you have any experiences related to what we’ve built, we would love it if you could share them below. Very much looking forward to learning from you!