is it concierto or conciertio? 🙂

concierto is name of the project but it's a popular name so went for http://conciert.io domain and hence conciertio for uniqueness on github - maybe i should just switch it all to conciertio to avoid confusion and be done with it.

Interesting. I just looked at https://kamal-deploy.org/ while riding the train earlier today. Seems to be vaguely similar in it's intention?

if you have a look at my "demo lxd" extension, i think that gives an idea of just how useful the extensions could be - a formalised version of that extension where multi tier app can be fully simulated locally by specifying the cloud-init file and OS to use.

another extension area is doing more statically than you may do otherwise - due to the fact services are sub-repos. For example, http://e.gi have an extension I'm playing with that creates a an api router (nginx proxy) container over multiple services, by simply having a "router_locations" file in each service directory which wants to participate in the api - that removes dynamic tools like traefik - that is, an nginx proxy container is deployed with static paths to all participating containers

Lots of interesting work to unpack in concierto. Is there somewhere for a follow-up discussions?

I added discussions on github, https://github.com/conciertio/concierto/discussions. Also, there are some videos here https://www.conciert.io/starter.html which I hope shed light. If there is a specific area i can address via a video let me know.

This looks really cool! I have been idly dreaming about a Babashka-driven infra manager for some time 😁