jusrhee's comments

The experience after ejecting to your own AWS account is the same as Porter Cloud. If you're using something like Postgres on Porter Cloud that also gets switched to wrap RDS under the hood in the AWS case

Cloud providers (particularly the hyperscalers) are ultimately bundles of multiple services. Given that the hyperscalers do almost everything, you could extend this point in a variety of ways: why do companies already on AWS bother to use MongoDB, Snowflake, or even GitHub when DynamoDB, Redshift, and CodeCommit exist?

The answer tends to boil down to a combination of developer experience, performance, and pricing. Fwiw the actual platform offerings on GCP are also more intuitive than the equivalent services on AWS + Azure where most businesses/startups are hosting services

Edit: cloud vendor lock-in is also a very real phenomenon regardless of how much it just "looks like" all cloud providers should be easily interchangeable. Needless to say, the incentives when you make money selling compute are to keep people on your stuff

Our archived repo functioned as more of a Kubernetes-centered dashboard - Porter Cloud is intended to offer a more complete PaaS experience including spinning up non-application resources like databases

At the moment we only support the major hyperscalers since they're the most common ejection destinations, but we're considering adding more options. No concrete plans for this at the moment though

I'd like to reframe this a bit (Porter co-founder btw). The way we see it, the core value of many PaaS solutions is the reduction of DevOps overhead by allowing teams to focus engineering resources on product and not generic infra maintenance tasks.

Most of our existing users are companies that are already using Porter in their own AWS/GCP/Azure because they want to reduce time spent on cloud management as they continue to grow. Companies like Heroku exclusively provide this service in a hosted cloud environment where they also resell the underlying infrastructure to you (similar to Porter Cloud), but we want to be flexible in delivering the same value on any cloud provider.

If we're doing our job, we will continue to automate enough generic DevOps work where Porter is delivering value even as you scale in your own cloud. We have a good number of late-stage startups (and even some public companies) that have DevOps teams in place using us precisely this way to handle core parts of their infra and application lifecycle management.

Porter Cloud is intended as a way to "get off the ground," but our staying value lies in continuing to reduce the same DevOps overhead even once you're running in your own cloud account

Founder here - the "up to 3x cheaper than Heroku" depends on the exact compute profile, but as a point of reference, Heroku pricing starts at $250/mo for a single 2.5 GB RAM instance on their Performance tier (https://www.heroku.com/dynos). Generously assuming that you get 2 dedicated vCPU cores, the equivalent Porter cost is ~3-4x cheaper

Edit: Porter Cloud also supports Postgres and our in-your-own-cloud offering just uses RDS under the hood for AWS

Porter (YC S20) | Full Time | NYC - Onsite | https://porter.run

We're building a PaaS that runs in a user's own cloud (basically Heroku on k8s). We've converted some of Heroku's largest enterprise users as well as a large base of high-growth startups despite starting just a little over a year and a half ago.

We're still a team of six but we believe in 10x engineers and are looking to grow our in-person team in NYC.

Tech stack: Go, Typescript/React, Kubernetes, AWS

Open positions:

- Product Engineer: https://www.workatastartup.com/jobs/46166

- Backend Engineer (Go): https://www.workatastartup.com/jobs/44501

- Kubernetes Engineer: https://www.workatastartup.com/jobs/45970

Please apply through https://www.workatastartup.com/companies/porter

Porter (YC S20) | Full Time | NYC - Onsite | https://porter.run

We're building a PaaS that runs in a user's own cloud (basically Heroku on k8s). We've converted some of Heroku's largest enterprise users as well as a large base of high-growth startups despite starting just a little over a year and a half ago.

We're still a team of only six people but we believe in 10x engineers and are looking to grow our in-person team in NYC.

Tech stack: Go, Typescript, React, Kubernetes, AWS

Open positions:

- Product Engineer: https://www.workatastartup.com/jobs/46166

- Backend Engineer (Go): https://www.workatastartup.com/jobs/44501

- Kubernetes Engineer: https://www.workatastartup.com/jobs/45970

Please apply through https://www.workatastartup.com/companies/porter.

OP and Porter founder here. The article was meant to outline the most common technical limitations we see companies on Heroku bump up against as they outgrow Heroku. For individuals and teams running smaller workloads on Heroku where saving $ is a chief concern, Heroku is probably still a good option even though they’re declining in market share (this unprecedented recent outage aside). Porter is designed for companies that are maturing off Heroku for the technical reasons we mention or for those already looking to get the automation of Heroku in their own AWS/GCP cloud.

Ah yup good catch - just updated the article

Yup, we're rolling out support for Azure and some other cloud providers in the next few months!

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

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

Yup, we don't plan to support a fully-hosted alternative to something like Heroku/Render where your applications run on our cloud.