I think you'd have a better reaction if you allowed some public repos to be viewed before handing over the keys to the castle, so to speak. Even better would be allowing a public repo to preview itself via better-hub.com/{org}/{repo} would be slick. Expensive for you, but might help onboarding. As it stands, the call to action is poor, so unfortunately there's no way I'm going to login with GitHub and give a bunch of permissions to a new app posted on HN, no matter who built it.
This is my most missed app since switching from Mac to Windows. This new kid on the block looks like a solid replacement, though! Will definitely be checking it out.
It always happens that way. I guarantee some people migrated from Heroku to Railway and bragged about future stability to the team, only to experience this.
I don't see how we need a brand new paradigm just because LLMs evidently suck at sharing context in their Git commits. The rules for good commits still apply in The New Age. Git is still good enough, LLMs (i.e. their developer handlers) just need to leverage it.
Personally, I don't let LLMs commit directly. I git add -p and write my own commit messages -- with additional context where required -- because at the end of the day, I'm responsible for the code. If something's unclear or lacks context, it's my fault, not the robot's.
But I would like to see a better GitHub, so maybe they will end up there.
CEOs have many audiences; great CEOs communicate capably with each.
FWIW it's not entirely clear to me who Entire's long-term customer is, but the (interesting!) CLI that shipped today is very much for developers who are busy building with agents.
Looks like that still has downtime for a Postgres migration- you're suggesting going into maintenance mode and just doing a dump/restore. I've seen that take hours once you hit the terabyte scale, depending on hardware.
I've had pretty good luck setting up logical replication from Heroku to the new provider and having a 10-15 minute maintenance window to catch up once it's in sync. Might be worth considering.
You might also want to add a warning about Postgres versions. There's some old bugs around primary key hash functions that can cause corruption on a migration. I've seen it twice when migrating from Heroku to other vendors.
Sorry, but telling people to take a logical backup of their database, and then download it onto their local work station is insane for a production application. First, a logical backup at any decent scale will fail, and second, I don't even have enough local storage to do that -- even ignoring the compliance issues with downloading a full copy of production data onto a work station.
For a company like Northflank, I'd expect actual production-grade documentation for migrating, not instructions that are only applicable to a toy app.
Some folks want to do that, others want to import a backup directly, some want to spawn a read replica and sync their DB. Different strokes for different folks, all supported on Northflank.
Crunchy Bridge will help you migrate. They did a great job for us. We had a minute or so of downtime to let the read replica catch up and cut across. The team knows Heroku well, and some of them built it. (No affiliation, just a happy customer.)
reply