Like Heroku, Porter takes care of a lot of generic DevOps work for you (like setting up CI/CD, containerizing your applications, autoscaling, SSL certificates, setting up a reverse proxy) and lets you deploy your apps with a few clicks — saving you a lot of time while developing. However, as you probably know, there’s a downside: platforms like this become constraining if and when your app takes off and you need to scale. The time you saved while developing can get pretty expensive once you’re paying for a lot of users — and the platforms tend to try to keep you locked in!
Our idea is to give you the best of both worlds: use Porter Cloud for as long as it saves you time and development cost, but at any time you can press the “eject button” to migrate your app to your own AWS, Azure, or GCP account as you please. We make it seamless to break out, so you’re no longer subject to the rigid constraints of a conventional PaaS. You can migrate in a few simple steps outlined here: https://docs.porter.run/other/eject.
A bit of background: we first launched on HN almost 3 years ago with our original product (https://news.ycombinator.com/item?id=26993421, https://porter.run), which deploys your applications to your own AWS, Azure, or GCP account with the simple experience of a PaaS.
Since then, we’ve helped countless companies migrate from a PaaS to one of the big three cloud providers. Most of them had gotten started on a PaaS in the early days to optimize for speed and ease of use, but ultimately had to go through a painful migration to AWS, Azure, or GCP as they scaled and ran into various constraints on their original PaaS.
Interestingly, we learned that many companies that start on a PaaS are fully aware that they’ll have to migrate to one of the big three public clouds [1] at some point. Yet they choose to deploy on a PaaS anyway because outgrowing a cloud platform is a “champagne problem” when you’re focused on getting something off the ground. This, however, becomes a very tangible problem when you need to migrate your entire production infrastructure while serving many users at scale. It’s a “nice problem to have”, until it isn’t.
We’ve built Porter Cloud so that the next generation of startups can get off the ground as quickly as possible, with a peace of mind that you can effortlessly move to one of the tried and true hyperscalers when you are ready to scale.
We are excited to see what people build on Porter Cloud. If you’ve ever dealt with a migration from a PaaS to one of the big three cloud providers, we’d also love to hear about your experience in the comments. Looking forward to feedback and discussion!
[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.
The key benefits for a small startup team are:
1. Effortless CI/CD: Deploying services on K8s clusters across different clouds becomes trivial. Setup a dockerfile in your repo, point Porter at it, deploy. We mostly run APIs behind AWS API Gateway.
2. Startup credits: You can use your existing credits on AWS, Azure etc.
3. Zero lockin: You can deploy in parallel and switch service providers.
4. Devops expertise: The Porter team have given us next-level hands-on support and help to figure out how to run things optimally. A lot of sensible defaults are built in. As a coder, they have knowledge of how to scale services effectively that (to be blunt) I couldn't match no matter how much time I spent trying to learn it as a lay person.
If you're a K8s and devops master, you probably don't need this. If like me you're a programmer with limited devops skills looking for the fastest and easiest way to just solve deployment and scaling, Porter is close to magic. Plus they have one of the most helpful and friendly teams I've worked with anywhere.
(edit for typo)
How long until they’re victims of their own success and can’t give every customer bespoke support…
There is definitely still some more devops overhead compared to Heroku, and I wish the product was a bit more mature. But even at ~$18k/mo on Heroku spend we’re now spending less than half with Porter. Other than myself and the other engineer who were responsible for the migration, the rest of the team really got to keep their work flows and there was little impact except for swapping some tools.
We had a messy, poorly documented web of micro services and shit too, the Porter team made the migration surprisingly easy all things considered. I’ll work with them again if I ever scale past a $10k/mo Heroku bill (post enterprise contract) with another team.
> 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 :)
Admittedly, my eyes are on pricing here. Couldn’t find anything yet.
Congrats on the launch.
As the second engineer who worked on this migration I'd like to add on to this — the Porter team went above and beyond for us on this process and made it so easy for us.
At first I was wary of all the moving parts we'd have to manage but they took care of a lot of complex things for us and let us have our site running over on Porter very quickly. Even at our not sky-high Heroku spend, the ~3 engineer-months we spent on this are probably paid back by now. Can't recommend them enough.
Cloud Functions are just a http handler with no hard dependencies on GCP.
Cloud Tasks are just a handler and the tasks just hit your Cloud Functions.
Cloud SQL is just postgres.
You connect your github with actions that CI/CD auto deploy to the above.
If you do it that way, you're pretty much dependency free and can move anywhere else if you need to.
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.
What I don't understand is why someone would start with Porter Cloud.
Your statement on the ease of migration really depends on your skill set. An increasing number of software engineers do not have to deal with real infrastructure whatsoever. Most of the "big" companies I've been at have pretty ready made platform abstractions for their engineers.
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
Let's break it down a bit...
"Porter takes care of a lot of generic DevOps work for you (like setting up CI/CD, containerizing your applications, autoscaling, SSL certificates, setting up a reverse proxy)."
All of this is done for you on GCP with the aforementioned services.
"Porter Cloud for as long as it saves you time and development cost, but at any time you can press the “eject button” to migrate your app to your own AWS, Azure, or GCP account as you please."
Why add an additional service, and set yourself up for having to "eject", when you can just start off on the right foot to begin with?
https://www.schneems.com/2024/05/01/build-a-ruby-on-rails-ap...
In the SaaS world, maybe this will be useful to run managed cloud services? (That is, customer A wants a private instance in AWS and customer B wants it in Azure)
At this point, I have to ask: what's your business model? The reason heroku never made it easy to migrate is the incentive you point out.
What's yours?
1. key to a buying decision: I see the documentation for Eject and it looks good, though like any product you'll only able to support it over time if it makes business sense for you
2. I'm interested in this challenge generally cross-industry for companies that sell 'get off the ground' services to startups, on a high margin usage-based model. It's a business model with a constant sword of Damocles, because if your customers do well they would have to leave.
AFAIK the only real solutions
- technical lock-in, either by making it concretely hard or "soft" hard (introduce a whole training regime for employees based on your systems with idiosyncratic concepts and terminologies, so the human skills aren't transferrable)
- build out a kitchen sink featureset including niche products specific to enterprises (a lot of GRC stuff), so they'll keep paying you high margins at scale (this is AWS's journey.)
- invest/take equity in your customers (this is only a partial solution but if they leave at least you'll capture some upside. See: Peak6/Apex & Robinhood)
- capping your fees to a flat upper rate (this will destroy your own expected customer LTV though you keep the customer)
- lock-in long multiyear contracts (this is also a partial solution)
- become an IP troll (e.g. oracle badgering it's legacy customers)
- deliver revenue or addressable markets to your customers that they wouldn't otherwise be able to get (no iOS developers choose it *because of* Xcode or Swift; it's the marketplace)
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
You mention 3x cheaper than Heroku, but the pricing page specifies $10 per month GB RAM, $20 per month vCPU.
I'm having a hard time to compare with Heroku with that information. Also, what about Postgres hosting?
Edit: Porter Cloud also supports Postgres and our in-your-own-cloud offering just uses RDS under the hood for AWS
1. Things like Digital Ocean that make it easy and can scale up
2. The PaaS offerings of the major clouds for example Microft Azure Appspaces.
I think your advantage might be that you could eject into something more enterprise ready perhaps with Terraform/k8s etc. You could also sell consulting time to help the ejector transition to cloud. Because rearchitecting is part of the issue but the new devops and maintenance load is another issue people will need to deal with.
https://github.com/porter-dev/porter-archive
They've probably forked the cloud product, and are leaving the old OSS version up?
I’d highly recommend Porter as the place to go to get started these days. I don’t see any reason that we will migrate away in the next few years, if ever.
For our startup, we instead use Hatchbox [1]. It provides us with that one-click PaaS experience while allowing us to run on your preferred platform (AWS).
I would put the following services in that category:
- Porter - Cloud66 https://www.cloud66.com - Hatchbox https://hatchbox.io
They all manage infrastructure on your behalf within a larger Cloud Service Provider.
Terms I could think of are "DevOps as a Service" or "Platform Engineering as a Service".
How would you call this?
And what alternatives do you see?
$10 per month GB RAM
$20 per month vCPU
As compared to standard pricing which is:
$6 per month GB RAM
$13 per month vCPU
Isn't the developer pricing for small project expected to be less than standard? If its costly than standard pricing then what is the benefit of developers pricing?
Huge fans of Porter, we've been using them for a number of years at Woflow and they've helped us scale effortlessly.
I wouldn't be surprised if as a result migrating from Porter to elsewhere without using the eject button would probably be easier than migrating from fly.io - a sensible architecture on fly is likely more different to a sensible architecture on a 'normal' cloud platform.
(I could be completely wrong about all of this and would want to see worked examples before I get more certain than "wouldn't be surprised")
We included Porter in our post-Heroku research and chose Render. We have loved Render and expect to be with them for quite a while (as we were with Heroku). If they happen to go south as Heroku did, we will find another PaaS... we will not 'eject' to bare metal or self configuration on AWS.
There’s a point in which the hosted PaaS is too expensive.
And what will you do when there are millions to be saved?
Worth noting startups under $5M funding can apply for a year of free services. There's a link on the pricing page to apply.
If Porter can host GPU’s, that’s a superpower render.com doesn’t have.
Excited to try out the product! Render was a better heroku, but porter can do all sorts of cool HIPPA stuff that render charges $500/mo. for
