Heroku alternatives have gone in a few different directions: - next-gen PasS that are more opinionated and offer wider range of services. Also can be cheaper. examples are Digital ocean, Railway or render - Performance-focused PaaS like fly.io - "Heroku in your own cloud" like porter.dev, architect.io or quovery - k8s tooling like garden.io, ReleaseHub, even gitlab - these are often geared more towards internal DevOps teams at larger orgs when compared to the very low-lift PasS providers - serverless providers - like cloudflare functions, AWS lambda, GCP Cloud Run - Vercel/Netlify - SPA + serverless with a great developer experience - Replit - kind of in a category of their own but they have integrated hosting/datastores/user auth

Lots of awesome products here, I'd argue that only replit is a true 10x change from the Heroku innovations in terms of providing a next-gen developer experience.

I'm the cofounder of a new company called Coherence, that we think creates a new direction and offers a better platform for the next leap forward. By integrating from dev to prod and capturing the whole SDLC, as well as by operating in your own cloud, we're focused on delivering the best developer experience possible, without compromising anywhere else. For example, by not building 100% on k8s we’re able to offer Cloud Run on GCP or App Runner on AWS, which are “free-tier” friendly without the fixed costs of the k8s baseline infra that other “in your own cloud” providers have. Check us out at https://www.withcoherence.com. We're in an early closed beta so not yet a fit for all teams, but feedback is welcome!

Came here to dump a similar list, but bravo this covers a lot.

As for Coherence: Sounds great. I see a future where this makes so much sense - managing distributed dev teams with a fully managed env like this seems like one of the obvious end-game outcomes. Prospect questions: will it run off-Coherence? i.e. will I have the option to spin up the pieces myself if the startup powering this good idea gets "incredible-journeyed" or otherwise goes away? You mention running "in your own cloud". How open source is this stack?

Obviously keeping your core secret sauce secret has a lot of merit, just a shout from the void about a potential (but not insurmountable) objection. (sorry if this is covered elsewhere, I read your announcement and browsed your site but didn't get too deep)

Thanks!

As far as business continuity for the end of our journey, that’s one of the main reasons we believe so strongly in running in your own cloud (along with extensibility, cost and compliance). I don’t believe that this means we need to be open source - it’s not on our roadmap to do that.

Our vision is to operate your control plane and configuration layer, while your customer-facing apps and data remain 100% in your control. If we are spinning down, our promise would be to give you some client-side tooling to replace the control plane, but even if we don’t keep that promise, you’d be able to figure it out on your own and nothing would affect your running apps/data. In the end we’re just configuring cloud services on your behalf and you could go back to doing that with terraform/pulumi/etc yourself (as you’d have to do today without our service).

I know it’s not shiny and new, but we use AWS Elastic Beanstalk, which automates everything but still gives us full control over the EC2 instances if we need it. It has built-in support for Docker, PHP, and several others. We use AWS’s managed databases (RDS/Aurora) and Redis (ElastiCache) with automatic failover, and both have been solid in the three years we’ve been on this setup.

Why not just use a $10/month bare bones virtual machine?

I just use plain Debian, copy my stuff over via rsync and everything works fine.

The machine gets something like 10k users on a normal day. In the past, it occasionally handled 30x that.

Speaking for myself, the issue is that I don’t know enough about devops/security to go barebones (esp if for a side project accepting payments w/ sensitive data). It’s of course dead simple to set up a server barebones, but to do it in a way for a service open to the internet with uptime requirements requires more specialization of knowledge these days.

OS level security? What does a service like Heroku even offer in this regard?

You can turn on autoupdates or run "apt update && apt upgrade" regularely. If an OS level exploit slips through that, you will probably be affected no matter where you are hosting.

But OS level exploits are super rare. The problem is usually your application. And Heroku and Co cannot guard you against those problems.

I'm not sure what you mean by setting up a server "in a way for a service open to the internet". "apt install php" gives you pretty much all you need. And it is ready for the open internet.

It's crazy how the cloud companies/Windows/Apple have encouraged modern developers to be scared of running apt update/upgrade.

Can marketing cause learned helplessness?

This has nothing to do with the companies you mentioned, and everything to do with the emergence and acceptance of DevOps/SRE best-practices over the last decade or so, which can hardly be reduced to an occasional `apt update`. There is a saying how "The building codes are written in blood". this translates quite well to modern software development lifecycle. It takes a non-trivial amount of work to maintain an internet-facing system in a secure, fault-tolerant, and scalable fashion, especially when e-commerce comes into play. At least if it's anything more serious than a toy project page or "brochureware". And modern developers don't want to deal with this toil - it's a solved problem at this point - they want to code features and build products, and it's wonderful that platforms exist that enable them to do so without having to lose sleep over the CVE du-jour.

It's just websites.

Heroku does isolate the application somewhat. You would have to add some amount of itables configuration, ssh setup, web server config, "don't run everything as root", and so on to your list. All doable of course, but there's a reason people pay for things like heroku.

You don't have to do any of those security wise.

On a plain Debian installation, do "apt install php", throw your files into /var/www/html/ and your application is up and running in a secure fashion.

You do need to at least: set up automatic security patching (a one-line command), turn off password authentication, disable root, and probably run ufw or something. It’s not hard, but it is slightly more effort than Heroku.

The hard part is making sure this random list of things I found on the internet is sufficient to keep the site secure, and taking the blame if it turns out not to be.

As opposed to trusting the random black box company on the internet? Don't you take the blame still for picking a company whose product you are unable to do due diligence on?

The OP wanted updates to happen in some automated fashion from a git repo. Also, didn't say specifically, but I'm guessing they wanted https and certificates.

Indeed. Besides GitHub integration, Automatic Certificate Management (ACM) is actually a feature I really appreciate on Heroku. Some might describe it as glorified Let’s Encrypt but nonetheless I appreciate things like that just working out of the box

This comment is kind of ironic given that the recent Heroku breach presumably triggered the OP’s question :)

There’s an added advantage to running your own server or VM. Heroku is a big, juicy attack target. Your little side project is not. If you take the basic precautions, your VPS will probably be just fine unless you become super successful and a juicy target in your own right.

The security history of VPS’ don’t lend much credibility to your argument. It was a running gag for awhile how frequently Linode was getting owned up (they may be great now this was a while ago).

Yeah, I don’t run the provider’s software on my VPSs, so it’s mostly a non-issue, especially if you encrypt your disks.

If you do this you're exposed to the reliability of this one machine. Managed offerings can recover from hardware and other failures without you even thinking about it.

When you're running a real business and don't want to be woken up at 3am this is worth every penny.

We do this for some of our legacy apps. I don’t like it and want to move away from it. I lack both time and motivation to think about security outside of the app/code itself.

What security outside the app? Do you think the OS maintainers deliver you an OS full of holes that you have to fix?

Of course not. But I don’t want to spend time choosing, configuring and maintaining an OS install in order to keep it secure. However little overhead that might be it’s almost invariably not worth it, especially since the company I work at have plenty of money to throw at PaaS hosting like Heroku

I absolutely adore https://www.glitch.com for low traffic, small and simple apps. It’s Joel Spolsky’s project; and he’s got Trello, StackOverflow and FogBugz as his previous companies (Fog Creek I think?). Give it a whirl!

I think you can run PHP on there now too; see https://glitch.com/edit/#!/php-poc

For even simpler (static JS/HTML), I just publish on GitLab or GitHub pages.

I recommend Caprover. It's a simple container environment that hosts your services via sensible nginx configurations and Docker swarm, has a cli tool that can be utilized for CI purposes, and provides easy spin-up for common OSS web-apps.

I utilize it to host many different PHP and Java apps.

https://github.com/caprover/caprover

Good in theory but in practice their web interface was often not responsive and I had to patch a lot of services together to make it work. interesting approach though, and a super savvy founder.

Now I use hatchbox.io with a digital ocean box. 15+10 usd month. Works incredibly well. Installs in minutes. Does auto backups. Work best for Rails apps. Haven’t tried other stacks yet.

Nowadays render.com and fly.io are the most promising alternatives.

I’d add [supabase](https://supabase.com/) to the list as well. They have some compelling hosted Postgres options.

Seconding fly.io. We moved a major global service to them and have been very pleased. It's especially nice to be able to provision many frontend servers close to our customers without going through the architectural woes of FaaS.

My only beef right now is the routing/autoscaling, which I believe they're in the process of improving.

Have a POC running on render.com’s free plan. Been very positive experience so far.

Your own server running on your own connection, running off a(n extra) solar panel on your roof which you use to charge a biggish UPS - enough for keeping it alive through the night. If a SBC like a Raspberry Pi is sufficient (and that's what your description sounds like) use something like that, alternatively get something bigger. A single 450W (1x2 meters) solar panel is enough for a lot of computing. Judging by what you describe it should be quite easy to rig up a workflow using standard components which fits your bill, no need for trendy technologies which are sure to be deprecated in a few years when the new trendy thing takes up its place for a year or two in the limelight. Set the thing to automatically fetch and install security updates, only expose web and SSH on a non-standard port (add port knocking if you feel like taking that extra step) and you're set for a long time.

Running your own services is not hard, no matter what naysayers tell you. Just give it a try, start small as described a RasPi uses a few watts so you won't even need that solar system here.

This is an absolutely absurd answer for someone looking for the simplicity of Heroku.

As I said, ignore the naysayers. Tell me, in what way is having (say) a Raspberry Pi running (e.g.) Debian on which you're free to install whatever you want - including something like Dokku or CapRover if you want to do the PaaS thing - an 'absurd' proposition? It sounds like a good suggestion to a question of this nature asked on a site called Hacker News.

I will never understand this fear of self-hosting. To me it is absurd to insist on using third-party services when it is so incredibly easy to setup and maintain your own.

You're talking about someone literally installing solar panels on the roof of their house and buying a UPS. That's the polar opposite of the value proposition of Heroku. Your answer isn't helpful for this person.

Use any old laptop and a) you won't need those solar panels while b) it comes with its own built-in UPS. If your place is anything like mine you'll have a few old laptops just collecting dust which are perfectly useable for hosting the average small service. Configure it to install security updates automatically, install your favourite PaaS package and you're off. Easy, cheap, accessible, decentralised. How much easier do you want it to be?

This is assuming that people have laptops lying around, that they never turn off, and never take out of the house. Again, you're creating requirements here that are hurdles that people do not need when just deploying to a PaaS.

I know others have suggested this too but https://fly.io is great! Very generous free tier, and it feels as magical as Heroku did when I first used it years ago.

I’ve worked as an SRE and do a fair amount of infrastructure work at my job, so I’ve had periods of time where I ran my own k8s cluster for side projects and more recently ran a nomad cluster. The big caveat here is I enjoyed doing this and it helped my career experimenting with infra in my free time before suggesting it internally. I’ve also had bare metal servers and some of the whole classic fabulous monolith thing which is its own beast.

All that said, if you just want some small easy to use compute with little maintenance definitely give Fly a try! (Not affiliated, just a happy new customer)

For PHP https://platform.sh has got a lot of traction, but it's notc cheap especially for small apps.

If you hadn't wanted the Docker-based backing I would suggest trying one of the services that automates setting up your VMs at AWS, DigitalOcean, Linode etc like https://forge.laravel.com/, https://runcloud.io/, https://serverpilot.io/, https://www.cloudways.com/ etc

Give render.com a try. I used it for our latest startup and it was overall a pleasant experience.

For me it's the sweet spot between Heroku and AWS.

Have to echo this. Just deployed a new app to Render this week. Was dreading it but the experience was really smooth. Was a fan of Heroku but it seems neglected and is overpriced. With AWS I want to gouge my eyes out. It’s early days but Render is a nice middle ground so far.

I’ve migrated 2 apps from Heroku to Render and both worked on my first push. One was node.js job, other was React SPA + Postgrest.

They also have $10K in credits for Atlas companies (and some other programs as well, though not personally using them so don’t know the details).

Don't have specifics, but Azure gives you something like $70 a month free for ever - might be able to run your stuff there for less. Oracle also has something similar - a few VMs free forever that would probably suffice.

Fly.io seems like it might be a good fit. They support Docker + Postgres (they recommend just running Redis in Docker and have instructions for how to do this). And they provide a Github Action for deployment.

Fly.io is also the first thing that came to mind for me. I haven't used it yet but it looks awesome and I've really liked seeing the founders interact here on HN.

Get a generic server and toss dokku on it.

I'm in a similar boat. Except I do not want any GitHub integration and would rather not use Docker. I have simple needs and don't want to manage a server. To me, it is rather strange that there are so few providers that allow pushing code without GitHub/GitLab/Git. Allow me to upload a tar (or similar) and I'm happy.

Any recommendations for two small Node.js applications?

Isn't manually installing an application from a tarball more complex than just pushing a branch from your source control?

Tarball: Build, create tarball, push

Git: Build, git commit, git push to some provider

Those seem pretty similar to me. Maybe you are thinking that I could just use my own repository and push that to the remote. But I don't think that such a provider should have access to my actual source code. It does not need to. All I want to push is the built application.

you still need git or other cvs for the tarball approach

For long running tasks (cron jobs, message queues, fire and forget) I’m the cofounder of https://www.tasker.sh, YC S21.

Feel free to ping me: jay@tasker.sh, happy to personally help onboard and toss in some credits if you’d be willing to chat with us about what you’re building!

I'm trying to understand your service. You write:

    It's really easy to spin up a web
    app in production.
    ... 
    However, it is incredibly difficult
    to run anything longer than a web request.

I can rent a $5/VM with and just run my tasks there. What is difficult about it?

(disclosure: I don't use tasker and am not associated with them, I do work on something in the similar space of "compute without servers")

First, you're coming at this from the wrong perspective. The OP is about alternatives to Heroku - the starting position is "I don't want to use servers". There are a number of rational reasons for this, including OS maintainence and the mental overhead of setting up continuous deployment from your repo (ansible to configure cron? a self-hosted PaaS?). "Don't worry about servers" doesn't just make sense in principle, it's also quite popular in practice - just consider the uptake of things like serverless.

So, starting from "no servers", how do you run something on a regular basis? Let's say "send me a message on telegram daily with some info". Serverless and similar offerings are useless for this, they're a different model (request/response). I did research on "hosted cron" at the time and the options were pretty terrible - there's definitely space here for tasker.

FWIW, this is coming from someone with a default position of "self-hosted only". For my own use, I tried out cron and airflow - they're both annoying and I settled on bgproc [0] as least-worst on my already-existing personal server. I really wanted to move to something hosted by the time I was done (tasker didn't exist).

[0] https://github.com/seanbreckenridge/bgproc

You can totally run cron jobs on a $5 virtual machine! This is how we started.

We find that as the workloads grow, it becomes a bit more burdensome to maintain. Did my job run correctly? Where are my logs? Do I need to make my box bigger? Do I need to pay for a VM when my workload only runs once a day? How do I get my code from GitHub onto the box? etc.

All of these are solvable, certainly. Just as Heroku removed the need to set these things up, so too does tasker but purpose built for batch processing.

But does it make a difference if I have to look up how to do these things on Tasker vs how to do these things on Debian?

"Did my job run correctly?" can mean so many things. I have to define what that means for my specific use case anyhow. What does Tasker offer here?

You don’t mention how you are going to handle the deployment process, logging (rotation, access, etc), metrics or the like. Those are obviously solvable but each takes some amount of configuration and management that some people don’t want to do.

If you are going to say “just use a vm” for every PaaS offering get ready for me to ask “why a vm?”

You could do everything you do on a vm with a bare metal server as well and it’s pretty easy and you maintain more control. Of course you probably have good reasons, perhaps lend others the same benefit of doubt?

You are (intentionally, I think) unaware of the context of this entire discussion where these are people who aren't comfortable managing their own servers. They don't know what they don't know. They don't want to learn about systemd, sshd, users and groups, apt, ufw, and however many other things needed to run on a VPS.

You got your point across in your various comments.

At least according to the landing page it doesn't really sound like a Heroku replacement (Especially because OP mentioned databases and app hosting or Docker) and more like an ad for an unrelated service.

I’d start answering this question by asking “why do you want to leave heroku”.

If as you’re stating, the recent security issues are the main reason, I am pretty sure you’re not going to find a better solution by switching. Any vendor or internal ops team is going to have vulnerabilities. Thinking security issues are limited to Heroku is not logical.

However you might object to the way they handled the security issues. I totally agree with that being a good reason, not because of this specific incident, but because in my opinion, this is a sign of bigger issues at heroku. In short Heroku has been stale from a product point of view and has lost a lot of good talent to deal with product and operational needs they have.

To me, replacing one PaaS with another is not a good idea. All PaaS providers suffer from the same fundamental issues of rigidity (you work around their limitations and not the other way around), price (they can’t transfer commoditisation of the cloud to their customers), and vendor risk (single vendor that can be bought and shut down by the buyer - remember AppFog or Tutum? - or at least lock you in)

Doing it yourself is also not a very wise choice for a lot of people: you either need a devops and SRE team or you’re left copy pasting scripts from across the internet to build and configure your servers.

Alternatively you’re pressed to learn a new tech (kubernetes, dokku, et al) and spend your time on that instead of your app.

I’m a proponent of a middle ground: vendors that take care of devops for you, the way your team would have done so, without the inhibitive costs. Consultancies are one option but they can build something for you at a cost and then you’re left with either keeping them around to maintain it to stuck with a tech stack you can’t manipulate yourself.

Companies like Cloud 66 or any other ones that build and maintain a PaaS like experience on your own servers without their own complex magic are the best ones out there in my opinion.

I’m biased towards Cloud 66 as a founder, but we built it not to build another PaaS, but to try to address the actual question of why everyone starts with heroku and no one seems to stay on it for long.

Digital Ocean has a buildpack based system and is pretty darn nice.

You may want to consider vanilla kubernetes and https://codezero.io for the development part of the SDLC. Also, here are some considerations when taking a platform based vs tools set based approach to the whole SDLC https://blog.codezero.io/5-myths-of-kubernetes/

AWS elastic beanstalk. Works with docker and handles running and scaling your app for the raw cost of the EC2 underneath. It's essentially heroku on AWS.

Have a look at cloud66.com It takes a different approach to the problem: it creates an environment like Heroku but on your servers on any cloud. This creates many benefits, including persistent storage and support for all available regions of your cloud provider of choice. But it also makes a big difference in availability: your application is not dependent on Cloud 66’s availability and won’t go down.

Look into running Dokku.

Simple and easy and we use it for a LOT of things. It does not tie you into dokku itself and you can manipulate everything yourself with docker and nginx.

Dokku is merely an easy interface on top of the OS.

It’s really not hard. Read the docs and you will be up and running pretty quickly.

Then it’s just a simple “gut push dokku master” to deploy your apps.

Scalingo is a great European-based Heroku alternative, reusing the buildpacks and 12factor approach, it’s very easy to migrate to!

We did: https://scalingo.com/customers/le-wagon

I have similar question. I use mainly webapps but I deploy a container image... I'd like to find something similar and free but european if possible?

There’s always rolling your own BOSH+CloudFoundry, but that be a bit heavy for your idea case. How about playing with microk8s and seeing if it works for you?

I like Cloud Foundry as much as the next person who worked on it, but in this case it might be like killing a fly with a howitzer.

Not a straight alternative but I use Firebase for a lot of “small” projects.