I am a happy Coolify user and I could say that it is a promising and quite active project with a vivid community. The fact that you can self-host dozens of services using a single VM is a breeze of fresh air.

Furthermore, with just a bunch of dollars you can get a really good VM from Hetzner and host everything there. At the moment I am using Coolify for small Node.js apps as well as using a few more services: - VaultWarden. - Minio as an object storage solution. - Glitchtip as a Sentry alternative.

Essentially, if you are considering privacy and avoid paying a dime to Jeff directly or sideways (most of the PaaS services are built on top of AWS) projects like Coolify, CapRover, Dokku etc are the way to go.

My whole purpose in using Heroku is to avoid self-hosting something, to get the "platform as a service." Is that not the main attraction of heroku? Maybe not for everyone, if the idea of a self-hosted product as an "alternative" to heroku has traction?

Presumably this is why the cloud/hosted version OP is working on has a good chance of being profitable. Open source means it's hostable as a backup plan, but the cloud version is there for those who want the convenience.

Right. It's not even about the initial setup and provisioning. I can handle that. But what I don't want to handle is constant maintenance. I get weekly notifications of maintenance that Heroku is doing for me. I have no interest in doing these things, or hiring anyone to do them.

That will be Coolify Cloud :) (https://beta.coolify.io).

Ruby/Rails aren't listed as supported apps. My how ruby has fallen. :(

https://docs.coollabs.io/coolify/applications/#supported-app...

yeah, that's disappointing. I'm a Ruby fan and my latest startup is built on the rails stack.

It's using buildpacks though, so shouldn't it be (easily) supported?

Yes, as lolinder mentioned, there will be a hosted version soon. :)

I think simple and not doing it yourself is the entire selling point for heroku.

Coolify sounds cool, And i love the idea of being able to have self-hosting as a backup which it would allow, but i don't want to HAVE to self host. Would rather pay Coolify to host for me until they go out of business / change direction, at which point i can continue on with the self-hosted bit.

This (coolify) looks very interesting. Since others may have the same question as i do: Does it scale horizontally? We actually have our own racks in datacenter and if i gave 3 machines to it would they handle that?

I saw you mention the K8s soonest: is that your scaling solution? Seems it would be simpler.

Regardless I think we may look into this.

You can attach any number of servers (and Remote Docker Engines) to a single Coolify instance (docker swarm is not supported).

If you are using a remote server, the building process of an application is done on the remote server and not locally (on Coolify's server), so Coolify won't be affected on how many builds are doing concurrently. The only limit is the CPU/Memory of your servers. :)

The ultimate & standard scaling solution will be K8s.

Hi! While the project does look very interesting, i'm kind of put off by the code. While it is pretty organized and neat, I can see that all of the services offered are hard-coded. Like the 330 lines long if-else chain in apps/api/src/lib/services/common.ts.

This way every time you need to set add a new service to coolify there's the need to ship a new version.

Why did you choose to go this way rather than a more generalized concept of a service? Wouldn't having a generic service architecture be more maintainable and ( imo ) more importantly add the capability to have a dynamic, global and customizable 'app store' of sort?

> i'm kind of put off by the code. While it is pretty organized and neat, I can see that all of the services offered are hard-coded. Like the 330 lines long if-else chain in apps/api/src/lib/services/common.ts.

I agree and disagree.

I agree that this kind of approach to coding is something that would put anyone senior-ish off totally, but I disagree at the same time because it's only 20-ish services, and the code is easily refactorable.

My assumption - after having read code 30+ years - is that this is done on purpose, so that they want to stabilise the approach and refactor it later. Though, as we all know, there's no thing as "I'll fix this later" in programming, but still (in this case) not something that would put me off.

Also, it's on github, so I could always refactor it for them if I'm not happy with it.

This isn't such a sin for a young project like this - Making code configurable adds overhead and it's often right to avoid 'over-configuration' along with 'over-abstraction' and other 'over-optimization efforts'. What is important is to isolate functions for orthogonality which will allow a project to be refactored according to priority needs further down the line.

The reason, I (founder of Coolify) choose that, it was faster.

I’m currently making a feature, that will change this. All services could be defined with a simple yaml file that won’t be hardcoded. They will be sitting in a repository and everyone can add any service with a simple yaml file.

It is definitely more maintainable than the current solution, but with the current solution, I could iterate faster. :)

Death to yaml. Thank you.

> Like the 330 lines long if-else chain in apps/api/src/lib/services/common.ts.

As far as I can see, there is no 330 line long if-else chain in that file. Nothing even close to it. Can you link to what you're talking about more specifically?

Looks really ...cool. When you say Netlify alternative, you're referring to commit-to-deploy functionality of static files only, not a global CDN and serverless functions, right?

Yes, I mean that you can easily deploy static sites. It does not have global CDN and serverless functions (yet), but you can easily set a CDN (like bunny.net) in front of your sites and then it will be globally CDN'd. I'm using similar setup all my marketing sites. It is deployed by Coolify to a server and Bunny CDN will make it globally available. So I do not need to care about any traffic bumps (like I have at the moment) and all my commits are deployed automatically.

When did it become acceptable for the official installation method to be running a random script on your server?

No one should be running that without personally verifying each line. What if I want to uninstall it? (I haven’t looked at this script) but many don’t effectively clean up properly after uninstalling, as that’s an afterthought.

What is specifically wrong with the dozens of existing packaging solutions we already have?

It became acceptable along with containers, so that the very OS the script is working on, is already isolated and disposable. You also mentioned dozens of packaging solutions. Which package manager should a single developer target first? Which package manager offers safety assurances enough that a customer wouldn't need to "personally verify each line" of the package manager's script?

> No one should be running that without personally verifying each line.

Ok, if you feel so strongly about it, then before you paste the link into your terminal and hit enter to execute it, how about you uh... open the shell script it will execute in your browser and read the contents of it?

You use this idea that people are executing stuff they don't know and blaming the tools for it but don't think to read the script yourself?

> Ok, if you feel so strongly about it, then before you paste the link into your terminal and hit enter to execute it, how about you uh... open the shell script it will execute in your browser and read the contents of it?

As an FYI - unless the script is on a site like GitHub (which you can assume to be behaving truthfully), it's possible for a server to respond differently according to the user agent, allowing a malicious file to be served if it's downloaded via `curl` or `wget`.

https://www.onsecurity.io/blog/careless-with-curl-dont-be/

As an FYI - The bash script downloads it and then runs bash on the file created on your local system, there's no way to determine if the user is downloading and piping directly into bash or if they're just downloading the file, so change the script before executing from

    wget -q https://get.coollabs.io/coolify/install.sh -O install.sh; sudo bash ./install.sh

to

    wget -q https://get.coollabs.io/coolify/install.sh -O install.sh; cat install.sh

Once the script is locally on your file system there is no way to change the contents.

Yep. My response was specific to your comment of reading in browser which is not a guarantee of what's downloaded.

My apologizes, I interpreted it as a "yeah but they can change it so you can't trust it!!!1!" response.

How is running an "random" script any different than running a "random" binary? With a script at least you CAN look at each line. With a binary you have no clue what the fuck it is doing.

Running random binaries is also a terrible idea. They should be packages that integrate with your local package manager, and which are signed by some entity that you've decided to trust.

and who would that be? Are you suggesting that you ONLY install software signed by developers you have personally verified the keys of? or that you know personally? Because if not, your argument is void because you're trusting completely unknown people who may actively be working to compromise your computer.

The fact that the software was signed doesn't mean anything if you don't actually verify each signature, and even then it only means that what they put up is what you downloaded. It doesn't mean it's not malware. It doesn't mean it doesn't have a back door. It doesn't mean it's not filled with security holes.

You don't need to know people personally to trust a signature, you just need to know that the organizations they're coming from are at least somewhat reputable. Ideally, signatures should all chain up to the root of trust in your package manager, which is presumably operated by some entity that you've decided to place some trust in.

> No one should be running that without personally verifying each line.

Do you also verify each line of software you install? If you trust the author of certain software, why do you mistrust their install script?

It's not only the original author, don't forget, but it's any malicious actor that's managed to compromise that hosted script.

It should be viewed in the same way that a package author on NPM or PyPI may publish a malicious package, either themselves or via their account being compromised. It's not particularly common, but nor is it impossible and could present a good targe.

> What is specifically wrong with the dozens of existing packaging solutions we already have?

specifically? Specifically: they are even WORSE from a security standpoint because you don't have the option of "personally verifying each line". Just because someone's stuck it in a nice easy-to-install package doesn't mean it's not a virus / malware / whatever.

are you suggesting that you read the source code of every app / tool you download before you execute it? If not, hello... pot. kettle?

Presumably for the same reason that ML models seem to self-download to god knows where instead of giving you a URL to a download link and telling you where to place the file?

Or those awful programs that give you a stub when you try to download the app, only to download the actual payload to, again, god-knows-where.

Or even worse, packaging your app in a docker container!

Seriously people, give a CURL-compatible URL to your actual payload and then get the hell out of the way

You shouldn't use internet either, is dangerous

Do you also verify each line of the software that the script is installing?

this is very very cool! one question - u deploy to individual servers right ? can u target deploy to a kubernetes platform. Like EKS? I couldnt find it in your docs.

Because one of the cool things about Heroku is scale-up. A cool project here is https://sst.dev/. Would love to see EKS/GKE native integration there.

Atm, only individual servers, but Coolify will be able to deploy to any Kubernetes platform soon, natively.

There are a couple self-hosting services that rely on k8s or k3s. For example, TrueNAS SCALE and Kubesail. Do you envision that Coolify could deploy on top of one of these, or does it need to own the full machine?

This looks really cool, I can't wait to try it out!

From what I saw, it looks like it does a lot of stuff behind the scenes relating to domains and SSL.. does it work with the server behind Cloudflare (the dashboard and hosted sites), or is this something I would probably want to be accessing directly?

Personally, I do not use Cloudflare, but Coolify works with it!

No Rails support? :(

Not “natively”, but as lots of people asking, I will add it soon. Try to fit in this week! :)

Sounds great!

I feel like Ruby on Rails out of the box support would really help bring an influx of Heroku orphans.

Any chance of swift server?

I'm open for anything but I never used Swift server before, so not sure if it could be integrated. I have to take a look.