Launch HN: Porter (YC S20) – Open-source Heroku in your own cloud
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...
75 comments
[ 0.37 ms ] story [ 127 ms ] thread> 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.
They seem to be particularly targetting users who are migrating off of Heroku (and are migrating to 'their own' Kubernetes) due to cost, at which point $72/m is likely a tiny drop in the bucket.
Second, I agree with you that the EKS pricing is extremely restrictive for small projects, and especially for projects that require multiple clusters. But that is kind of a gripe at AWS and their Kubernetes offering, rather than Porter. They appear to support other Kubernetes cloud offerings, so just use DigitalOcean's (DOKS) if you don't want to pay for your control plane.
However, the underlying EC2 machines added to the $72/mo management fee on EKS is relatively cheap, and we've found that if you are using more than 4GB RAM/4 CPU on Heroku, the cost on EKS starts getting cheaper than Heroku (at scale, using EKS is substantially cheaper than Heroku). That said, we are actively working on partnering with independent cloud providers with cheaper k8s offering for those who are running small projects. At the moment the cheapest option is to use Digital Ocean with Porter, which can be as cheap as $35/mo. With regards to Qovery, AFAIK, Qovery also runs EKS and does not yet have the option to use cheaper cloud providers like Digital Ocean.
[1] - https://github.com/Qovery/engine#-plugins
As an early stage founder, my time would be way more valuable than $70/month. I need to do as many (practical) things as I can to focus on delivering the unique value of my product.
My team is evaluating porter versus alternatives like Qovery and Skaffold. What is your pitch on Porter versus other attempts to replicate the magic of Heroku with kubernetes on a directly controlled cloud?
I describe this in more detail in the comment above, but I would say the biggest difference between Porter and Qovery is that we intend to make Porter a platform that accommodates not only those seeking the magic of Heroku in their own cloud, but also the devops engineers who want to customize and "opt-in" to be exposed to the underlying complexity of k8s. Please give the above comment a look and lmk if you have any lingering q's.
[1] https://docs.getporter.dev/
However, we were surprised to find that a lot of our users actually fall in the middle - they want to run things in their own cloud, but don't want to deal with the complexity of k8s. Perhaps the biggest change in the last 3 years is that k8s became a popular option even for startups - adoption of k8s has been "trickling down" and now the k8s user base is increasingly composed of those who "know the basics of k8s, but don't want to deal with all of its complexity". We've found that a platform like Porter fits in with that type of demographic, and we are optimistic that there are more of these companies based on our current data.
Our goal with Porter is to create a platform that accommodates both ends of the spectrum. And this is motivated by seeing companies develop internal developer platform (IdP) that I mention in the post - we want to create a platform that abstracts k8s away to the extent of Heroku's DX while accommodating the DevOps engineers' need for flexibility/configurability on top of k8s. This is why we invested in features that optionally give the user more visibility into the underlying k8s cluster and helm charts.
By default, Porter looks and works just like Heroku. With "devops mode" turned on, Porter looks more like OpenShift and Rancher. Essentially, there are two user personas we are building for: an application developer with no knowledge of k8s and the devops engineers who need to help the application developers and often even build out an IdP. We are focused on the former for now, but I think what distinguishes us from the other k8s based PaaS's is our commitment to building the mature version of Porter to accommodate the latter.
Do you have any plans to cater to devops engineers who want to use infrastructure as code tools such as Pulumi or Terraform to manage both their Kubernetes cluster and their other cloud resources (e.g. AWS RDS database) with one tool?
Also, just so you know, the abbreviation IdP (with that particular capitalization) is already a term in security, particularly in the context of single sign-on; there it stands for identity provider. Edit: I suggest IPaaS as an alternative.
> Do you have any plans to cater to devops engineers who want to use infrastructure as code tools such as Pulumi or Terraform to manage both their Kubernetes cluster and their other cloud resources (e.g. AWS RDS database) with one tool?
Yes, this is a request that we've gotten from current users, and we'd like to release a Terraform module in the next two months that allows users to provision a cluster compatible with Porter for this exact use-case. We're also thinking about releasing a Terraform module that can install a cluster hosting the PaaS layer for fully on-prem use-cases. This wouldn't be too hard to do considering our cluster provisioner is packaged as a Terraform runner and we use Terraform to manage our infrastructure internally.
Also, we're going to open-source our provisioner in a separate repo at some point soon, and we're thinking about using Pulumi to get slightly more control over the automated infrastructure provisioning (using Pulumi's automation API: https://www.pulumi.com/blog/automation-api/). So I wouldn't be surprised if we released something more native to Pulumi as well, but we have to look into it more.
> Also, just so you know, the abbreviation IdP (with that particular capitalization) is already a term in security, particularly in the context of single sign-on; there it stands for identity provider. Edit: I suggest IPaaS as an alternative.
I thought I recognized that abbreviation -- I believe we picked it up after reading an interesting article about various internal dev platforms[1] (to be fair, that article uses the capitalization IDP).
[1] https://www.infoworld.com/article/3611369/how-to-build-an-in...
One way porter could interest me would be if it incorporated best practices for me not to get fleeced by the cloud operator.
That said, for small projects we are adding support for cheaper independent cloud providers very soon. We've talked to folks at both Vultr and Linode, which provide significantly cheaper k8s offerings, and are working with them right now!
How so? Doesn't AWS break down the cost of each resource you consume? I suppose it's difficult to predict all of the little costs that will add up though.
is there some reasoning behind it or are we running out of ideas?
Most devs try to avoid a lock-in situation. Having an open source option for the base functionality with additional paid features is something you can compete on.
I can't speak for other companies, but we didn't look at Heroku and think to just create an open-source competitor. We thought of the idea after interacting with companies that migrated to Kubernetes that wanted their Heroku experience back, and later decided to be open-source. So I don't think our core value proposition stems from the open-source aspect, but it made sense for a lot of reasons -- unique to our product/team we felt that open-source was appropriate for a tool in the cloud-native ecosystem and since all three of us are developers, it was our natural inclination.
On the technical side, being open source has come with a bunch of benefits thus far -- we get detailed bug reports since our users are developers, we get a channel where devs can keep tabs on our progress, it gives us a public log where we explain our decision-making in the specs for various features, and it forces us to be better technically. We had to create a development process rather than just push code (when we worked on projects in the past, we didn't follow best practices with regards to PRs, documenting issues, reviewing code and testing changes, because we were solely focused on immediate velocity, which we would have regretted if those projects ever got off the ground).
We decided to go open source quite naturally for the benefits that Alexander mentions, but we are also aware of the business benefits that OSS brings. Open source/open core is increasingly becoming a standard in the devtool world and as the other comment points out, there is a certain degree of natural selection at play. To gain traction as a devtool company and drive bottoms-up growth, building in public helps tremendously these days, because developers almost don't want to use closed source products. Although the rise of "open core" and commercial open source projects does come with a bit of tension with open source purist ideology, I think this trend is something we should welcome as an industry. But this trend definitely isn't just a result of running out of ideas like Disney's endless real life remakes :)
I absolutely love the fact that they simply show me what the product looks like. Often times you have to dig through docs and "features" pages just to get a glimpse of the offering. Here it's front and center, screenshots are right there in your face, can't miss it even if you want to.
To other SaaS developers, I say: SHOW ME THE DAMN PRODUCT!
The only step up from this is to have an interactive, radically simplified version of the product embedded in the landing page, with dummy data I can play with it, just to get a feel of the product. Obviously this is much more difficult to get right.
Showing off the product with clear screenshots is a real differentiator for me - I can understand far more quickly what you're offering from that visual.
Making that interactive (in a minimal sense) would be a great next step - demo accounts are nice, but a working demo in the actual page itself would be really powerful - someone looking at the screenshot wondering if it has X option can click it and see for themselves.
Just having a live demo link would be great.
The setup was simple - EKS cluster created for you (or you can use your own), automatic bot instrumentation to build and push containers for you, Heroku-like "git-ops" etc.
But, under the hood they made the (IMO) wise choice to use each cloud's tooling as much as possible so you can modify things as needed. For example, the EKS cluster on AWS is in a regular autoscaling group. Persistent drives for containers (if you opt-into them) are regular EC2 block devices, etc.
So glad to see them grow into what they've become today :)
[1]: https://dokku.com/
Also, lots of companies in this area, was talking to folks behind Octad (https://octad.io) who are doing similar stuff too.
I also wonder how will it all play out in 1yr and how it would impact customers. Almost all these cos are on the similar tangents - Render (self hosted), Qovery, Convox, Platform.sh, Octopus.com, Reploy, Releasehub, etc etc.
Also, if a Kubernetes deployment malfunctions (or any other Kubernetes resource is added incorrectly) and you created it through Porter, it's a bug on our end, and would be dealt with by pushing a fix and requesting that you upgrade that application to the latest version. Along with this, if a Kubernetes deployment fails due to expected behavior (e.g. your worker machines are out of resources), it is our responsibility to propagate that error to the user and give you an easy way to fix it.
Again, there are likely some edge cases for more complicated use-cases, but this has been our experience so far.
I've looked at many of the attempts similar to this over the years and while you hear "you don't need to know how to operate K8S" you are in fact operating K8S and when there's a problem suddenly all this complexity is revealed. If Heroku has a problem, it's pretty clear where the responsibilities lie, but with this it's your code but my deployment so I'm kind of on the hook. What are your thoughts on that?
How would you compare to something like app platform at Digital Ocean?
Thanks!
You're definitely right to flag that there's a fine line between a useful and leaky abstraction of Kubernetes as a PaaS. Since Porter expects you to deploy services by linking up a GitHub repo or Docker container, our responsibility is the same as a service like Render which also delivers a Heroku-like experience on Kubernetes. Fwiw at least half of our users are teams that have no existing familiarity with k8s and they're able to use Porter treating it purely as an implementation detail.
> How would you compare to something like app platform at Digital Ocean?
The main difference on the flip side is that app platform locks you out of deeper control of the underlying infrastructure if you ever want it (say, for configuring a production environment): https://docs.digitalocean.com/products/app-platform/#when-no.... Also, I suppose it goes without saying, but the abstraction we provide has the benefit of being cloud-agnostic and is the same regardless of where your environments are hosted (DO, AWS, GCP, etc).
https://docs.qovery.com/docs/getting-started/what-is-qovery/...
We also plan to support a more out of the box behavior by adding integration with GitHub's recent deployment feature: https://docs.github.com/en/rest/reference/repos#deployments
1. Modeling all platform capabilities with Helm/CUE modules, so essentially a PaaS built with Helm/CUE.
2. Self-service workflow based on above LEGO-style components.
3. No specific add-on system, so just Helm charts.
We also auto-gen forms based on Helm/CUE, it's great more and more products are leveraging this capability and wider ecosystem.
I just want to peacefully launch my side projects without being “locked” into a vendor or framework that will start charging me on a random day after it was free.
That’s why I opted out of porter and learned to deploy and build my own automation pipeline.
Please change my mind porter guys.
It is simply too premature to settle on pricing at the moment because we do not have enough data on the "bigger users", who will likely comprise most of our revenue. We have no intent to go out of our way to squeeze revenue from smaller users hosting side projects - quite frankly, the addressable revenue of that user segment is just too low compared to that of larger businesses for us to even fight that battle.
Is there a guide on how to deploy with docker-compose, instead of dockerfiles?
(The load balancer is the issue: there seem no good ingress solutions if you do not have hardware support even though there are lb as a service like cloudflare and software loadbalancers which are not supported. Again as far as I can find)
But we're working on Azure support first, and then looking at some smaller providers. I would expect the first Azure rollout in ~4 weeks.