Show HN: Coolify v2 – Open-source and self-hostable Heroku/Netlify alternative | Hacker News Reader

Show HN: Coolify v2 – Open-source and self-hostable Heroku/Netlify alternative

coolify.io

158 pointsandrasbacsai54 comments

Hey, HackerNews, Andras here!

Coolify started because I was just curious if I can make it work for myself. Then after the first release (v1) and after it went a bit viral here, I quickly realized people might like it!

Coolify's mission is to simplify the building and deployment process of your applications and to be free, open-source, self-hosted and hassle-free, so you only need to concentrate on the code, not the infrastructure. Also, you can quickly spin up databases and other open-source services with just a simple click.

In this way, everyone could shape the application! It is built with the community and backed by the community.

You may ask, how is it financially sustainable? It is not, at the moment, but it is backed by community and the actual users through OpenCollective. After it went viral on here, lots of VC reached out to me to invest and help to raise a fund. I said no to all of them. That is not the way I would like to grow this project.

Features:

- Fully automated update process. You get the latest updates every time a new version is published, you just need to click on a button. That's all.

- Integrated with your favorite GitHub, GitLab hosted and self-hosted instances.

- Automatically deploys pull/merge requests, so you can quickly review contributions and speed up your teamwork!

- You can deploy to Local Docker Engine.

- Automatically generates SSL certificates.

- Automatically configures a reverse proxy for everything deployed with Coolify.

- You can make teams. Each team can only view their own resources.

Future plans:

- Support Bitbucket and Gitea.

- Support Remote Docker Engine, so you can manage several servers from the same Coolify instance.

- Support Kubernetes, so you can scale to infinity and beyond!

- And more... I have lots of cool features on the table!

I love to hear your thoughts, so please, comment below.

PS: This is THE side project that caused me to leave a good paying job when the pandemic started. If you're interested in the full story, you can read it on my blog: https://blog.andrasbacsai.com/why-did-i-leave-my-stable-job-...

Can't immediately tell if this works for deploying with Docker Compose. It's my main sticking point with Dokku[0], which I've been finding quite pleasant to work with otherwise.

[0] https://dokku.com/

Not at the moment, but I will add support to work with Docker Compose.

Maintainer of Dokku here.

There are a few technical and philosophical reasons we don't support compose out of the box:

  - The build process does not lend itself well to a cleanup step. Since images are overwritten, users end up having old images lying around.
  - There is no zero-downtime scheduling for compose containers. You either replace them all at once - via `up` - and suffer the downtime, or namespace them by specifying a `--project-name` command arg and then doing some tricks when updating routing.
  - Many folks want docker-compose to specify the entire environment, including datastores. If you change the project name, compose links don't work anymore since you're essentially creating a new stack. If you use the same project name, we don't have any guarantees on where data lives, since many folks use volumes for that stuff (and volumes may not be backed by filesystems).
  - The compose yml format exposes lots of stuff that may not be desirable to expose on a shared instance in the name of security. For users that share a host with others in a semi-untrusted setup, I'd hate for their first step to be "disable the compose builder and scheduler plugins".

Note that you can deploy compose to ACI and ECS, both of which have a bunch of caveats around usage[1][2]. The only Kubernetes support I'm aware of for compose is Kompose[3], which transforms the file to something kubernetes is aware of for application.

I think overall the limitation around zero-downtime deploys in compose makes support in Dokku less interesting. We have support for basically everything you'd want otherwise. Our current alternative is to use dokkupose[4] to transform a compose file to the corresponding Dokku commands.

If folks are comfortable with the downtime and any other limitations, it might be nice to have a simple docker-compose plugin for building/scheduling, but I feel as though it wouldn't be worth it (maybe its just me).

  - [1] https://docs.docker.com/cloud/aci-compose-features/
  - [2] https://docs.docker.com/cloud/ecs-compose-features/
  - [3] https://kompose.io/
  - [4] https://dokkupose.netlify.app/

This makes a lot of sense, and I presupposed some of this reasoning, so it's great to hear that my understanding was correct.

Most of the frustration just comes from a lot of existing projects I'd like to simply deploy rely on docker-compose, so instead of just cloning and deploying, I need to adapt things. So really it's not exactly a frustration with Dokku :P

I thought about this a bit last night and did some research. I think with the evolved compose file format, this is more doable (though still with routing downtime until I do some extra work). I've filed a ticket for this here: https://github.com/dokku/dokku/issues/5102

Hello, big fan of dokku and your work.

Docker-compose was a limiting factor for me as well. I am seeing more and more projects that I deploy --- maybe 25 of the 50 I deploy a month -- using docker-compose.

I would love a simple docker-compose plugin, or a way to deploy with compose (I'd be okay if it gave a warning that 'may cause potential issues etc etc').

Do you have any resources on how to write plugins for dokku?

Again, I am extremely impressed by dokku and a big fan. I think a significant amount of your users would benefit from some way to use docker-compose. Would love to contribute.

Can't wait to see future releases!

Our plugin creation docs are here: https://dokku.com/docs/development/plugin-creation/

After going through the contents of https://get.coollabs.io/coolify/install.sh it seems to want to overwrite my docker daemon.json, then sets up a UUID for telemetry. I decided to just manually run the docker container (this should be clear in your README, please don't try to abstract away what this is doing behind a script)

After launch I was then greeted with a login/registration page. Seems kind of backwards to require this when you are targeting the self-host crowd. Too much friction to try this out.

Appreciate your digging.

The above is why I won't try this. Thanks for posting, avoiding.

Hello,

I have 2 questions:

1. Is the entire collection of telemetry data a problem, or just the fact that you can't opt out of it?

2. How would you like to be informed about the collection of telemetry data? (let's say for a CLI tool). I'm a founder at https://stacktape.com, and we're also collecting telemetry. We have a specific docs section on what/how we collect (https://docs.stacktape.com/user-guides/telemetry/), and how to opt out of it. We also have it stated in our privacy policy on our web. Is this enough? Or should we do something like print it to the terminal the first time you use the CLI?

No OP, but:

1) Telemetry that is ON by default is what I don't like. Not being able to opt out makes me uninstall/disable/unregister it.

2) I don't want to read documentation about a "feature" I couldn't care less about (i.e., telemetry)

Lmarcos below this is spot on.

How about not doing telemetry at all? Maybe surveys?

Anything that advertises itself for self hosting should do no telemetry. If I sign up for your cloud offering then fine but don’t spy on me and my hardware and my use cases.

Yeah, it is clear based on the script that it sets up an UUID just to show how many instances are used (see the landing page). But you are right, I add a state why it is used.

About the registration, I do not understand it. Ofc, you need to register to your own instance, otherwise how you could use it, especially as a team? Each team member needs to register.

You're in Hungary, right? I do think that like any EU country, you need explicit informed consent to gather analytics like that, and offer a way to opt out (for example via setting an env var)

Thanks for the suggestion!

Yes, I'm from Hungary. I will add an opt-out feature, but I do not think it is an analytics thing. It is used to count installed instances on the frontpage. That's all.

You most likely process PII (IP address) that is not strictly required to run the service by doing so. There is clear precedence in the GDPR for this. Doesn't matter if you call it analytics or not.

I simply don't think the number of installs is a compelling piece of information, not the least because it is gamed everywhere. To me it says one of two things: "someone installed it," or "developer spun up a zillion micro instances to juke the stats." Nothing personal, it's the reputation of the data itself.

Maybe show a warning that the install script enables telemetry by default and implement https://consoledonottrack.com/. Users who do not wish to participate in telemetry can set the DO_NOT_TRACK=1 environment variable before running the script.

Nice! Thanks for the suggestion! I will implement this!

Hi, trying this out but I'm getting "503 Service unavailable error" static HTML page Git repo I just added for testing.

* Nevermind figured it out, I had to hit "Play" button up top to actually build. :)

This is amazing, it auto-picks up Next.js and even Nest.js!

Thanks!

Haha, yeah. I need to improve the UX part a bit! :)

How does it compare to https://www.cloudron.io or https://caprover.com/ ?

im really loving this "self-host" movement. So far I've discovered on github:

- self-hosted dynamodb api compatible db

- self-hosted S3 api compatible project

- self-hosted AWS serverless project

does coolify include all of the nuts and bolts, like Netlify functions?

My plan is to purchase dedicated servers from Hetzner (open to other suggestions) , harden it (also open to suggestions here), and run these self-hosted BYOC (be your own cloud) solutions.

The dream setup would be something that takes away the complexity of AWS IAM roles & permissions, easy configuration of self-hosted AWS API compatible storage, serverless, queue, streaming etc.

Not yet. As Netlify (either Heroku) is huge compared to Coolify, but I will keep working on it to fill the gap. :)

Atleast under the coolios services tab there was the minio-service that has aws-s3 compatible blob filestorage api and a nice web-app ui. One could host the minio directly with docker too.

Just checking out the repo, is there a summary of whats new in V2? Recent releases have release notes, but the 2.0.0[1] didn't.

The phrase "build pack" is a bit loaded in the container space - currently that can refer to either Heroku's Buildpacks (v2a), Cloudfoundry's Buildpacks (v2b), or the new Cloud Native Buildpack[2] initiative (v3). Might be good to rename your feature there (or maybe integrate with CNB?) to reduce any confusion.

What do you use for your routing? Seems like haproxy (with some custom generated config), which I think is a great option, though maybe less so for configurability.

Overall seems pretty neat. Might be good to add screenshots of functionality to your docs to make it clearer what is supported/what isn't.

  - [1] https://github.com/coollabsio/coolify/releases/tag/v2.0.0
  - [2] https://buildpacks.io/

Show HN: An open-source, self-hostable Heroku and Netlify alternative - https://news.ycombinator.com/item?id=26624341 - March 2021 (116 comments)

Yeah, that was the MVP (v1). :)

This looks very cool for quickly running your own apps without configuring a server yourself!

Does Coolify also host your git repository? I noticed that Gitea is listed as work-in-progress, so maybe there will be not just a Gitea Source but also a Service so you can self-host your own git repos too?

Any thoughts on community-contributed buildpacks, databases, and services? At the moment they seem to be hardcoded into the web app. I guess contributors could send a pull request to get them merged into Coolify?

Thanks, Stefanha!

It is not supported at the moment, but as any service could be added which can be hosted by Docker, it is possible to have a one-click git repository. :)

Regarding the buildpacks, I will add more general buildpacks (Heroku's Buildpacks (v2a), Cloudfoundry's Buildpacks (v2b), or the new Cloud Native Buildpack[2], initiative (v3)) like a commenter mentioned here: https://news.ycombinator.com/item?id=30858538.

I'm fully open for contributors!

is there like a tutorial that walks though the process, step by step, to get like a hello world project hosted some where?

Just added a video tutorial on the landing page. https://coolify.io

i chuckled at seeing SSH “root” login.

might be a thing for web-developers to do but it is deeply frowned upon by the cybersecurity community.

What is the extra danger of "root" if there is only one user/application on that system?

This is so cool! For some of the one-off projects, it'd save a fortune to not have to use AWS.

Thanks! :)

IaaS, local-Docker-only so far; looks very very promising.

worried about other back-end things namely configurability of some and missing things like full-suite SMTP set.

But I like the ability to self-host your front-end development team.

I love these projects and I'll definitely look into it more later. At the same time, I think it would be hard for me to want to leave Kubernetes. K8s isn't something that I love, but it's something that I know works and will continue to be supported in some fashion. I've seen Flynn (https://github.com/flynn/flynn) EOL. I've seen Docker Swarm's future be a bit hazy. I've seen Porter decide to put pretty restrictive limits on their free tier (though it is open source). I've seen Dokku lose steam and then pick up again - but still not be a solution for more than one server.

I love the idea of something that will Just Work, but a lot of stuff doesn't handle the parts I care about the most. Will my one-click PostgreSQL have a couple replicas in my cluster? Will it launch pg-backrest so I can have it backed up to S3? Will it deal with secret storage so I can just add my secrets in the UI and then have my apps grab those secrets as environment vars? Will it fail-over nicely?

Coolify looks really cool and I do want to check it out for real later (probably over the weekend to be realistic). However, it seems like it's single-server (for now) and that seems less compelling for me at the moment. It looks like you're planning on K8s support which would just be wonderful.

Part of me wishes I could get a much simplified UI for K8s. I use Lens at the moment and while it's very good, it doesn't really smooth over the rough bits of K8s, just kinda organizes and presents them. K8s isn't as bad as a lot of people say once you get past the pain of learning. Still, it misses the mark if what you just want a few simple things Heroku-style instead of every bell and whistle. Small users don't care about ingress, they just want their app to be accessible. Small users aren't interested in namespaces or storage classes or roles. Sure, it's important for K8s to support storage classes for large users who might have all sorts of opinions on how they want their data stored. For a small user, you often just want it stored on the local disk.

Likewise, I think there's a reasonably small set of things people often want to run. For example, the databases Coolify supports (MongoDB, MySQL, PostgreSQL, CouchDB, RedisDB) are probably what 95% of people want. There are K8s operators to run them, but like K8s itself it can often be "here's every knob we could think of, we documented 80% of them, now go write some yaml." Heroku lets me deploy PostgreSQL without that. Why can't I get something a bit more slimmed down like Heroku on K8s - so that if I need the additional power in the future, I can get my hands on it.

I'd even love it if this hypothetical K8s Heroku could commit the yaml it is going to apply to a GitHub repository for me so I can easily track infrastructure changes. It would even let people become more comfortable with K8s as they saw the changes they were making in the UI show up as commits in a repository.

I think the point of this rambling is that Coolify is kinda what people want from one perspective - something that seems nice and friendly and handle the cases that the vast majority of people need solved. However, it lacks the critical mass of K8s which can always leave its future in doubt (it looks like there are two of you on this project and open source can take a toll on people) and without high-availability/multi-server it feels a bit lacking for what so many people are looking for in a self-hosted Heroku. Coolify feels like what I'm looking for - I just want it with high-availability and the possibility of continuing on even if the project shuts down (because I can just use an underlying K8s layer, not because it's open source and I could become the new maintainer).

It feels like there's two camps that don't talk to each other: awesome UX people who know what people want and people building solutions that companies want while scaling up (but end up with a bit of a UX mess).

> However, it seems like it's single-server (for now) and that seems less compelling for me at the moment. It looks like you're planning on K8s support which would just be wonderful.

Isn't this where Knative should come in? Kubernetes under the hood but simpler abstractions on top

Dokku maintainer here.

Dokku is still chugging along, and has 3-4 big releases a year, with patch releases every so often. We also have partial support for Kubernetes and Nomad, and our Kubernetes integration in particular is in use in a variety of Fortune 500 companies. Some folks are interested in Swarm support[1] as well. I also recently released a "pro" version[2] for folks that want/need extra functionality that doesn't quite make sense for the typical "I have a single server and its just me using it" situation

All that said, we're here to stay, and I don't think we're losing any steam :)

  - [1] https://github.com/dokku/dokku/issues/4486
  - [2] https://pro.dokku.com/

Dokku is amazing. Thank you for all your work. I have this sense of magic when I use.

Thank you for the detailed review/opinion! I love it!

My vision is kinda similar to yours. I would like to simplify things as much as possible and make most things behind a single button. :)

I do not want to only cover the single server solution. It will cover K8s and Remote Docker Engine as well.

With K8s, you can definitely scale to the sky, Coolify will be just to simplify the building and deployment part. It will be a huge feature, but I love K8s, so it will come soon. I'm sure it won't cover everything in the initial release. I love to work in small iterations and iterate often.

But before K8s, I will integrate Remote Docker Engine. That will make a single Coolify instance to manage several servers and even loadbalance services between those servers. So it will offer a simple HA/DR solution.

About the project shut down, I do not think it will happen soon. I have a daytime job, so I'm not doing for the money. I'm doing for fun! Coding is fun! It's simple. :)

Also, I will improve the contribution guides as well, so it won't rely only on me.

very cool, I recommend adding a loading icon when saving or creating services, apps so I don't have to wait in silence

Thanks for the suggestion! I will improve the UX part!

ASP.NET not supported? Been looking for a way to self-host my asp app.net based app ... guess Imma go cry in the corner ...

It's not supported atm. I've added an issue to support ASP.net.

https://github.com/coollabsio/coolify/issues/245

Any hidden pricing page anywhere?

No. It’s backed by the community on opencollective, or at least will be someday.

I have a daytime job, so I’m not doing it for the money.

Well that's awesome. I was asking because so many services now tell me about pricing after I create an account. I run a tiny non-profit so I always go for free tiers or almost free services. Websites that don't tell me pricing ahead of time I don't even bother to try.

Coolify is free and always will be.

does docker slowdown the server if you have too many images running?

It depends on the server performance. The demo instance, currently running 130 applications/services/databases, and I see no performance degradation. It is only a simple VPS from Hetzner.

When the Remote Docker Engine and K8s support come out, performance won't be a problem, that's sure.

Reply on news.ycombinator.com