[HN Gopher] Show HN: Coolify v2 - Open-source and self-hostable ...
       ___________________________________________________________________
        
       Show HN: Coolify v2 - Open-source and self-hostable Heroku/Netlify
       alternative
        
       Author : andrasbacsai
       Score  : 125 points
       Date   : 2022-03-30 13:27 UTC (9 hours ago)
        
 (HTM) web link (coolify.io)
 (TXT) w3m dump (coolify.io)
        
       | dang wrote:
       | Related:
       | 
       |  _Show HN: An open-source, self-hostable Heroku and Netlify
       | alternative_ - https://news.ycombinator.com/item?id=26624341 -
       | March 2021 (116 comments)
        
       | andrasbacsai wrote:
       | 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-...
        
       | sharemywin wrote:
       | is there like a tutorial that walks though the process, step by
       | step, to get like a hello world project hosted some where?
        
         | andrasbacsai wrote:
         | Just added a video tutorial on the landing page.
         | https://coolify.io
        
       | stefanha wrote:
       | 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?
        
       | ibdf wrote:
       | Any hidden pricing page anywhere?
        
         | andrasbacsai wrote:
         | 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.
        
           | ibdf wrote:
           | 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.
        
       | josegonzalez wrote:
       | 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/
        
       | jdthedisciple wrote:
       | 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 ...
        
         | andrasbacsai wrote:
         | It's not supported atm. I've added an issue to support ASP.net.
         | 
         | https://github.com/coollabsio/coolify/issues/245
        
       | tomatowurst wrote:
       | 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.
        
         | andrasbacsai wrote:
         | Not yet. As Netlify (either Heroku) is huge compared to
         | Coolify, but I will keep working on it to fill the gap. :)
        
         | iskela wrote:
         | 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.
        
       | RadixDLT wrote:
       | does docker slowdown the server if you have too many images
       | running?
        
       | jszymborski wrote:
       | 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/
        
         | josegonzalez wrote:
         | 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/
        
           | jszymborski wrote:
           | 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
        
         | andrasbacsai wrote:
         | Not at the moment, but I will add support to work with Docker
         | Compose.
        
       | jaequery wrote:
       | This is so cool! For some of the one-off projects, it'd save a
       | fortune to not have to use AWS.
        
         | andrasbacsai wrote:
         | Thanks! :)
        
       | jaequery wrote:
       | 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!
        
         | andrasbacsai wrote:
         | Thanks!
         | 
         | Haha, yeah. I need to improve the UX part a bit! :)
        
       | mdasen wrote:
       | 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).
        
         | josegonzalez wrote:
         | 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/
        
         | nwsm wrote:
         | > 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
        
       | moondev wrote:
       | 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.
        
         | gigatexal wrote:
         | The above is why I won't try this. Thanks for posting,
         | avoiding.
        
           | matus_congrady wrote:
           | 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?
        
             | gigatexal wrote:
             | 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.
        
             | lmarcos wrote:
             | 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)
        
           | [deleted]
        
         | throwaway888abc wrote:
         | Appreciate your digging.
        
         | andrasbacsai wrote:
         | 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.
        
           | rhizome wrote:
           | 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.
        
           | 3np wrote:
           | 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)
        
       | RadixDLT wrote:
       | very cool, I recommend adding a loading icon when saving or
       | creating services, apps so I don't have to wait in silence
        
         | andrasbacsai wrote:
         | Thanks for the suggestion! I will improve the UX part!
        
       ___________________________________________________________________
       (page generated 2022-03-30 23:01 UTC)