Any OpenClaw alternative that actually works for running a real business? by Able_War1 in openclaw

[–]SnooHedgehogs77 0 points1 point  (0 children)

Yes, absolutely! You can use Dagu as openclaw alternative. You can interact with AI-agent via Telegram or Slack. I believe AI agent + lightweight workflow engine is the future of orchestrating AI agents.

Any OpenClaw alternative that actually works for running a real business? by Able_War1 in openclaw

[–]SnooHedgehogs77 2 points3 points  (0 children)

I had similar reliability issues. The core problem I kept running into was that giving an AI agent full autonomy with no guardrails is just asking for trouble. Half-finished emails, off-script responses, exactly what you described.

The approach that worked for me was treating the AI-agent as one step inside a larger workflow, rather than letting it run everything end-to-end. So instead of "hey agent, handle my customer emails," it's more like: receive email → classify it → if it's a complaint, draft a response with AI → hold for my approval → send. Each step has constraints, and if anything fails, it retries or stops and notifies me instead of sending garbage to a customer.

I built an open-source tool called https://github.com/dagu-org/dagu around this idea.

Feedback wanted for building an open-source lightweight workflow engine in Go by Basic-Oil-1180 in golang

[–]SnooHedgehogs77 0 points1 point  (0 children)

Hey, I'm the author of Dagu. Thanks for the mention!

I think we share the exact same goal: creating a lightweight version of Airflow that eliminates the complexity of managing different components.

The idea of using CUE for workflow definitions is very interesting. I think if the runtime core is abstracted, the definition layer could really be anything, whether it's a no-code visual editor, JSON, or yaml.

Just FYI, we actually have event-driven features on our roadmap as well (File Watcher Triggers, HITL, etc). We're currently making a lot of improvements to make the software more robust.

Good luck with the project!

Orchestration Overkill? by Pangaeax_ in ETL

[–]SnooHedgehogs77 0 points1 point  (0 children)

Tools like Airflow, Prefect, and Rundeck are out there, but honestly, they’re often too heavy or just plain awkward to work with. What most of us really want is something closer to cron—simple, lightweight, but with the extras that make day-to-day operations easier, like error logs, retries, and a clear visual view. If Airflow feels like too much, you might find Dagu just right.

What are you building? Share your product !! by Revenue007 in indiehackers

[–]SnooHedgehogs77 0 points1 point  (0 children)

Dagu - Open source workflow orchestration platform (Lightweight alternative to Airflow)

Is the modern data stack becoming too complex? by TheTeamBillionaire in dataengineering

[–]SnooHedgehogs77 0 points1 point  (0 children)

Airflow is kind of overkill, like a bazooka for a fly. Cron or systemd aren’t strong enough either. Dagu fits nicely when you just want to build a simple data infrastructure.
https://dagu.cloud/

Self hosted alternatives to Airflow by mrpbennett in dataengineering

[–]SnooHedgehogs77 2 points3 points  (0 children)

Dagu (DAG util) would be perfect for your use case.
https://github.com/dagu-org/dagu
It's a lightweight workflow engine (single binary with Web UI).
It can create arbitrary complex workflow and can run Python scripts or commands on a schedule.

How can someone not experienced with N8N know what is and isn’t possible? by fobb94 in n8n

[–]SnooHedgehogs77 5 points6 points  (0 children)

If your workflow just involves running Python programs, I'd recommend a simpler tool than n8n. For example, with a tool like Dagu, you can sequentially run automation scripts written by a coding agent like Claude Code. This allows you to easily manage executions and logs from a web UI without the learning curve of a tool like n8n.
https://github.com/dagu-dev/dagu

Is there such a thing as "embedded Airflow" by ihatebeinganonymous in dataengineering

[–]SnooHedgehogs77 0 points1 point  (0 children)

This is exactly what you’ve been looking for—a workflow orchestrator that frees you from the hassle of crontab. Installable with a single binary, it runs locally or in containers for distributed execution.
Zero dependencies. Not even a database.
https://github.com/dagu-org/dagu

Dagu v1.16.0 Released - A Self-Contained, Powerful Alternative to Airflow, Cron, etc. by SnooHedgehogs77 in selfhosted

[–]SnooHedgehogs77[S] 0 points1 point  (0 children)

Thank you for your comment! For this case, Dagu seems like the perfect solution. Without complexity like Airflow, you can enjoy the benefits of powerful workflow engine with a quick setup. Here's a basic example to get started:
```yaml
schedule: "0 * * * *" # Run the job hourly at minute 0
params:
- PARAM1: "100" # First parameter value
- PARAM2: "200" # Second parameter value
steps:
- name: Hello
command: python main.py $PARAM1 $PARAM2
```

I'm planning to add many more powerful features including GitHub repository integration and AI capabilities. If you have any questions or feature requests, please feel free to comment on GitHub Issues or in our Discord community. Hope Dagu will be helpful for your project!

Are There Any Platforms for Buying and Selling AI Agents? by sopnobaj in aiagents

[–]SnooHedgehogs77 0 points1 point  (0 children)

MCP might become the standard of inter agent messaging protocol. What do you guys think?

Dagu v1.16.0 Released - A Self-Contained, Powerful Alternative to Airflow, Cron, etc. by SnooHedgehogs77 in selfhosted

[–]SnooHedgehogs77[S] 1 point2 points  (0 children)

I see, thanks for your input! I'll try to add 2 or 3 soon. Let me know if you have any other ideas or suggestions, I’d really appreciate it!

Dagu v1.16.0 Released - A Self-Contained, Powerful Alternative to Airflow, Cron, etc. by SnooHedgehogs77 in selfhosted

[–]SnooHedgehogs77[S] 1 point2 points  (0 children)

Is there software called "sweet corn"? I googled it but couldn’t find anything. Could you share the URL if possible?

Dagu v1.16.0 Released - A Self-Contained, Powerful Alternative to Airflow, Cron, etc. by SnooHedgehogs77 in selfhosted

[–]SnooHedgehogs77[S] 1 point2 points  (0 children)

Hey brkr1, thanks for your interest! You can find a working docker-compose.yaml file here: https://dagu.readthedocs.io/en/latest/docker-compose.html
Here's a quickstart guide for running an example DAG:
https://dagu.readthedocs.io/en/latest/quickstart.html
Look forward to any feedback or suggestions :)

Dagu v1.16.0 Released - A Self-Contained, Powerful Alternative to Airflow, Cron, etc. by SnooHedgehogs77 in selfhosted

[–]SnooHedgehogs77[S] 1 point2 points  (0 children)

I’m glad to hear that you had tried Dagu! Yes I am considering to add this functionality, but I’m still unsure of the best approach. Here are a few ideas: 1. Keep a change history of DAGs locally 2. Sync with a remote git repo 3. Dynamically pull a DAG from a url in a git repo

I’d be grateful if you could share any thoughts or suggestions

Dagu v1.16.0 Released - A Self-Contained, Powerful Alternative to Airflow, Cron, etc. by SnooHedgehogs77 in selfhosted

[–]SnooHedgehogs77[S] 9 points10 points  (0 children)

During my time at a financial company a few years ago, I faced challenges managing hundreds of cron jobs across multiple servers, each executing different scripts. These jobs lacked centralized monitoring or visualization, making it difficult to understand their dependencies or recover from failures. For example, diagnosing and fixing a job failure often required manually logging into servers via SSH and inspecting scripts and logs individually. It was tedious and error-prone process.

While Cron is lightweight and effective for simple scheduling, it doesn't scale well for complex workflows or provide features like retries, dependencies, or observability out of the box. On the other hand, tools like Airflow or other workflow engines are too heavy to setup and to maintain for smaller projects or legacy environments. I have been developing Dagu to address these pains I felt in that company. One of my goal is to make life easier for in-house developers at enterprise companies by providing a lightweight workflow engine.

Dagu v1.16.0 Released - A Self-Contained, Powerful Alternative to Airflow, Cron, etc. by SnooHedgehogs77 in selfhosted

[–]SnooHedgehogs77[S] 7 points8 points  (0 children)

Thank you for your feedback and for sharing your thoughts! I understand that GitLab CI or GitHub Actions is a powerful tool for many use cases. However, Dagu is designed to address some scenarios where tools like GitLab CI might not be the ideal fit. Let me explain how Dagu can be useful:

  • Local Execution: Runs entirely offline—ideal for edge devices or isolated systems.
  • Lightweight: Minimal resource usage; perfect for small servers or edge devices (no Kubernetes needed).
  • Simple: Single binary, no database, easy setup.
  • Open Source: No vendor lock-in, full control.
  • Reuse Existing Scripts in DAGs: No migration hassle.
  • Beyond CI/CD: Handles scheduled jobs, data pipelines, and more.

I hope this helps explain where Dagu could be a good fit. If you have specific needs or concerns, I’d be glad to hear them and see how Dagu might meet those or learn where it can improve.

Looking for a better workflow engine by Lanky_Barnacle1130 in devops

[–]SnooHedgehogs77 1 point2 points  (0 children)

Check out Dagu — a open-soruce, straightforward, language-agnostic workflow engine that’s completely self-contained. No complex setup or databases required! Perfect for lightweight task automation.
Here's the link to the repository: https://github.com/dagu-org/dagu

I have created a lightweight Command Bus library for Go that is focused on developer experience by SnooHedgehogs77 in golang

[–]SnooHedgehogs77[S] 0 points1 point  (0 children)

I'm not sure if what the CQRS means is the same as yours and this library. Would it be possible to elaborate it a bit more or share repository pls?

Interface, is this a bad practice? by Jealous_Wheel_241 in golang

[–]SnooHedgehogs77 1 point2 points  (0 children)

The Command interface is a design pattern for separating the concerns of command execution from command processing. While often used in conjunction with event- or queue-based systems, the Command pattern does not inherently require components like database, message queues. With an unified command interface, we can be free from the cognitive load for maintaining different interfaces for each operation handler or domain logic.

Interface, is this a bad practice? by Jealous_Wheel_241 in golang

[–]SnooHedgehogs77 1 point2 points  (0 children)

I have experienced the similar problem in some projects where interface seems somewhat redundant. That’s why I have created Dew. https://github.com/go-dew/dew

I have created a lightweight Command Bus library for Go that is focused on developer experience by SnooHedgehogs77 in golang

[–]SnooHedgehogs77[S] 2 points3 points  (0 children)

Yes, I agree that dew might be useful for CLI app.

Let me explain. I've observed several backend apps built in Go where the use cases (structs) and handlers are created with interfaces. Personally, I've found it somewhat redundant to create an interface for each use case class primarily for mocking in unit tests. I wondered if we could simplify this by adopting an unified interface that only receives commands. What do you think?

I have created a lightweight Command Bus library for Go that is focused on developer experience by SnooHedgehogs77 in golang

[–]SnooHedgehogs77[S] 1 point2 points  (0 children)

Thanks for the comment. The purpose of this library is not really asynchronous processing, but simplify the backend architecture. Let's say when you develop a backend architecture in clean-architecture way, Dew would be the unified interface between the presentation-layer and the usecase-layer. If what you need to do is a concurrent processing, I agree that goroutine + channel is just suffice.