windmill-gh-action-deploy VS windmill

> Ability to store everything in code that you control. In Airplane, we have a CLI that lets you deploy scripts from your own machine to Airplane. You can version control the script code as well as the metadata (name, parameters, validation rules, etc). In Windmill you have to create everything in their UI as far as I can tell. Airplane's approach is more developer-friendly and also allows you to reference other code in your codebase if you want.

https://github.com/windmill-labs/windmill-gh-action-deploy Which is basically just sending a tar of your repo to sync it so you do not have to centralize your code on Windmill if you do not have to.

What about the features you do not provide, like a fully-featured web editor with lsp in the backend for smart assistant. The ability to convert script parameters to UI directly and so on.

> * Third-party integrations (Sendgrid, Slack, etc). I only saw Slack in your docs.

This is disingenuous, we provide integrations for anything that has OAuth https://docs.windmill.dev/docs/contributors_guide#add-an-oau... by just needing to append the oauth informations to this file: https://github.com/windmill-labs/windmill/blob/main/backend/.... We have a hub for people to provide the no-code module part out of it. We expect this ways to have thousands of integrations by the end of this quarter when you will only have a dozen.

You have an amazing product but being open-source is not our sole differentiator, we want to build an even better amazing product.

Yes you can, and you should! The included versioning is there for simplicity if you do not want the hassle to maintain your own git repo. But the real git will always be more powerful.

There is a github action to automatically deploy from github to windmill: https://github.com/windmill-labs/windmill-gh-action-deploy

That gh action is what I do for the public templates that hydrate every workspace on:

https://github.com/windmill-labs/windmill

Fun fact, the way it works is that it just tarball a subdir of your repo and send it as an input of a normal windmill script that then just extract it to your workspace (for all the diffs that it finds).

Data Handling: Utilizes Windmill for data pipelines, with a primary database powered by PostgreSQL. Auxiliary data storage is handled by MongoDB, with Redis for caching to optimize performance

Look very similar to the script builder portion of https://github.com/windmill-labs/windmill, but not open-source, not self-hostable, and without open-source integrations (https://hub.windmill.dev/)

disclaimer: I'm founder of ^

If you need a job queue on Postgres, https://windmill.dev provide an all-integrated developer platform with a Pg queue at its core that support jobs defined in python/typescript/sql

windmill.dev - Windmill is an open-source developer platform to quickly build production-grade multi-step automation and internal apps from minimal Python and Typescript scripts. As a free user, you can create and be a member of at most three non-premium workspaces.

For an alternative to airplane.dev, you can checkout Windmill.

https://github.com/windmill-labs/windmill

"Open-source developer infrastructure for internal tools (APIs, background jobs, workflows and UIs). Self-hostable alternative to Airplane, Pipedream, Superblocks and a simplified Temporal with autogenerated UIsm and custom UIs to trigger workflows and scripts as internal apps.

Scripts are turned into sharable UIs automatically, and can be composed together into flows or used into richer apps built with low-code. Supported script languages supported are: Python, TypeScript, Go, Bash, SQL, and GraphQL. "

If you search HN, you'll find the creator of Windmill comment on comparisons to airplane.dev:

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

https://windmill.dev is a self-hostable OSS alternative to pipedream

(disclaimer: I'm founder)

I'm genuinely curious what server-side stuff on BC you are referring to. That may have been something added after our assessment. The way I'd generally approach something like that for any of the platforms would be using an external low/no code solution to process webhook data. But it would depend heavily on the use case. For a more developer friendly option I've been really impressed by windmill.dev. We use a mix of n8n and windmill for various needs.

Yes it goes in that direction, however note that you can already do this in a not too hard way.

Our openflow spec is both open-source and has a full openapi definition: https://github.com/windmill-labs/windmill/blob/main/openflow...

you can use that to generate client sdks in any languages and build your own dag with it. That's what one of our customer did building a reactflow to openflow library: https://github.com/Devessier/reactflow-to-windmill

It's not as good as the decorator way but we move fast and if you still have interest for it we could prioritize it (and ask for feedbacks :))