I run a handful of small PHP apps with Redis and Postgres as add-ons. Max 5 Standard 1X dynos per app.
I want strong GitHub integration and would also like the replacement to be Docker-based.
I imagine there are tons of developers like me out there. And it seems like there are many options. Which ones would you recommend?
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.
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.
When you're running a real business and don't want to be woken up at 3am this is worth every penny.
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!
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?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).
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.
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 got your point across in your various comments.
My only beef right now is the routing/autoscaling, which I believe they're in the process of improving.
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!
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)
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).
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.
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.
For me it's the sweet spot between Heroku and AWS.
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).
Any recommendations for two small Node.js applications?
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.
I utilize it to host many different PHP and Java apps.
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.
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’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)
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
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.
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.
If you wanna see pure magic, CMD+K —> PostgreSQL (or Redis). ~3s and you’re good to go.