We migrated microservices from Heroku to Porter, and also from standalone VMs and K8s running on AWS to Porter. As a coder trying to do both dev and devops on a tiny team, it was life changing for me.

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)

> Devops expertise: The Porter team have given us next-level hands-on support and help to figure out how to run things optimally

How long until they’re victims of their own success and can’t give every customer bespoke support…

Hopefully the experience they're getting now will make increasingly more of the relevant decisions something they can bake in to their automation and defaults.

We migrated from Heroku to Porter at work (at my behest). Still one of the better bets I’ve taken.

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.

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

Excited to try it out for future projects!

Admittedly, my eyes are on pricing here. Couldn’t find anything yet.

Congrats on the launch.

> the Porter team made the migration surprisingly easy all things considered

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.

I personally don't get it. You can start on GCP today, without being tied to GCP much at all. It isn't even expensive to do so. Is there something I'm missing here?

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.

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

Small startup with brand new team, no devops/infrastructure/security. Most engineers are mid-level and not really strong on infrastructure, they are hired to build features and backend.

In this environment something like Porter Cloud would make it far simpler to deploy apps as they were being built and know that there is a chance of scale (at least to a certain degree). Otherwise you get to watch engineering grind to a halt while everyone learns how ECS/AIM/SSM/XYZ works.

Spend some time understanding what Cloud Functions has to offer. There really isn't much to it at all. A http handler function is all you need. No infrastructure or need to do much deeper than that.

> Is there something I'm missing here?

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.

Yes, OP is talking about the ease of migration from cloud providers vs a PaaS. My point is most companies these days either build their own or operate a PaaS so "migrating cloud providers" would be daunting to them due to lack of exposure to core services (network, compute, etc).

GCP Cloud Functions are PaaS running on top of a “cloud provider”. My point is that if you start with CF, there is no lock in and no migration.

How do you do secrets with CFs without lock-in? Telemetry? Releases? and on and on

Tons of options, some more "lock-in" than others. But the stuff you're talking about in general is really not that much lock-in.

For secrets, I personally use Github for that and you can add them in as a build step. Google also offers this: https://cloud.google.com/functions/docs/configuring/secrets

For logging, I just use Google's logging layer. If I was to migrate somewhere else, I'd just use that logging layer.

For releases, I just used github releases as part of my build step. But google also has the concept of releases... https://cloud.google.com/functions/docs/deploy

and on and on...

None of these are major lock-in problems though... any other PaaS platform you want to go to will need those sorts of things too.

That "not that much" easily turns into months or years of migration once you put enough data into it. Cloud providers are showering startups with credits not due to their inherent kindness - they know once you're in it's tough to move out and you are seriously downplaying the amount of effort and costs involved here.

It isn't expensive to run on Cloud Functions at all. You do it right and it scales pretty insanely high with very little additional cost. I've built multiple successful businesses with AppEngine and CF, so I'm keenly aware of their implementation details.

My point is that this is the solution to use and there really isn't any reason to switch. But, if you really were that bothered that you wanted to to switch, you aren't super tied to it in your codebase. I'm not saying the cost to switch is zero, I'm saying it isn't impossible.

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

Totally; the ability to migrate seamlessly between cloud providers is compelling to many

Migrations between clouds are a rare thing, seamlessly is an impossibility, just too many nuances if you've done it before

You're just like the dropbox launch just use ftp guy

The ftp guy is the spark that inspire me to work on a storage independant web ui as I was trying to understand what in the actual FTP protocol was missing to make it happen. Turns out, it works and file manager are great abstraction to a lot more things than FTP alone and that oss project has been used by a couple millions people around the world (https://github.com/mickael-kerjean/filestash). If the FTP guy ever see this, I owe you a couple beers!

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.

Not everyone gets those credits. If you’re not vc-backed or ai it used to be harder to get decent credits. Also the credits expire after 1-2 years and then what?

Ouch, that's an absurd comparison. Instead of commenting nonsense, how about explaining to me how I'm missing the mark here?

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?

It looks like Preview Environments could be a part of it. It seems costly though. It says they get a copy of the database. I don’t know if they pass the costs on to the customers and if the customers have to avoid pushing code too often without excluding it from the build (by adding something like “no ci” to the commit message).

I love GCP (did a migration to it at my last place), but I think like all cloud providers, it's a lot more "some assembly required" than Porter looks like, or like Heroku used to be back in the day.

To my knowledge GCP doesn't have a git-push deployment. Cloud Run might be the closest thing if you do a Docker push, but that is just one part, then you need a database, still need CI/CD, etc.

It's close. And while I like the look of Porter, I probably wouldn't bother and would jump straight to GCP, but I do think there are usability differences.

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

That is why I said Cloud Functions instead of Run.

Agree, and Cloud Run's upcoming application canvas feature appears to offer a simple way to integrate the various GCP services together seamlessly without much hassle.

> To my knowledge GCP doesn't have a git-push deployment.

https://cloud.google.com/source-repositories/docs/deploy-clo...

It also has the ability to deploy cloud functions directly from github actions, which is super easy to set up and works really well...

https://github.com/google-github-actions/deploy-cloud-functi...

> I probably wouldn't bother and would jump straight to GCP

This is exactly my point. Just do that.

Pretty hilarious that link you posted has a big red banner announcing product EOS but yeah just use proprietary GCP APIs why don't ya

Good catch! Yea, I responded quickly and didn't note that that was Googles private repo thingy that they EOS'd.

Just use the second link. Works fine with github.

I agree, people act like these big providers are so difficult. Almost all of them offer some form of container deployments that takes 30 minutes to setup a GitHub action workflow for, and as long as you keep using open source stuff, like postgres on cloudsql, you are never locked in

Speaking of not wanting to get locked in. I work for Heroku and we are previewing an open source buildpack that produces docker images here’s a tutorial

https://www.schneems.com/2024/05/01/build-a-ruby-on-rails-ap...

Cool concept. In my experience, the biggest headache/expense is data migration, and not software migration. As long as the stack is vendor neutral, it's not the long-poll, though it is gruntwork.

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)

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.

Crunchy Bridge seems to make the data migration simple too - https://docs.crunchybridge.com/migrate/heroku_dump_restore

I looked into porter at the time we were migrating from Heroku to AWS! I thought it would have been a great solution if it was mature when we first started on heroku.

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?

To wit, I ask because:

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)

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

They charge for managing the kubernetes instance that’s running on your infrastructure. What’s cool is that you can stop using Porter once everything on AWS/Azure/GCP is set-up and you’re not locked in. You just have to manage the cluster yourself.

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.

I meant: what's the business model for Eject specifically? Why make it easy for customers to leave (aside from pre-empting buying-decision concerns)

Isn’t it that they expect it increases the likelihood people would choose to use Porter in the first place? The problem being that the biggest clients are probably the most valuable and having this makes them more likely to churn.

Unless I've misunderstood entirely, Eject can move you from Porter Cloud to "you bring the cloud account but some/most things are still managed through your Porter setup."

Very cool! As someone pointed out, your github repo says it was archived: https://github.com/porter-dev/porter-archive Naively, I would think Porter cloud would just be a managed version of your porter-dev/porter-archive. Could you talk about how it's a different product than before? Did the code base change significantly?

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

Thanks! Followup question: After you "eject" the app and start paying AWS directly but continue using porter, is the experience more like the archived repo? Or, is it still Porter Cloud just with different billing underneath?

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

Hey thanks for sharing.

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?

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

I think your natural competition here is:

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.

I think you're right. In fact, that's the stack I would recommend right now to a new (web) app developer. Write your own Dockerfile, some terraform to spin up a docker host on DO, and a bit of GH Actions yml to pass secrets, build dockerfile, upload to container registry, terraform apply. It's a fun weekend project. It's interesting how many ways there are to "build your own PaaS".

Fly.io is too good and no reason to leave it. I am enjoying it much more than DO too

Sounds like an interesting tradeoff. I noticed that the link to GitHub in the footer 404s however. I was hoping this was OSS.

The old repo looks like it’s been renamed to

https://github.com/porter-dev/porter-archive

They've probably forked the cloud product, and are leaving the old OSS version up?

At HomeLight we migrated from Heroku to Porter and it has been great. The team has been super helpful, the platform as stable as you can get, and the cost savings have been tremendous.

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.

This is a great idea.

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

[1] https://hatchbox.io

Had this exact problem (Heroku Postgres to RDS) at my old co. Data migration went as bad as it possibly could (dropped indices, foreign keys, everything but the data itself). This would have saved us months of pain.

I wonder how that category of services, which Porter provides could be called.

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?

I don't understand the developer's pricing (new offering) which is as below:

$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?

The standard pricing doesn't include underlying cloud provider cost. The pricing page can be more clear.

ok but from that page I do not easily understand how much I'm gonna pay. on heroku I know I pay $5/month for eco dyno hours, and then potentially up to $5/month for each small database. here? how much would I pay for a sqlite discord bot and three django applications with their own postgres?

Congrats on the launch guys! This is a great feature, in a world where most companies try to increase lock in!

Huge fans of Porter, we've been using them for a number of years at Woflow and they've helped us scale effortlessly.

Please support AWS GovCloud!

Is the eject button the only thing that makes Porter more appealing than something like Fly.io or Render? They too automate a lot of stuff but for a better price.

I think it's not just the eject button, but Porter's service automation model being designed to move elsewhere with equivalent moving parts underneath.

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

Would this be something to use over Docker containers when running a single host homelab server? What would be the cons/benefits?

I have never quite understood this value proposition (maybe I am not the target audience?) The point of PaaS is to avoid DevOps... making a PasS with an eject just feels orthogonal to the value prop of the main business. Ejecting seems like a low probability event as they CHOSE PaaS in the first place. (unless the money got really high)

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.

> maybe I am not the target audience

There’s a point in which the hosted PaaS is too expensive.

And what will you do when there are millions to be saved?

I am not the target audience as I believe in making profit (a lot of it) so I really don’t believe in any cloud hosting as it is a rip off and even at $1000 a month, let alone more vs our millions $ of profits (our hosting of our main products is $89/mo currently and 0% downtime the past 10 years), I rather have that as profit than giving it to aws or porter or whatever. It is almost never worth it; if it takes more effort to deploy or develop, you are Facebook or Google etc (probably you are not and never will get close; if you do, you can do something at that time if needed) or probably hired the wrong people (resume driven developers) or using the wrong stack (something modern and horrible JavaScript horror most likely).

Any plans to support Hetzner?

Any plans to support eject to on-prem or bare metal hosters like Hetzner?

There's a separate project Cloud Seeder [1] which is completely open source and gives you 1 click server appliances and IP addresses on-premises. Disclosure, I work there.

[1] https://github.com/ipv6rslimited/cloudseeder

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

Looks useful! Pricing page is a bit confusing IMO. It's unclear at a quick glance what the features/benefits difference is between Developers Cloud and Business (bring your own) offerings.

Worth noting startups under $5M funding can apply for a year of free services. There's a link on the pricing page to apply.

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.

Pricing page (developers). How can you have less than 1 CPU?

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

talk to me about GPU’s? I saw some gpu_node config stuff in your documentation a couple days ago.

If Porter can host GPU’s, that’s a superpower render.com doesn’t have.

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

Is there a mailing list I can sign up for to know when this drops?

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

How does this compare to Coolify/CapRover

i think Coolify doesn't have a built in ejection button?

Why just big 3? How about Digital Ocean?

Can I use it on DigitalOcean?

Credit card paywall, so I'd recommend to check Render or Koyeb for these people who prefer to save their time.

Really good concept