https://gist.github.com/NatElkins/20880368b797470f3bc6926e35...
The world is made much better by safer defaults, but they also lead to a degree of complacency.
I hope not, because I lack enough foul language to describe my burning hatred for Ignition and all its cutesy campfire-related project codenames. Hate-red.
This got me to wondering when I first heard about HTML, HTTP, Linux, UTF-8, or any number of things, and from where, how so many of the things I've heard of once and never again, and the many important "standard" things I've never heard of.
Something also has to be said for simplicity and redundant choices. For example replacing systemd-timesyncd with chrony is not justified. And some of the recommended sysctl values may be redundant and already the default in the target OS.
hire a professional to secure your shit.
You have to setup docker compose files with airo it looks like in any case, so this just simplifies the caddy part? But caddy is so simple to begin with I'm not sure the point..
Seems like something that could have been solved with just docker compose (by setting a remote DOCKER_HOST). If you need “automatic” proxying, then traefik can do it off container labels.
This looks extremely barebones and makes a large number of assumptions in its current state. This is better as a Show HN after some more dev work has been completed.
Maybe I should try to Show HN my Docker dashboard, https://lunni.dev/ :thinking:
The ability to spin up services is crazy good and easy. I was able to evaluate n8n, windmill.dev and prefect in 3 hours because I was able to quickly setup these clusters and test them. And final thing was to compile my code as docker container and spin it up on coolify within mins with custom domain and ssl.
How is it different and eaiser than coolify kinda setup?
Compared to simply docker compose isolated in a vm/lxc container it was not a particularly better experience.
I also wanted to use cloudflare tunnels instead of exposing the server on the internet and it seems coolify really prefers to work directly on the internet (lacking reverse proxy doc, ...)
I’m now using Dokku and can’t imagine using something else.
Would love to hear your thoughts if you give it a try!
Before I started Lunni, I was using Portainer myself, but it got too painful. Here are some paper cuts I’m trying to solve with Lunni:
- I only manage one cluster (of one server), but I still had to select endpoint every time. In Lunni, the first thing you see when you log in is the status of your stacks/projects
- I use Traefik with routing config living in service labels. It’s a huge snippet, impossible to remember, which I had to copy from project to project. In Lunni it’s autocompleted for you: https://lunni.dev/docs/deploy/#:~:text=This%20is%20quite%20l...
- When you look at the service logs in Portainer, they refresh once in a while and throw away your scroll position, which is super frustrating. In Lunni, it works as you’d expect. As a bonus, you can copy a link to a log line (e.g. if you want to share it with somebody or just bookmark it)
- If you need to create a Docker config or secret for a stack in Portainer, you have to go to another dashboard section, make a config yourself, then copy the name to your stack. In Lunni, you can do that right on the New project page: https://lunni.dev/docs/configs-secrets/
- ...and a lot of other things like error messages that don’t disappear in 5 seconds, before you’ve had a chance to read them
Basically, I’m trying to make a Portainer that is a pleasure to use. Maybe it’s not as close to Coolify as I thought, but I’m trying to maintain a more PaaSy feel than Portainer. Some things you’d expect from a PaaS, like a built in CI and automated DB/volume backups, are also on the roadmap!
Overall, I like it but I wish it was a bit more polished.
It has some unique features like supporting OAuth authentication for the apps, staging env for each app (code and config changes are staged before deployment), supporting declarative update, supporting hypermedia based apps natively etc.
I’m also working on a deployment tool, though not nearly as ambitious – it’s just a Docker dashboard based around Compose files: https://lunni.dev/ (though it does everything Traefik does, and GitOps are also definitely on the roadmap)
The Hypermedia based app support was added to be able to build a management dashboard for Clace itself, without going down the SPA route. It made sense to expose that for end uses to be able to build their own apps.
I mean, what if you needed to change the way it worked? With bash you'd have to open a text editor, change a line, and save the file! And on top of that you need to understand shell scripting!
With Go, you can set up your development environment, edit the source code, run the compiler, download the external dependencies, generate a new binary, and copy it to your server. And all this requires is learning the Go language and its development model. This is clearly more advanced, and thus better.
And I assume you want to be building once to test your changes anyways, so you really only need to push.
Long scripts suck in Makefile, but can call external scripts for anything big.
#!/usr/bin/env bash
export DOCKER_HOST="ssh://username@host:port"
docker compose up -d --build