I am a bit in a pickle. Looks like I cannot trust or even use Heroku any more. The trust is broken a bit because of how they are handling the breach, that they had.
The "use" is even more complicated. I've used review apps extensively with their pipeline, and since they revoked GitHub integration 2/3 of Heroku are non-functional for me (no review apps, no staging migration pipeline).<p>I've been looking for alternatives and found them severely lacking in security scope or basic functionality.<p>Render.com<p>- There is no concept of read/manage permissions. Anyone who is invited into a team can delete the team, all apps, services etc. By design of their UI also possibly by mistake. Support responded that they have been working on this the last 2 years or something like that.<p>- /tmp folders are misconfigured. This means that if you send a large enough POST and the web server stores the payload into a temp folder, that seek file is lost. I noticed this after a week of random EOF errors that the web server reported. The support responded I should just use their disk offering and that ephemeral services should not use temp folders, mind that Heroku is also ephemeral but /tmp folder can still be used because otherwise you have above problem.<p>- GitHub integration. The problem is that only one team/user can link the app to the entire platform. This means that if other team members visit the "Blueprint Sync" page, they will see an error that GitHub integration is broken. And for every team that you have, you would have to create a new GitHub user, just to set up sync and only that user can then see sync status.<p>I feel they are working hard and are closest to the Heroku. Yet I feel they are not up to the task that Heroku was/is, in particular I think they are not using the service themselves otherwise they would fix these shortcomings a long time ago.<p>Railway.app<p>They have Teams properly solved, and GitHub integration also works as expected. But they have issues elsewhere.<p>- Builder is slow as hell. For example, 200mb bundle needed 6 minutes to be deployed (they don't have build cache) and I was able to do it only once. The second attempt resulted in timeout (builds in 179s on Heroku and on Render in ~30s).<p>- No support for scheduled executions. This is a feature that both Heroku (Scheduler) and Render (Cron Jobs) provide. What it does, it spins the bundle/container and executes something at specific interval, you pay extra, but that's the whole point so that you can run more demanding tasks. I would have to rewrite everything into fake web cron of PHP era.<p>Do you know any alternatives besides these two? What are your plans with Heroku?
(Render founder) I'm very sorry you ran into these issues. I'll follow up with the team and get back to you over email. We obviously have work to do, but I should note that we do use Render ourselves every day (render.com and dashboard.render.com both run on Render, and so do a bunch of our internal applications).<p>So why haven't we fixed everything yet? Ultimately, our bandwidth is limited (but growing!) and every day is an exercise in ruthless prioritization. We haven't ignored role based access control — we just haven't gotten to it yet (as a side note, <a href="https://feedback.render.com" rel="nofollow">https://feedback.render.com</a> shows things we're working on right now).<p>I can't provide ETAs, but I can say with full confidence we will address everything you mentioned, and more. Give us time!
I’ve been using Cloud66 for about a year to run a fairly complex rails app that has been in development for about 6 years. Strikes a nice balance of owning the infra while having it managed.<p>The docs could use a lot of work though, and I find upgrading things like Ruby versions far more annoying than it should be.<p>Previously used Dokku for a few years then it was on heroku before that. Switched off dokku to outsource more of the ops.
We moved off Heroku about 2 years ago and use gcp. It’s been really good.<p>GitHub to cloud build. Cloud build deploys to cloud run. We setup multiple branches for different environments and it’s pretty much all streamlined.<p>We find the eco system pretty cool also we use scheduler and other cloud run instances for batch jobs. Worked great for us.
Take a look at Fly.io - <a href="https://fly.io" rel="nofollow">https://fly.io</a><p>They offer scalability across different regions and provide the networking and tooling for it. Their service also has a way to go, but I see continuous progress.
I'm going to be another person to recommend Fly.io. It's phenomenal: The pricing is good, the UX is good, everything just works. The GitHub action is a bit simplistic but it's more than easy enough to just make your own action that runs flyctl. The only real issue I have with it right now is there's no API token system, you need to give CI access to everything you can.
I use hatchbox.io with a Linode.<p>Hatchbox is really great, and very affordable for my needs!<p>I like that it's a UI and some opinionated tools and processes on top of a standard Linode VPS.<p>I can still SSH into my Linode and it's all there.<p>Performance is totally down to the size of the VPS you pay for!<p>I dont have time/skills/focus for devops, and have found that Hatchbox took away the pain by affordably managing deployment of a bunch of Rails apps that didnt warrant the larger costs of Heroku!
I've been wanting to try fly.io.<p>I also use Digital Ocean's App engine, but its definitely not as hands off as Heroku, nor does it have the generous free add-ins for small apps (e.g. free redis or pg).<p>I've had a bear of a time trying to get elastic beanstalk to work on a rails app.
There's Dokku: <a href="https://dokku.com/" rel="nofollow">https://dokku.com/</a><p>I haven't kept up with it in years, so I'm not sure it's still the status quo.