I have a small open-source project, that uses docker compose behind the scenes, to help startup any service. You can look to add it in (or I am also happy to add it in) and then users are one command away from running it (insta moose). Recently just added in lakekeeper and various data annotation tools.

insta-infra: https://github.com/data-catering/insta-infra

Actually, this https://github.com/514-labs/moose

I thought of https://moosetechnology.org/ and wondered why I'd need all that fancy other stuff?

Maybe this is the greybeard in me, but I first thought about https://metacpan.org/pod/Moose, and catalyst (http://catalyst.perl.org/)

Hi!

We are built on top of them. Right now the techs above are what’s backing the implementation but we want to add different compatibilities. So that you can eventually have for example airflow backing up your orchestration instead of temporal.

You can think of moose as the pre-built glue between those components with the equivalent UX of a web framework (ie you get hit reloading, instant feedback, etc…)

Not sure if this is what you are asking about, so if I misread feel free to correct me. You don’t have to install moose first on the deployment machine, in the tutorial I go through that to generate a dummy moose application to be deployed.

It is the same idea as a nextjs application you deploy through docker, you have your application and then you build your docker container that contains your code, then you can deploy that.

I tried to limit the port bindings, we usually expose moose itself since one of the use case is collecting data for product analytics from a web front end, which pushes data to moose. And then usually people want to expose rest apis on top of the data they have collected. The clickhouse ports could be fully closed, this was an example of if you want to connect PowerBook to it