Let It Grind on Its Own: Windmill.dev and a Mill of Your Own for the Digital Daily Grind

Who I’m writing about Windmill for

Before I get into anything else, I want to save you some time, because this is not for everyone.

You don’t need to be a programmer (especially not these days), but it helps if you work in a field where you deal heavily with digitally represented information and you’d like to see things smoothly automated.

This is for you if you’ve ever written (or had someone write) a script that does something - downloads data, renames files, sends a notification, whatever - and then you looked at it and thought: great, so now what?

It’s for you if you work in an organisation where things get done by hand, or in convoluted and opaque ways, even though they could surely be automated and made clearer with little effort - because nobody has the capacity or the will to set it up or fix it.

It’s for you if you’re into self-hosting - whether you’ve got a NAS full of films at home, Unraid and an ‘array’ of drives on an old ThinkPad labelled ‘do not switch off’ on the top shelf of the storage closet, or a VPS for five euros a month - or even an ‘organic’ combination of all of the above.

It’s for you if you have sensors measuring things at home, at the cottage or in the garden - temperature, soil moisture, power consumption, solar panels - and you’d like those numbers to finally amount to something: for the watering to kick in when it’s dry and hasn’t rained, for a message to reach you when the temperature in the freezer starts climbing, or for your smart home to get along even with services the maker of your little box has never heard of.

It’s for you if you’ve had a small web app built - an internal dashboard, a form, an order overview, whatever - and now you’re wondering where to deploy it / how to host it, and why one page with a table, which was done in an afternoon, means spending weeks setting up Vercel, a domain and a CI/CD pipeline.

It’s for you if you’ve started vibe-coding your own tools - because you’ve discovered that suddenly it’s possible, and that the feeling when something finally works exactly the way you imagined is pretty addictive.

And of course it’s for you if you’re a programmer - especially if you’ve got API keys to five different services stored in a .env file that you hope you’ll never accidentally commit.

If you’ve read this far and don’t recognise yourself in any of it - wow, maybe do read on anyway, because it clearly draws you in and it’ll be an enriching experience. Or don’t - the world is full of great articles about other things. I’d recommend anything Michael Levin has a hand in, for instance - a biologist and former IT guy who explores a wide range of things - like what intelligence actually means, what an incursion from invisible dimensions into our world might look like, or how cells communicate and organise themselves into more complex wholes. He can talk about it in a way that fascinates even people who normally find biology super boring. That’s exactly how I’d like to write about automation - because at its core it’s a similar thing: how simple parts, each doing its own thing in its own quirky way, come together into something that holds up and works as a whole.

A path you can’t skip

Now I’ll describe a sequence of experiences that, in some form, everyone goes through when trying to get a computer to do something automatically.

Milestone 1: “It works!”

You write a script. Or these days Claude easily writes it for you. Or you ‘just’ took a ready-made tool, a library, a service with an API, and hooked it up to something else. Or you have a tiny app built: a page that shows an overview. A form that saves data somewhere. A dashboard that shows what’s going on. What matters is that you got a computer to do something useful that you’d otherwise have to spend your own time on.

Maybe it ‘just’ downloads exchange rates. Maybe it’s ‘just’ a shopping list for the family. Maybe it ‘just’ renames photos by the date they were taken - but it does it by itself and you feel like you’ve just discovered fire.

It’s a radiant moment. As if the fog has lifted and the landscape of possibilities has revealed itself all the way to the horizon.

Milestone 2: “And now I run it… myself, again?”

The euphoria gradually fades - often helped along by the weight of realising that the script won’t take care of itself. Sure, you don’t have to open a terminal every time you want to use it, go to the right folder, remember how you actually set it up and why, and hit Enter - you don’t, because of course you’ll set it up so it’s easier to reach. But it’s death by a thousand cuts.

And that’s only the beginning. Because then there are the inevitable new versions. Sooner or later someone changes an API and you have to fix the script. Or you write a second script, and a third. Then a small web app that drives those scripts - but suddenly you’ve got five things, each needing its own maintenance, each with its own dependencies, each running somewhere else in some other way, and while you learned something on each of them, you’re the only person in the world who has any idea how the whole thing holds together (and even that only roughly and, above all, temporarily) - and that’s heavy.

By the way - it wouldn’t be surprising if all of this depended on your device. Close the laptop, the script stops. Lose the laptop, tough luck (no, I know, of course you have backups). Which is a somewhat undesirable state of affairs, given that this was supposed to be automation that frees up your capacity for more interesting things.

None of this matters all that much when you’re just playing around or need something once in a while. But as soon as something’s at stake, as soon as it’s meant to happen regularly or someone else has to deal with it too, you realise that with your shining de-facto-programmer triumph you’ve just solved the more interesting but less pressing problem; the more boring yet far more lasting problem - “how do I keep this working” - is only just surfacing.

Milestone 3: “It’ll just keep running somewhere”

So you set up a cronjob. Or a systemd timer. Or Windows Task Scheduler, if you have that particular form of masochism or a fixed idea that things would be too complicated under Linux. Or you simply decide you’ll run it through GitHub Actions, because it’s ‘free’ there.

And it works - the script runs, you don’t have to do a thing. This is true automation. This is the future. The fire is burning steadily.

Until it stops working.

Milestone 4: “Wait, how long has this been broken?!”

Whether you’ve got the previous milestones nicely integrated or you’re still wrestling with something, the world waits for no one and this cold shower inevitably arrives: your tool has failed silently - maybe the API changed, maybe a token expired, maybe you just no longer have any idea what it’s supposed to do.

Maybe you have logs, but no notifications. Maybe something slipped through the settings. Maybe you don’t even have a way to find out exactly when it stopped working and why. Either way, a feeling is inevitably fermenting in you that automation, and the whole of digitalisation for that matter, is a scam and a pyramid scheme, that all it does is create a lot more work with everything, which by its very nature can never lead to anything being solved once and for all, and that we just keep getting more tangled up in it.

But emotions pass with time, and the usefulness of the digital is undeniable.

Milestone 5: “I need… a system”

And this is where something important happens. This is the moment when you have a chance to stop dealing with individual scripts and start genuinely thinking about infrastructure. Not as something annoying, or something that would be nice to have, but who has the time and capacity for that. But as the foundations of a building and the scaffolding that can rest on them, which you don’t want to operate without, because the simplicity of the simple solutions was only an illusion.

You find out that what you’d need is:

• one place where scripts live and where you can still find them in six months - not scattered across folders and notes, not each on its own network drive, not as a bunch of “final final final” names where it’s impossible to pick without wasting attention
• a way to run scripts regularly and reliably
• logs, ideally centralised somehow, so you can easily see and trace what’s happening (or what isn’t)
• sufficiently strict (but not too frequent) notifications, so the right people find out when something fails
• access management, so you don’t have passwords hardcoded or lying around in other horrifying places
• some kind of overview of what’s actually running where, when and how often
• and if you’ve also got a web app or two - a secure place to host them, ideally without having to deal with deployment separately for each one

Ideally you’d have all of this neatly in one place. But through historical development it’s entirely common to end up with half your automations living in the admins’ cron, a quarter with the developers in GitHub Actions, a few bits in sales on Zapier or Make, and the rest as hazy notions in someone’s head - or not even that. It’s precisely the kind of faulty approach that can look like successful order until a problem hits - not to mention how such a patchwork wastes the capacity of the human minds that have to keep it alive inside them, and then mysteriously have less and less room left for other important things, like actual work, or even their own lives. And when you’re juggling all those options, you’re bound to drop a ball now and then.

And it’s precisely in this dark and desperate moment, as we writhe in our imagination under the weight of needless digital sediment, and a set of needs has emerged from the long line of experiences behind us, that I’d like to introduce you to a product called Windmill, and to my own ‘mill’, which I run on Windmill.

Why Windmill

I won’t open by saying Windmill is the best thing since sliced bread, because (a) that would be shallow marketing, (b) pre-sliced bread is a pretty low bar, and (c) you’ve read this far, so you’re expecting juicy, nourishing information, not silly superlatives.

So you’re in the right place.

The mill as the main place

Windmill is a super modern (written in Rust!) and, at its core, open-source platform that can take excellent care of exactly those automation needs of ours. It takes our scripts and not only gives their source code a home, but also makes sure they actually run, along with the whole environment around them. In theory you wouldn’t even need Git to store your source code, since Windmill versions it too, but that would be blasphemy, so of course you keep using Git alongside Windmill (and if you don’t, you’ll spend half a day getting acquainted with it) - in Git the scripts are written down, in Windmill they come alive.

It hardly matters what language you need for your scripts; all sorts are supported: Python, TypeScript, Go, Bash, SQL, .NET, Docker, etc. Every script can be in a different programming language and Windmill doesn’t mind. You can bring a finished script, or write one with LLM assistance in the built-in editor, and Windmill is able to promptly turn it into a runnable unit with logging, scheduling, input parameters, credentials management and a web interface.

But it’s far above just running scripts. Windmill can also host full-fledged web applications - dashboards, forms, internal tools, admin panels. Windmill can provide a database too, when needed, and you’ve got a working app for internal use without having to deal with separate hosting, deployment, CORS, reverse proxies or any of the other terms that are the reason no sane person wants to be an IT admin.

Windmill can help you break out of various prisons - one of them is called spreadsheets. You know the drill - one Excel file where orders are tallied, a second one that pulls numbers out of it via a macro, and a third one that someone copies them into by hand every Monday to make a report for management. And woe betide everyone if someone shifts a column in the first one. Windmill can dissolve this tyranny: it fetches the data itself from wherever it originates, stores it in a database, recalculates it on schedule and publishes the result as a dashboard, sends it by email as the Monday report, or - if someone insists - writes it back into an Excel spreadsheet so the bosses don’t have to learn anything new. It’s not exactly a new concept, but it’s executed without the ballast of our historical finding out what is actually needed. A hand-maintained patchwork can become a flexible business intelligence and reporting suite that can also practically run and develop itself, and you can still see where every number came from on your spreadsheet dashboard.

But the key word isn’t “place” - it’s “main”.

Simply a mill for data flows

Windmill itself is an automation platform; the mill is Windmill with opinions and content - an automation platform for individuals, groups and organisations. Once you get used to these possibilities, it’s hard to go back to a life in which every digital thing had its own random, disconnected world.

Think of it as “Zapier, where instead of clicking, you let an agent write code within a safe framework” - or as “GitHub Actions, but self-hosted, with the option to click things together in a UI, and with the bonus that you can host right there the very app you wrote those scripts for in the first place”. Except that, unlike both of those, it’s also the place from which all of it is controlled - not just run.

Today, every external service I need or work with (Google stuff, Reddit, invoices, to name a few) now has its own Windmill wrapper. A small script (or several behind a single facade) that wraps the service (directly or via existing libraries) and gives it a uniform interface, uniform logging, uniform naming and structural conventions. And takes care that my data in the cloud also stays at home - by default.

The key word there is wraps. For the mill I try to use ready-made things - open-source projects and existing libraries that someone has already looked after, fixed and thought through. I don’t want a monolithic solution tailored exactly to my needs. The world iterated its way to today’s established patterns and tools for a reason. It’s an interesting thought experiment to explore why that is and whether it’s the best we can come up with - but believing I’ll just code everything to measure, because AI can now write it for me in an afternoon, would be a symptom of AI psychosis. Even just gluing ready-made pieces together takes a fair amount of attention.

Why? Because a mill as the place through which everything in your digital world flows opens up interesting possibilities:

On top of that, and that’s no small thing, it’s not at all hard to run the whole thing on your own server.

Those milestones, one by one

Remember that journey above? Let’s run through it again, this time with Windmill:

“It works!” - If you really don’t want to be even a little bit of a programmer and refuse to use an IDE and Git, go ahead and create (or have someone create) a ‘script’ (or several) in Windmill, right in the browser. Windmill gives you an editor and lets you hook up the AI assistant you use, and it handles imports and installs dependencies automatically. No npm install, no virtual environments, no “well, it worked on my machine”. You click Run, you see the output. Done.

“And now I run it… myself, again?” - No. You add a schedule in that one place where you keep such things. You say “every hour” or “every Monday at 8:00” or write any cron expression you like. Windmill takes care of it. You go do something else.

“It’ll just keep running somewhere” - Windmill is that cron, only better. Every run has its own record - when it ran, how long it took, what it returned, whether it succeeded or failed. You can click through it, filter it, export it, and there’s an API for everything, so it can be controlled from elsewhere.

“Wait, how long has this been broken?” - Windmill answers this one by design. Every run is logged. If a script fails, you see it immediately in the UI - and you can set up a notification (webhook, email, Slack, whatever) to tell you. Fewer silent failures, fewer surprises weeks later.

“I need… a system” - Windmill is that system. Scripts are organised into folders (by domain - f/scraper/, f/llm/, f/google/, f/invoicing/ - or however you like). Windmill keeps credentials encrypted in resources; you refer to them by name, you never see them in code, and every user can have their own. You get an overview of all schedules, all runs, all scripts on one dashboard.

What’s free about it

This is where I’d normally expect the catch™. “Free tier up to 100 runs a month” or “free for one user with a limited number of steps” - you know the drill.

Windmill does it differently. The self-hosted version is free with no limit on the number of runs. No licence key, no counter, no “upgrade to continue”. You just run it.

I’m not saying you’ll never pay anything for it. Enterprise features like audit logs, SAML SSO, native Git sync or Kafka triggers - those are paid. But for one person, a small team or an organisation that needs to automate dozens of processes? The free tier is enough. I’ve been running on it for a few years now, I have 200+ scripts across 27 domains, thousands of runs a day, and so far nobody has sent me an invoice.

Why not Zapier / n8n / Make

I have nothing against these tools. They do what they’re meant to do. But:

Zapier charges you for every “task” (a step in an automation). If you have an automation that fetches RSS → sends it to an LLM → saves the result → sends a notification, that’s 4 tasks. For one automation. At a hundred runs a day you’re at 12,000 tasks a month, which on Zapier Pro will cost you… well, more than the VPS that Windmill will run on for you with an unlimited number of steps. Make is in a similar boat, except it doesn’t call them tasks but operations - and you pay for every one.

n8n is great and source-available (its ‘fair-code’ licence isn’t quite open source), but it’s a click-together editor. Perfect for simple automations. But as soon as you need to write real logic - conditions, loops, error handling, calls to external libraries - you start wrestling with a “code node” inside a visual editor, which is exactly as pleasant as it sounds. And what if you wanted to plug in someone else’s open-source library, written in Go, say? Sure - build your own Docker image with it bundled in, or spin up your own workers for it. Sure, it can be done. Good luck.

Windmill is code-first. Your script is the automation. Hardly a layer between your environment and the code. When you want a visual flow (and for some things it’s legitimately useful), Windmill can do that too - but as a composition of code steps, not as an alternative to them. And if you need your automation to have a face as well - a frontend for someone who has never opened a terminal and doesn’t want to - that’s still Windmill, still in the same place, still with no extra deployment.

🤯 To wrap up: agent-ready

All the AI companies today are fighting over who gets to supply you with an assistant, a worker, a teacher, an understanding stand-in for a partner, so that you become dependent on them and they can then tighten the screws, milk you and enshittify. When you have a mill, you have a chance to own everything yourself and simply plug an LLM into it - even your own local model.

Windmill can act as an MCP server: MCP is simply an agreed-upon way for AI assistants to use tools outside themselves.

Windmill can offer the scripts you choose as tools.

It sounds unassuming, but it’s the last piece of the puzzle. The ChatGPT app on your phone can already use MCP tools even in voice mode - so my Claude Code works on some project in its isolated container, and ChatGPT, as my assistant, takes a peek through my mill into its terminal to see what’s going on; I can answer out loud the questions Claude is asking me, which ChatGPT reads out, or even send it off to search or investigate something somewhere and then sum it all up into ‘proper’ output, because of course I have the rules for that stored in Obsidian.

Or I can simply deal with email and schedule meetings in my calendar by voice - across several clouds, or fully self-hosted.

If I suddenly lose access to one of the services I use, I lose nothing, because everything goes through the mill and is mirrored to me. And I don’t need to leave ‘anything’¹ to who-knows-whom to data mine.

And all the while I don’t have to log OpenAI or Anthropic into my Gmail and the like and leave my credentials with them, or pay for yet more services to look after my projects, graphics, whatever. A mill that’s been lent an LLM like the Claude models (5.5 currently rules the roost) can these days automatically swallow and absorb, or outright replace, a whole lot of things that today’s ecosystem nudges you to keep scattered, expensive and open to snooping as you’re building them in other people’s walled gardens.

With Windmill, it’s my mill that’s logged in, on ‘my’ machine - and a third-party assistant only reaches a connected service through the mill, say my email, at my behest, indirectly, through tools I’ve offered it myself, within the scope I’ve set for it, and with an approval I may or may not give.

Access for agents is the mill’s most significant ‘side effect’ - you can let any LLM of yours into the mill, or into part of it. Your agent, be it Claude or the ChatGPT app on your phone, can operate anything you allow through the mill. In practice this means I can have my Obsidian notes, chat with GPT Astro - a model you can actually talk to, not just type at - tell it out loud what to find or write down for me, and know that the resulting artefact won’t end up in OpenAI’s walled garden but right here at my home. And when something does have to be created elsewhere, the mill can automate saving a copy at home too.

Right after that I can use Claude on my computer, tell it to load the note I just added and set up the bones of a project for it according to the rules in my vault (which it loads by itself, of course) - and it calls my mill in turn, and could just as well add a row to a Google spreadsheet here, spin up a new environment there, or kick off research on some topic (the mill can of course read things from the web that tend to be hidden from LLM agents these days), write a script for a five-minute podcast (again following the rules I already have in the vault) and have it voiced through the mill using a service I’ve got hooked up there.

My wife can do the same - under her own account she can let the same mill into her digiself.

It took several years of gradual experimenting on my part, and of the best LLMs steadily improving, before I was sure I could lean on the way the mill is set up and, casually, in spare moments, do things that would otherwise need a full-time team - like a series of pre-election AMAs on the Brno subreddit (in Czech). At first you want to check and approve every step before it runs, but you can’t keep that up forever, and you gradually learn that with the right harness, today’s LLMs can be pretty reliable. And if tomorrow I decide I want Microsoft instead of Google, or to run everything at home or in the neighbourhood, or I want ChatGPT instead of Claude (or my own local model, or all of them at once as needed), nothing has to move, nothing needs to be carried over - the tools, inputs, outputs and access stay available in the mill and through the mill, and they only flash through someone else’s walled garden for a moment before everything returns to my digital space.

The mill deliberately doesn’t give AI autonomy

It’s not “all agent”, the way people (probably inevitably) try it in experiments these days. The mill isn’t an autonomous agent like OpenClaw or Hermes; the way it’s wired doesn’t let generated text control your digital life and do whatever it sees fit there. Though such an agent would certainly make good use of Windmill’s access and scaffolding too.

You can let an assistant press some of them - and each press is predictable and traceable.

And these days new buttons get made for you by an agent, too. If you know what to ask of it and how to check it got it right, it can do this reliably today, especially within Windmill’s guardrails. You show it the documentation for the service you want to connect, and it writes a script following your conventions (plus tests and documentation), tries it out, uploads it to Windmill and even makes it available to your assistants. Half an hour later you have a new tool, and you never had to leave the conversation in which you asked for it. And when the assistants use it, they won’t see the passwords and keys to that connected service - those stay encrypted in the mill.

It’s really no wonder that people in China are flocking to courses on how to set up agents. We’re in a situation where it’s genuinely possible to let LLM assistants handle routine stuff - not in a keynote demo, but on an ordinary Tuesday. The question is no longer whether it’ll work, but where it will run, who it will belong to, and what the prompts will be - is it, for instance, good manners to let an LLM write on your behalf, under your name, without a warning? Where will we, as a society, write down the direction we end up taking?

The mill is my answer: a way to use what LLMs can do to the fullest, but also, as far as possible, on ‘my own’ hardware, with open-source software I don’t have to maintain myself, within my own digital privacy. The mill can be a control panel for everything, a solid but flexible backbone for digital life - all the more powerful because shaping it, running it, managing it and caring for it can easily be handled by agents, if you guide them well. Or if they’re guided by an organisation that could take care of such things for us.

And when the mill is to become the backbone of an organisation, it gets even more interesting. Organisations have always had a spirit of their own, but only today, once we plug in LLMs, can an organisation’s spirit begin to manifest autonomously. It’s just that it will quickly become clear that the spirit of a lot of organisations is pretty frightening.

Start with the mill wheel with planning by observing

Over the next month, try to notice:

Once you’ve collected enough of these, you’ll know exactly whether you need a tool like Windmill. And if you do, start from scratch: with an empty Windmill.

Have an LLM agent (here at the end of 2026 that’s mostly Claude Code / Codex) study the actual documentation and write up skills - that is, procedures for how things are done properly in Windmill - or go straight for having it write and hook up a script that solves the one thing that’s bugging you most. For your first experiments, a box with a couple of cores and a few gigs of RAM, half an hour of your time and docker compose up -d will do.

It sounds slower and more complicated than paying for the option to build with someone else’s tools in someone else’s garden and preferring not to think about whether you’ll be able to take it with you later. But Windmill isn’t needlessly complicated, even if it may look that way at first glance. A finished system is a complex thing whose purpose you often can’t see at first - and so it asks you for nothing but seemingly pointless things: conventions you don’t understand yet, layers for problems you don’t have yet. Whereas a script that saves you manual work in the morning makes sense from the very first minute. So does the second one. And by the fifth you’ll find you need some conventions - and this time you’ll know why.

A mill of your own

Would you rather have my mill right away instead of an empty Windmill? One that does what you tell it, and builds and manages itself? Hah, of course you would 🤠

Sure, we can talk about me setting up a custom mill like that for you, whether for an organisation or a family. Of course I can do it - I have ready-made templates for everything, written-up skills for AI agents, and the whole thing can almost automatically hook itself up and run itself. It includes deploying Windmill, setting up conventions, migrating existing scripts, connecting services.

It’s just that the whole thing isn’t a product; it’s a bundle of conventions, it’s a path you’re choosing to walk - these days no longer alone, but with the help of LLMs. The foundation is an instance of the mill with principles and skills you can rely on, and your mill then, with your help and the AI provider of your choice, shapes its own form and the way it works to suit what you need.

The mill of course has an app that makes it easier to get to the various parts you set up in it. The mill can let other users in, and it can explain itself to its users and to you. After asking you a few questions, it can suggest what might be worth connecting and how it could all be wired together.

With Windmill and a ready-made LLM harness, you can go as deep as you like - you never have to come face to face with code, but just next door you’re free to optimise a workflow down to the last query.

Startup? Rather a nonprofit

I’ve long held that for something as powerful as the mill (and AI in general, though the mill’s genie hasn’t escaped the bottle yet) we mustn’t use a for-profit model - that’s how we summon the paperclip scenario: a system obsessed with a single goal (profit for a select few) flattens everything else in its pursuit. In the famous thought experiment, that goal is making paperclips. In our world, it’s the phantom of mandatory profitability and eternal growth.

After all - so far I haven’t noticed the AI corporations eagerly using their AI to drain the existing ponds of power. If anything, they’re deepening them and fencing them in. You can’t really blame them, it inevitably comes with the business model. And that’s exactly why our model doesn’t want to be, and mustn’t be, commercial and for-profit.

I call this line of thinking Aretea (after the Ancient Greek ἀρετή), and it isn’t a startup I’d want to cash out of quickly, but a nonprofit I’m putting together, whose aim is to do things as well as today allows us. More precisely, it’s a meta-nonprofit: a nonprofit as a replicable template for people and groups who want to have their own digital infrastructure under their own control, at shared cost, transparently, without anyone extracting a profit from it. A template that brings up the necessary digital infrastructure on any cloud or your own server, automatically configured and ready for LLMs to be plugged in, with Windmill as one of its main pillars, with whose help it can then take care of itself almost on its own.

The technical part is actually the easier one. These days agents will write much of the code, and the mill will mark out where to run it.

There’s no script for the social side. That’s what a nonprofit is for - people who work it out together, and then share the mill together too. Details are gradually piling up on aretea.cz and kerray.cz. No mailing list, no “subscribe to our newsletter” - check in now and then, or just get in touch. I’d be glad.

Windmill: windmill.dev | GitHub | self-hosted, open source, free tier with no limit on runs.