> it does seem like your target market are dev teams which are light on DevOps skillsets because you can run these systems for free with a modicum of DevOps chops on the team.
Managing infrastructure at scale is not trivial (otherwise, why would full-time devops engineers exist?), and that's why platforms like Porter exists to help companies scale more easily with fewer devops resources. It's the same reasoning as why so many developers like yourself use Fly.io - you could run your applications for free on an EC2 instance instead of paying fly.io/heroku/render a margin on top of it if you have a modicum of devops chops. Yet clearly, these platforms are bringing enough value in the axes of developer experience and reliability that justifies the additional cost for you.
RE your comment in the other thread about there being open source options: it's worth mentioning that Porter is also open-source (repo here: https://github.com/porter-dev/porter). If you want to use Porter purely as a UI on top of your own infrastructure that you are managing yourself, you are more than welcome to take it out on a spin with our OSS repository!
Co-founder and OP here. First off, it's worth mentioning that we did not ask the customer to write this blog post in any way. It was a write-up that taught us a lot about the adoption journey of our own product, so I just thought I'd share it on HN (honestly surprised that it made to the front page).
I've touched on this in the other comment, but I'd like to once again reiterate that Porter is not meant for small scale projects that do not warrant the scalability of something like Kubernetes. We actually advise many people getting off Heroku who are interested in Porter to use Fly.io or Render instead, because for most individuals who are running projects that do not anticipate scale, those platforms make more economic sense.
Porter is designed for companies, not individuals. The base infrastructure Porter provisions alone is around $300, so if your spend on Heroku is less than that, it's more affordable to stay on Heroku or use a platform like Fly.io/Render. For companies who are running at decent scale, however, we've found that Porter starts making sense earlier than you'd think, because cost on platforms like Heroku starts increasing rapidly as you scale beyond a certain point (e.g. a single Performance L dyno on heroku already costs around $500/mo). This particular customer has actually been on Porter for more than a year and had no fluctuations in their billing.
In comparison to ECS, our customers actually tell us that Porter is easier and more developer friendly than ECS (many of our users migrate from ECS as well, not just to improve scalability but for the better developer experience - we wrote about it here: https://www.porter.run/case-study/why-woflow-moved-from-ecs-...). There's no denying that Kubernetes is complicated - do most startups need Kubernetes? Absolutely not. But if it's actually easier to use than something like ECS and as easy as Heroku, why not deploy on the most robust, industry-standard orchestrator that you can customize later and leaves no stones unturned for the future?
Porter supports GKE as well as EKS, and which k8s offering you use under the hood is largely unimportant to the end user because Porter abstracts k8s anyway. Migrating from a platform like Heroku to Porter is just a few hours of work.
If you're an early stage startup, you certainly are our target demographic - for startups with less than 5M in funding, we also offer a startup deal where you can get $10k in credits from us (you can apply from our pricing page). If you have any cloud credits on AWS or GCP, which is fairly easy to get as a startup, along with this deal you can effectively use a PaaS for free because the infra runs in your own cloud account.
Also just to clarify, our pricing structure is designed to increase more slowly as you scale. We offer volume discounts above a certain resource usage, so that your cost increases more logarithmically rather than exponentially.
Co-founder here. Thanks for asking this - we get this question a lot and have tried our best to address it in the FAQ section of our pricing page (https://porter.run/pricing). Infrastructure provisioned by Porter is constantly managed by Porter so that the end user does not have to worry about the details of maintaining a Kubernetes cluster. In this regard, our pricing structure is identical to traditional platform as a services like Heroku, Render, Fly.io, or Vercel, where the respective PaaS provider is effectively charging a margin on top of their own cloud resources on AWS/GCP. This form of leasing out the PaaS provider's AWS/GCP infrastructure to end users also often results in rapidly increasing costs especially as you start hitting scale on hosted platforms like Heroku.
The value you get from Porter is the same as these platforms: with the clusters plugged into our internal system, our team monitors your infrastructure and owns its reliability so the end user can just focus on the application. Other platforms that also run in the customer's own cloud, such as Red Hat OpenShift, has similar resource based pricing models.
On this note, we offer an option to bring your own Kubernetes cluster and connect Porter to it. In this case, the end user manages their own infrastructure and Porter purely acts as a UI on top of your own Kubernetes cluster. Accordingly, for this use case, pricing is based on the number of user seats instead of resource usage. Many of our customers who use Porter in this capacity often have their own DevOps teams that manage the infrastructure and use Porter purely as a means to simplify deployment for their developers.
It's also worth mentioning that Porter is not meant for small workloads or hobbyists. If your spend on Heroku is less than $300, we actually do not recommend using Porter and have advised many users who were interested in Porter to use platforms like Render and Fly.io. Porter is designed for companies - mostly startups - who actually need to scale their applications and have sufficient budget for their cloud infrastructure.