Really excited to see this. Airflow always felt like too much software for my simple self-hosting needs.
rengler33
marciok
Hi! Yes, I’ve checked durable, both parse and run durable workflows. However, Gust has some key differences:
- Is UI centric: Dashboard with graphs, errors, logs, code, and other things like editing secrets and runs.
- It’s not a proof of concept; I am using on production, multiple nodes, and it has a good amount of test coverage.
Overall, they’re alternative approaches to the same problem. 
4
ghannam80
Hi,
I saw it had live log update in the UI but I wonder if it track the log per run as this might be important for audit purposes ?
0
marciok
Hi there, sorry for the wait!
Yes, it tracks the logs per run and attempts! You can see here, there’s a log level, attempt (a run can have many tries), and its content: https://camo.githubusercontent.com/cf1111c6e13cd7d71ac7ac6ec31e115a648b5da12ec0da18110946f01a6423ee/68747470733a2f2f677573742d6769746875622e73332e75732d656173742d312e616d617a6f6e6177732e636f6d2f677573742d73732d322e706e67
0
marciok
Hi there!
There’s a major update on the project: It now supports DAGs in Python!
Since the start of this project, I’ve always wanted to bring over some of my legacy Python DAGs without having to rewrite them. Also, it’s a great way for people outside the Elixir community to experience the power of OTP without needing to adopt a new language
Enjoy!
1
marciok
Hi, it’s me again!
Announcing MCP Server + SKILLS to ease DAG management with AI
Check it out:
https://github.com/marciok/gust?tab=readme-ov-file#mcp-server
1
saleyn
@marciok, is there a way to execute tasks on a pool of worker nodes? Alternatively, Airflow allows to spin K8s pods on demand for a job. I wonder if the same approach can be used with Gust. E.g.:
from datetime import datetime
from airflow import DAG
from airflow.providers.cncf.kubernetes.operators.pod import KubernetesPodOperator
with DAG(
dag_id="ondemand_pod_example",
start_date=datetime(2026, 1, 1),
schedule=None,
catchup=False,
) as dag:
run_script_in_pod = KubernetesPodOperator(
task_id="run_custom_image",
name="airflow-dynamic-pod",
namespace="airflow",
image="python:3.11-slim",
cmds=["python", "-c"],
arguments=["print('Hello from an on-demand pod!')"],
get_logs=True,
is_delete_operator_pod=True, # Automatically deletes the pod when done
)
0
marciok
Hi! Thanks for your question.
For some context: Gust workers pool claims the whole run and executes its tasks by spinning up dynamic processes for each of them. Once the task is over, the processes are stopped (the run is finished).
If you need, for example, a run to be performed on a specific worker, let’s say that is on a GPU-enabled node. This could be easily implemented by changing the run claimer code to enable specific rules, ex: “claim only runs where GPU=true”
Overall, it can be done per DAG run, not for a specific task. If you really need per task, one could do it like Airflow and call the K8s API within Gust’s task body.
Could you elaborate more on what is the use case that you’re thinking of? I’d love to help.
Best!
0
saleyn
Please forgive my ignorance if I missed this in the docs, but I couldn’t find the relevant details on if the DUG or the tasks within can run not on the same node that is running Gust but on different ones, customizing the resources given. E.g. for ML-related tasks to chose nodes that have GPUs; for some data scraping jobs to pick nodes that have local storage with relevant data, etc. Is this doable?
Also if there are many DAGs is it possible to balance their execution by scaling Gust horizontally?
If you could expand the documentation with these examples, it would be super helpful.
1
marciok
No worries! Yep, it’s missing more in-depth detail on how Gust works internally; I’ll include it in the docs.
Regarding the feature to specify what type of worker the DAG should run on, I opened an issue, and I’m planning to add into the next release: Route DAG runs to nodes by capability · Issue #139 · marciok/gust · GitHub.
Feel free to leave any comments!
Best!
0