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