sungrokshim

OP here. Cloud Run actually does have a git-push deployment and is pretty easy to use. This is why I preemptively added this bit in the post:

> [1] By “big three clouds” we mean the lower-level primitives of each cloud provider. We don’t mean their higher level offerings like AWS App Runner, Google Cloud Run, or Azure App Service, since those run into the same PaaS problems described above.

Porter is explicitly designed to be a competitor to these services that is 1) more flexible 2) cloud-agnostic 3) more cost-effective. Many of our users come from Cloud Run because they need to customize networking settings (timeouts, websockets, etc.) or autoscaling behavior, not to mention the rather expensive cost (taking as an example a machine with 2 vCPU and 4GB RAM, Cloud Run is around 3~4x the cost of what equivalent compute would cost as a VM).

For startups with credits, we offer this deal so you can pair up Porter with your cloud credits: https://porter.run/for-seed-stage-startups.

We also offer a feature called one-click SOC2 compliance that configures your AWS account to pass controls on platforms like Vanta/Drata in a single click, which many startups find useful.

As long as the cloud providers of the world keep inevitably converging to, often against their own will, a single standard for each piece of the infrastructure (e.g. k8s, postgres, S3), most things that you deploy on the cloud will remain portable. You are never truly locked-in.

Similarly, if you want to, you can move away even from a PaaS that is explicitly designed to lock you in to another cloud provider. And as I mentioned in the post, this is exactly what we've done for countless companies that wanted to move from a PaaS to the big 3 cloud providers.

The more important question is: what is the switching cost? Why do companies so rarely switch hosting providers and if they do, why does it take months and sometimes years for them to move?

We want the process of moving from Porter Cloud to one of the hyperscalers as arbitrary as a click of a button.

We support GPUs if you use standard Porter on any of the three cloud providers. Also coming soon to Porter Cloud.

You can adjust resources down to 0.01 vCPU and 1MB RAM granularity. Price is prorated accordingly

Yes data migration is definitely the most gnarly part. We regularly migrate databases with zero downtime using Bucardo (we detail it here: https://www.porter.run/blog/migrating-postgres-from-heroku-t...) and will be addressing this part of the migration in the ejection process in the future as well.

not sure where you saw $30/month minimum! There's no minimum spend on Porter, and you just pay for what you use as low as a 0.1 CPU and 1MB RAM. We do not have a free tier however.

Great to hear that!

> I’ll work with them again if I ever scale past a $10k/mo Heroku bill (post enterprise contract) with another team.

We built Porter Cloud so you can just start on us from day 1 and migrate to the Porter you're used to when you're ready, without spending much effort on the migration :)

yup exactly. we also offer volume discounts on Porter as you scale so the cost grows logarithmically as opposed to exponentially. Our philosophy is that we should win on merit not inertia. If the customer doesn't continue to see value, you can offboard and start managing devops on your own.

Co-founder of Porter (https://porter.run) here - Porter brings that easy PaaS experience to a k8s cluster that's running in your own cloud account (and manages it for you so you don't have to). We specialize in serving the segment of users who don't want to manage devops fully in-house but are outgrowing their existing PaaS providers.

We are offering a credit program for early stage startups that you can apply for here. Happy to fast track your application! https://porter.run/for-seed-stage-startups

Co-founder of Porter (https://porter.run) here - we do not use Terraform under the hood. We moved away from an IaC based system earlier this year to better manage our users' infrastructure distributed across multiple cloud accounts. A decision that definitely turned out to be conveniently prescient :)

With this new system, we are also able to immediately reconcile drifts that occur in our user's infrastructure, which an IaC based system did not allow us to do.

Must have been incredible to see that unfold in real time... I can only imagine!

yup! we use letsencrypt

I've seen people use Wallarm (https://www.wallarm.com/). They have a controller based on nginx-ingress-controller that you can deploy into your k8s cluster. I'm building a platform on top of k8s and the clusters we provision use the same setup (cert-manager + ALB + nginx-ingress). Worth a try!

it's not possible to use docker-compose to deploy on Porter atm. This is something we've considered implementing but it gets too hairy to accommodate every option possible on docker-compose. Please reach out in our community if you have trouble using buildpacks!

Pricing discussion is always tough for startups because the pricing model evolves so quickly and so often. As I address in the post, we are still figuring out the specifics and we completely understand that some users will be turned off by this - we apologize for this uncertainty. I am aware how naive and hand-wavy this sounds, but we genuinely mean it when we say our goal is to not charge smaller companies and indie devs. We are not maliciously avoiding the pricing discussion because we want to "surprise charge" users later.

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.

Ah, this must have just been released, thanks for the correction. I was going off what's listed on qovery's repository [1] - It says "In Progress" next to Digital Ocean, you might want to update it along with the docs!

[1] - https://github.com/Qovery/engine#-plugins

Yes let's talk!

It's great to see enterprises like Alibaba build out these types of internal developer platform (IDP) around Helm. We've talked to the engineers who built out these IDP's at different companies because we wanted to build a generalized solution that is not specific to one company's devops culture. We hope to democratize IDP's to smaller companies who can't afford to build things out themselves internally!

Yes it's possible to do that on Porter. When you deploy an application, you choose which branch you want to deploy from and we build/deploy the application on every push to the specified branch. Under the hood, we write a GitHub actions file in your repo, so it's completely flexible and up to the user to configure how branches map onto environments (i.e. whatever is possible on Github actions is possible on Porter).

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

Teams with little to no k8s experience are the type of users we are primarily designing it for! The advanced features like "devops mode" is completely optional and only useful if you want to expose yourself to the complexity of k8s.

The advent of k8s really gave the PaaS providers the luxury to focus on the platform layer rather than creating the infra layer from scratch. The market is early and we're excited to see what innovation each of us is going to bring to the table!

If you're running small projects, Dokku is a cheaper option compared to running a k8s cluster. Porter helps you leverage all the benefits of k8s like scalability, scalability, configurability, and is great for multi-cloud environments due to interoperability - these are all useful when you're dealing with projects at a larger scale.

Building open source comes with a bunch of technical benefits like my co-founder mentions, and I don't think the recent trend is a result of YC startups "running out of ideas". It's somewhat like food companies going organic - at first organic food was a special thing, but organic food is becoming increasingly common because every company is doing it. (or maybe it's just at my grocery store :) )

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

We've encountered this from our early users and are definitely looking for ways to incorporate transparency of cost. AWS is particularly opaque when it comes to pricing, and I'd love to hear any ideas you have in things that would help you better understand costs. What comes to mind is integrating with something like InfraCost (YC W21)...

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!

This was our biggest hesitation when we were first evaluating the idea - we thought companies want to either "outsource" devops completely by using something like Heroku, or hire a devops engineer to do the devops work, obviating the need for a platform like this.

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.

We've talked to the folks at Azure recently, and Azure support is on its way along with a few other cloud providers!

Skaffold is a bit different from Porter and Qovery because it's mostly a tool for development on Kubernetes, and its primary goal isn't to make deployments as easy as Heroku on k8s.

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.

Yes Dokku is an awesome option for smaller projects. The maintainers are great!

Thank you! That's a great idea, at the moment you need to go through cluster provisioning to get the feel of our product - we were looking for ways to make the product more accessible without having to provision an entire cluster in your cloud (was playing with the idea of demo accounts). We'll take this into consideration when we update our landing page next time. Thanks again :)