rubenfiszel

I do, thanks :)

https://windmill.dev: open source developer platform to turn scripts in Python, Typescript and go into endpoints, shareable internal apps, workflows and schedulable jobs.

Something was not clear to me from the README. When you do string interpolations as in your examples, those are actually prepared sql statements right ? Otherwise it would open the way for sql injections.

Very cool, I have lots of ideas of how to leverage it for windmill.dev. We were using psycopg2 for all our examples but this is much cleaner. Thanks for sharing!

Typescript (deno), Python and Go. Tbh the goal is really not to compete with AWS Lambda on performance as they use microvm with hot http servers, but to show that it's not order of magnitudes slower.

And VCs, but as much as I'd like it to not be the case, the US and the bay area in particular play at another level. The french ecosystem is getting really good at some forms of deep tech, but developer tools is not one of them, yet. The current government and station F have done wonders, we were 8 french startups at YC this year, the most populous of any other EU countries. Things are starting to change in the right direction and french engineers don't lack the drive and talent.

On the other hand, French people/VCs will wonder what can go wrong whereas in the US they look at what can go right. There are enough hurdles to face when trying to build a global tech companies as a solo founder and it can definitely make a difference.

Thanks! and let us know what you think, we are still rapidly iterating (to the point where the landing page and video is quite obsolete)

I would prefer the windmill.com domain but a cool windmill museum has it. I have not seen any downsides except Google (who owns the .tld) kept refusing to approve our oauth because the approval team was convinced that .dev could only be for testing.

Just want to add, I followed pretty much the same path with Windmill [1], which is also in the developer tool space, and also open-source. Built everything solo for 5 months. I thought it would be impossible to get into YC, it is not and I was fortunate enough to join YC on the latest batch, on my first try [2].

Getting into YC changed the course of the company, increased many orders of magnitude my ambition and made fundraising much easier. Most importantly, even though I worked in tech in the bay many moons ago, at the time I was very isolated in Paris and thought I understood the startup game but I did not really. Being part of a cohort like YC with like-minded amazing peers, truly felt like I was able to go up to speed on many subjects that would have been out of reach for a solo founder.

If you are a solo technical founder and considering applying to YC, reach out to me, I am more than happy to help.

[1]: https://windmill.dev

[2]: https://news.ycombinator.com/item?id=31272793

We are open-source so yes, that is the point that I am making. We offer a hosted version of Windmill and plugins but the core will live-on forever.

I do not know if your commented was targeted at Windmill or Airplane but our pricing is very clear and upfront. It's 10$/mo/user for the premium hosted version. You can read the code, use and self-host the product freely and without our blessing. The enterprise contract is a call us because that's how enterprise contracts work, they need complex agreement with various clauses.

Or you know, this little company called astronomer https://www.astronomer.io ...

Open-source does not mean we do not have a sustainable business model. We offer enterprise license for specific plugins and hosted solutions as well. The difference is that you can read our code, audit it and self-host the full platform with less frictions. Kafka and Airflow are also open-source but the commercial company backing them are thriving. Plus if we were to disappear, the project would continue to go forward.

To give them credits, Airplane was first. But we have very different ambitions imho. We have open-sourced our flow spec: https://openflow.dev and have a larger vision of becoming a standard for orchestration as established as Airflow or Temporal but simplified and principled, which is completely out-of-scope for a proprietary product.

It's AGPL. If you do not need any enterprise feature like SSO, you do not need to "call us", it's free. But if you fork it and re-expose it to users, you will need to make your fork open-source.

Our business model is that we are the only ones that can grant a commercial license because we hold the copyright and we provide plugins that only make sense at the enterprise scale such as SSO and exportable audit logs.

So in a sense, if you are an enterprise and need to pay us, what is the difference ? Well you can audit the code and experiment with it prior to deciding if you'd like to pursue with us, and not have to go through a salesy pitch to self-host and stress-test our orchestration runtime.

Congrats on the series B and very interesting approach with the Views.

Developer tools, especially ones around code should be open-source. If you like the idea of productionizing one-off scripts, building flows, and managing secrets and schedules in an integrated platform, we have made the same observation as the Airplane team but in a fully open-source manner: [1]. Being open-source in this space offers a lot of synergies, you can for instance build a community around sharing the modules that compose your flows: [2]

In addition, if your primary languages are Typescript, Python or Go, we offer a more integrated experience by parsing the script parameters directly to generate the input spec and the frontend. We are developing our own UI builder as well, more to be announced in the next month. We just released our helm-charts for easier self-hosted deployments: [4]

You can also try it for free at [5]

[1]: https://github.com/windmill-labs/windmill

[2]: https://hub.windmill.dev

[3]: https://windmill.dev

[4]: https://github.com/windmill-labs/windmill-helm-charts

[5]: https://app.windmill.dev

This is great, thank you for open-sourcing. One limitation is see with this model which is clearly stated in the post is that it is javascript/wasm and HTTP servers only. The deployable workers model is a great one and I had hoped to provide an adapter for the open-source windmill[1] project by transforming the normal scripts that are our units of execution into http servers runnable in workderd.

We support typescript (deno), go and python. Short of those languages becoming 100% transpilable to wasm, we will have to fallback to use firecracker or keep our current system implemented from scratch using nsjail for sandboxing and a fork for each process.

[1]: https://github.com/windmill-labs/windmill

Why would someone choose to work with anniversary dates instead calendar dates in the first place?

The downside on the accounting side looks real, as it’s easier to invoice all your customers at the same date (beginning of the month), instead of invoicing them granularly during a month. Imagine you want to refund a customer. If invoicing period is from 15 Sept. to 14

However, if your invoicing period is from 1st Sept. to 31st Sept., if a refund occured during this period, you make sure to calculate it during the same month. Easier for your finance guys.

At windmill (https://github.com/windmill-labs/windmill), our whole frontend is in svelte, we love it, the performance are second to none and the dev experience is great. But finding svelte dev is proving itself harder than I thought. So there is that issue as well.

Windmill (YC S22) https://windmill.dev | Founding SWE/DevOps | Rust/Svelte, K8S | Full-Time | Remote/Paris | $90-130k + $100k stock-options

Windmill is the sweet-spot between Retool and Temporal, it is fully open-source (https://github.com/windmill-labs/windmill) and has a hub (https://hub.windmill.dev) for sharing scripts and flows.

Apply here: https://www.ycombinator.com/companies/windmill/jobs

This is amazing. Long live open-source platforms that let developers and data scientist focus on the interesting parts of their jobs and day and make them more productive.

Looking forward to partner with you as our first no-code tool partner to wrap us!

Self-host: https://github.com/windmill-labs/windmill#how-to-self-host

Custom domain: not yet but for sure we will add it as an option for the teams plan

No plan yet but that's an interesting idea! We will do cloudflare workers and lambda first then move up the layers probably.

Thank you for the kind words!

Pricing is at the bottom of the landing page. Point taken, we should add the link directly to the menu bar.

Good catch for the back-button bug, we will fix it. Thanks!

Great question. The answer varies widely depending on the kind of company you are.

1. The biggest pain we solve is to turn scripts that you would run on your own laptop as internal apps that you can share. If your company make no use of script anywhere and does not need any automation then maybe it doesn't apply to you.

2. Avoid live sql queries in production and use templatized sql query made into apps instead (automatically!). Making live sql queries is common in DevOps, support and ops in general. It can be very error-prone, stressful and inconvenient.

3. Integrations between tools you already use but that are unable to talk to each other.

4. Workflows, code that runs very frequently to react to new events, transform data and run your business logic. Most companies are a frontend on a database that is updated in the background. We make it possible to build those workflows from simple scripts so that you can build it faster, more reliable and easier to maintain.

5. The last one only apply if you are a SaaS that want to provide automation as a feature of your product, or a no-code tools yourself. Because we focused very much on the hard-engineering of orchestration and specs for workflows, you might simply want to wrap Windmill to offer it to your own clients.

Yes. If you want to build from source, replace `image: ...` by `context: .` in https://github.com/windmill-labs/windmill/blob/main/docker-c... and docker-compose will rebuild from source.

If you just want to compile backend and frontend separately: `cd backend && cargo build` `cd frontend && npm install && run build`

We are working on that, it is non trivial because of the tight sandboxing but we will add it soon

Thank you! It is an immense honor and joy to be able to do both the exciting endeavor that is a startup, and being able to do it my way, open-source with great tech. I wake up every day excited to contribute to open-source software and could not imagine it otherwise now .