Day 5 of Windmill launch week. You can now define complex workflows entirely in TypeScript or Python. Windmill handles checkpointing, parallelism, and fault tolerance. You write functions.

The problem​

Windmill's flow editor is powerful for visual workflows. But some orchestration logic is easier to express in code: dynamic branching, complex error handling, loops over variable-length data, or workflows that need to live in your codebase alongside the rest of your application.

Other workflow-as-code frameworks (Temporal, Inngest) require dedicated infrastructure, complex SDKs, or proprietary runtimes. We wanted the same capabilities with two annotations and zero new infrastructure.

Workflow-as-code: functions, not YAML​

A workflow is a regular script with @workflow and @task annotations. Each task runs as a separate Windmill job with its own logs, timeline entry, and retry policy. Between tasks, the workflow fully suspends and releases its worker.

import { task, workflow, sleep, parallel } from 'windmill-client';

export async function main(urls: string[]) {
  const results = await parallel(urls, async (url) => {
    const data = await task(async () => {
      const res = await fetch(url);
      return res.json();
    });
    return await task(async () => {
      return transform(data);
    });
  }, { concurrency: 5 });

  await sleep(60); // suspend for 60s, release worker

  await task(async () => {
    await saveResults(results);
  });

  return { processed: results.length };
}

from wmill import task, workflow, sleep, parallel
import requests

def main(urls: list[str]):
    results = parallel(
        urls,
        lambda url: task(lambda: transform(task(lambda: requests.get(url).json()))),
        concurrency=5,
    )

    sleep(60)  # suspend for 60s, release worker

    task(lambda: save_results(results))

    return {"processed": len(results)}

No YAML, no DSL, no drag-and-drop. Standard TypeScript or Python with full IDE support, type checking, and version control.

How checkpointing works​

Workflow-as-code uses a checkpoint/replay model:

1. The workflow runs until it hits a task(), sleep(), or waitForApproval() call.
2. The script exits and the checkpoint is saved to the database.
3. The worker is released back to the pool. No resources are wasted while waiting.
4. Child jobs run independently on any available worker.
5. On replay, all previously completed steps return cached results instantly.

This means a workflow that sleeps for 24 hours consumes zero worker time during the wait. A workflow with 100 parallel tasks does not hold 100 workers.

Core primitives​

Each task() supports options for timeout, worker tag, cache TTL, priority, and concurrency limits.

Why we built it this way​

Three design choices drove the architecture:

Zero worker waste. When a workflow suspends (sleep, approval, waiting for child jobs), the worker is fully released. Other frameworks hold a thread or container open. Windmill's checkpoint model means you pay only for compute you actually use.

Standard language, standard tooling. Workflows are regular TypeScript or Python files. You get IDE autocomplete, type checking, unit testing, and Git diffs. No proprietary DSL to learn.

Composable with flows. Workflow-as-code scripts can call existing Windmill scripts and flows via taskScript() and taskFlow(). You can also use them as steps inside visual flows. The two models are fully interoperable.

Script modules​

For complex workflows, you can split logic into companion modules in a __mod/ folder:

my_workflow.ts
my_workflow__mod/
├── extract.ts
├── transform.ts
└── load.ts

Each module has its own dependencies and lock file. Import with relative paths, reference via taskScript().

When to use workflow-as-code vs flows​

Getting started​

1. Create a new script in TypeScript or Python.
2. Import task and workflow from windmill-client (TS) or wmill (Python).
3. Annotate your main function and wrap each unit of work in task().
4. Run it. Each task appears as a separate job in the Windmill UI.

That's a wrap​

Thanks for following along this week. Five days, five features: Data Tables & Ducklake, full-code apps, AI sandboxes, Git sync & workspace forks, and workflow-as-code. All available now. Try them out.

Windmill is an open-source and self-hostable serverless runtime and platform combining the power of code with the velocity of low-code. We turn your scripts into internal apps and composable steps of flows that automate repetitive workflows.

You can self-host Windmill using a docker compose up, or go with the cloud app.

Day 4 of Windmill launch week. We have reworked Git sync and introduced workspace forks, giving you a full staging-to-production workflow inside Windmill.

The problem​

Windmill workspaces are live environments. You deploy a script, and it runs in production immediately. That works for small teams iterating fast, but as your team grows you need review, staging, and rollback.

Teams end up building custom CI/CD pipelines around Windmill's CLI sync, managing branches manually, and writing their own merge logic. The deploy-to-prod path was functional but required too much glue.

Git sync: automatic, bidirectional​

Every time you deploy an item in Windmill, it automatically commits and pushes to your configured Git repository. Pull from Git to update your workspace. Supports GitHub, GitLab, Bitbucket, and Azure DevOps.

# wmill.yaml
sync:
  branch: main
  path_filters:
    include:
      - "f/production/**"
    exclude:
      - "f/experiments/**"
  type_filters:
    - scripts
    - flows
    - apps
    - resources
    - variables
    - schedules

Configuration lives in wmill.yaml at the repository root. Path filters let you sync only what matters. Type filters control which resource types are included.

Workspace forks: branch your workspace​

Workspace forks let you create an independent copy of a workspace for feature development. Changes in the fork do not affect the parent until you merge them back.

When Git sync is enabled, creating a fork automatically creates a corresponding Git branch (wm-fork/<parent-branch>/<fork-name>). You get parallel development with full version control.

Merge workflow​

Three ways to bring changes back:

1. Deploy UI: deploy individual items from the fork to the parent workspace directly from the Windmill UI.
2. Merge UI: merge all changes at once with conflict detection, no Git sync required.
3. Git merge: use your preferred Git workflow (PRs, code review) to merge the fork branch.

Why we built it this way​

Three design choices drove the architecture:

Workspace-level branching. Forks operate at the workspace level, not the file level. When you fork, you get a complete copy of all scripts, flows, apps, resources, and variables. This means you can test changes end-to-end in an isolated environment before merging.

Git as the source of truth. Git sync is bidirectional but Git always wins. If you need to roll back, reset the branch. If you need to audit, read the commit history. Windmill does not replace your Git workflow; it plugs into it.

Multiple deployment paths. Not every team needs the same workflow. Small teams can use the deploy UI. Growing teams can use workspace forks. Enterprise teams can use the full Git promotion workflow with CI/CD and cross-instance deployment.

Deployment options​

Getting started​

Git sync:

1. Create a Git repository.
2. Go to workspace settings, then Git sync.
3. Configure authentication (GitHub App, PAT, or GitHub Enterprise App).
4. Deploy an item and check your repo for the commit.

Workspace forks:

1. Enable Git sync (recommended but optional).
2. Create a fork from the workspace settings.
3. Make changes in the fork.
4. Merge back using the deploy UI, merge UI, or Git.

What's next​

Tomorrow is Day 5: Workflow-as-code. Define complex workflows entirely in code with the next generation of our SDK. Follow along.

Windmill is an open-source and self-hostable serverless runtime and platform combining the power of code with the velocity of low-code. We turn your scripts into internal apps and composable steps of flows that automate repetitive workflows.

You can self-host Windmill using a docker compose up, or go with the cloud app.

Day 3 of Windmill launch week. You can now run AI coding agents like Claude Code or Codex in sandboxed environments with persistent storage, directly from your scripts and flows.

The problem​

AI coding agents need two things that are hard to combine: isolation and persistence. You want them sandboxed so they cannot access the host filesystem or network. But you also want them to remember state across runs, produce artifacts, and pick up where they left off.

Teams end up managing Docker containers, mounting volumes manually, and writing wrapper scripts to handle session state. The orchestration layer has no opinion about where the agent runs or how its files persist.

AI sandboxes: two annotations​

An AI sandbox is a regular Windmill script with two annotations: one for isolation, one for storage.

// sandbox
// volume: agent-state .agent

import Anthropic from '@anthropic-ai/sdk';
import { MessageStream } from '@anthropic-ai/sdk/lib/MessageStream';

export async function main(prompt: string) {
  const client = new Anthropic();
  // The .agent directory persists across runs
  const result = await client.messages.create({
    model: 'claude-sonnet-4-20250514',
    max_tokens: 1024,
    messages: [{ role: 'user', content: prompt }],
  });
  return result;
}

# sandbox
# volume: agent-state .agent

import anthropic

def main(prompt: str):
    client = anthropic.Anthropic()
    # The .agent directory persists across runs
    result = client.messages.create(
        model="claude-sonnet-4-20250514",
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}],
    )
    return result

// sandbox enables NSJAIL process isolation. // volume: agent-state .agent mounts a persistent volume synced to your workspace object storage. That's it.

Why we built it this way​

Three design choices drove the architecture:

Process isolation with NSJAIL. Each execution runs in its own NSJAIL sandbox with filesystem isolation, network restrictions, and resource limits. The agent cannot access the host system or other jobs. You can force sandboxing instance-wide for all scripts.

Persistent volumes on object storage. Files in the mounted volume are synced to your workspace S3 (or Azure Blob, GCS) between runs. A per-worker LRU cache (up to 10 GB) avoids re-downloading on consecutive runs. Exclusive leasing prevents concurrent writes to the same volume.

Works with any agent. Claude Code, Codex, OpenCode, or any custom agent that operates on a local filesystem. Windmill provides the sandbox and the storage; the agent brings its own logic. A built-in Claude Code template handles session persistence and token counting out of the box.

Built-in Claude Code template​

Windmill ships with a ready-to-use Claude Code template. It handles session persistence (the session ID is stored in the volume), agent instructions, skill files, and token counting for cost monitoring.

// sandbox
// volume: claude-sessions .agent

import { ClaudeCodeAgent } from '@anthropic-ai/claude-agent-sdk';

export async function main(prompt: string) {
  const agent = new ClaudeCodeAgent({
    instructions: "You are a helpful coding assistant.",
  });
  return await agent.run(prompt);
}

Use cases​

• Persistent agent memory: conversation history and session state survive across runs.
• Artifact generation: agents produce reports, code, or data files that persist in the volume.
• Multi-step workflows: a flow triggers an agent, waits for results, then passes artifacts to the next step.
• Safe execution at scale: resource limits and isolation let you run untrusted agent code without risk.

Getting started​

1. Configure workspace object storage (S3, Azure Blob, GCS, or filesystem).
2. Add // sandbox and // volume: <name> <path> annotations to any script.
3. Run it. Files in the volume path persist across executions.

What's next​

Tomorrow is Day 4: Git sync & workspace forks. Sync with Git, stage workspaces, and deploy via CI/CD. Follow along.

Windmill is an open-source and self-hostable serverless runtime and platform combining the power of code with the velocity of low-code. We turn your scripts into internal apps and composable steps of flows that automate repetitive workflows.

You can self-host Windmill using a docker compose up, or go with the cloud app.

Day 2 of Windmill launch week. We are shipping two new storage primitives: Data Tables for relational data with managed SQL, and Ducklake for massive datasets backed by S3.

The problem​

Workflow engines typically punt on data storage. You end up managing separate databases, connection strings, credential rotation, and permission models. Your orchestration layer knows how to run code but has no opinion about where results go.

For analytics workloads, the gap is wider. Teams default to managed data warehouses (Snowflake, BigQuery) that charge per query and live entirely outside the orchestration layer. The result: two systems, two permission models, and a lot of glue code to move data between them.

We wanted Windmill users to go from "I have a script" to "I have a script that reads and writes data" without leaving the platform.

Data Tables: managed SQL with one line​

Data Tables give you a workspace-scoped PostgreSQL layer where credentials are managed by Windmill. Users write SQL; they never see connection strings.

import * as wmill from 'windmill-client';

export async function main(user_id: string) {
	let sql = wmill.datatable();

	// String interpolation is safe: auto-converted to parameterized queries
	let friend = await sql`SELECT * FROM friend WHERE id = ${user_id}`.fetchOne();

	return friend;
}

import wmill

def main(user_id: str):
    db = wmill.datatable()

    # Positional arguments for safe parameterized queries
    friend = db.query('SELECT * FROM friend WHERE id = $1', user_id).fetch_one()

    return friend

-- $user_id (bigint)

ATTACH 'datatable' AS dt;
USE dt;

SELECT * FROM friend WHERE id = $user_id;

That's it. One import, one function call, standard SQL. TypeScript uses tagged template literals that are automatically converted to parameterized queries, so string interpolation is safe by default. Python uses positional arguments ($1, $2). DuckDB uses the native ATTACH syntax.

Why PostgreSQL​

We chose PostgreSQL because:

• It is the most widely understood SQL dialect. No new query language to learn.
• Battle-tested ACID guarantees out of the box.
• DuckDB can attach to Postgres natively, so Data Tables and Ducklake share the same query surface.

Organizing with schemas​

We recommend using one or a few Data Tables per workspace and organizing data with schemas:

let sql = wmill.datatable(':analytics');
await sql`SELECT * FROM events`; // refers to analytics.events

This keeps things clean without spinning up separate databases for every project.

Why we built it this way​

Three design choices drove the architecture:

Workspace scoping. Data Tables are scoped to a workspace. All members can read and write. This removes the need for database-level user management while keeping workspaces isolated from each other.

Credential opacity. Users never see or manage database connection strings. Windmill handles credentials internally. This eliminates a whole class of credential-rotation bugs and accidental leaks.

Bring your own Postgres. You attach a workspace Postgres resource to the data table. Windmill manages credentials internally so users never see connection strings. This gives you full control over database hosting while keeping the API simple.

Asset tracking and data lineage​

When you reference a Data Table in a script, Windmill automatically parses your code and detects which tables you read from and write to.

Assets appear as nodes in flows, giving you a visual data dependency graph. Click any asset node to open it in the Database Studio and inspect the data directly.

Ducklake: S3-backed data lakehouse​

Data Tables are great for transactional data. But some workloads produce millions of rows that do not belong in a relational database. For those, we built Ducklake support directly into Windmill.

Ducklake stores data as Parquet files in S3 and keeps a metadata catalog in Postgres. You query it with standard SQL through DuckDB.

The API follows the same pattern as Data Tables:

import * as wmill from 'windmill-client';

export async function main(user_id: string) {
	let sql = wmill.ducklake();

	let friend = await sql`SELECT * FROM friend WHERE id = ${user_id}`.fetchOne();

	return friend;
}

import wmill

def main(user_id: str):
    dl = wmill.ducklake()

    friend = dl.query('SELECT * FROM friend WHERE id = $id', id=user_id).fetch_one()

    return friend

-- $user_id (bigint)

ATTACH 'ducklake' AS dl;
USE dl;

SELECT * FROM friend WHERE id = $user_id;

Real-world example: sentiment analysis pipeline​

Here is a DuckDB script that receives analyzed messages (e.g., from an LLM sentiment analysis step in a flow) and inserts them into a Ducklake table. Each insert creates a new Parquet file in S3 and updates the catalog metadata.

-- $messages (json[])

ATTACH 'ducklake://main' AS dl;
USE dl;

CREATE TABLE IF NOT EXISTS messages (
  content STRING NOT NULL,
  author STRING NOT NULL,
  date STRING NOT NULL,
  sentiment STRING
);

CREATE TEMP TABLE new_messages AS
  SELECT
    value->>'content' AS content,
    value->>'author' AS author,
    value->>'date' AS date,
    value->>'sentiment' AS sentiment
  FROM json_each($messages);

INSERT INTO messages
  SELECT * FROM new_messages;

Under the hood, TypeScript and Python integrations run DuckDB inline within the same worker. No separate job is spawned, so the overhead is minimal.

Why Ducklake over a data warehouse​

Ducklake gives you a data lakehouse without new infrastructure. Your data stays in an open format on storage you control. The catalog metadata lives in the same Postgres that Windmill already uses. And DuckDB handles analytical queries on a single node without cluster management.

Database Studio​

Both Data Tables and Ducklake are browsable through the Database Studio, a visual interface for inspecting schemas, editing rows, and running SQL.

Building data pipelines​

Data Tables and Ducklake are designed to work with Windmill flows. A typical data pipeline looks like this:

1. Extract: a script pulls data from an external source (API, webhook, database).
2. Transform: one or more steps clean, enrich, or aggregate the data using Python, TypeScript, or SQL.
3. Load: the result is written to a Data Table for operational use or to Ducklake for analytical queries.

Because each step is a standalone script, you can mix languages freely. For example, fetch data with TypeScript, run a sentiment analysis in Python, and insert the results with a DuckDB query into Ducklake. Windmill handles the orchestration, retries, error handling, and data lineage tracking.

You can also schedule pipelines with cron triggers, react to events with webhooks, or chain them with other flows.

Getting started​

Data Tables:

1. Go to workspace settings, then Data Tables.
2. Add your own Postgres resource.
3. Use wmill.datatable() in any script.

Ducklake:

1. Configure a workspace S3 storage.
2. Go to workspace settings, then Object storage and set up a Ducklake.
3. Use wmill.ducklake() in any script.

Benchmark: Windmill + Ducklake vs Airflow + Snowflake​

To put numbers behind the architecture, we ran the same data pipeline on both stacks and measured wall-clock time. Both pipelines start from the same pre-ingested ~3 million row dataset (NYC Yellow Taxi trips, January 2024) and run 5 identical transformation and validation steps.

Pipeline steps​

The transformations are semantically identical — same filters, same formulas, same output schemas.

How each side works​

Windmill + Ducklake runs as a Windmill flow (TypeScript + native DuckDB SQL steps). Each step is a DuckDB SQL script that attaches to Ducklake and creates each table in sequence. All compute and storage stays on your infrastructure — a single worker container (2 CPUs, 4 GB RAM) + PostgreSQL for Windmill metadata. No data leaves your environment.

Airflow + Snowflake runs as an Airflow DAG (Python @task functions using SnowflakeHook). Each step sends SQL to a remote Snowflake MEDIUM warehouse. Compute is externalized to a third-party cloud service: every query travels over the network to Snowflake's infrastructure, where it is processed outside your control. This adds per-query compute costs (Snowflake bills by the second of warehouse uptime) and raises sovereignty concerns over the compute layer — your queries and intermediate results are executed on infrastructure you do not own.

Results​

Windmill + Ducklake completed the pipeline in 9.98 s — 1.5× faster than Airflow + Snowflake at 14.74 s.

The per-step breakdown shows where the difference comes from:

What's next​

Tomorrow is Day 3: AI sandboxes. Run Claude Code, Codex, or custom agents in isolated environments with persistent volumes. Follow along.

Windmill is an open-source and self-hostable serverless runtime and platform combining the power of code with the velocity of low-code. We turn your scripts into internal apps and composable steps of flows that automate repetitive workflows.

You can self-host Windmill using a docker compose up, or go with the cloud app.

Day 1 of Windmill launch week. You can now build complete applications with React or Svelte frontends connected to Windmill backend runnables through a typed, auto-generated API.

The problem​

Workflow platforms typically have no UI layer. When they do, it is a low-code builder: great for dashboards and forms, but limiting when you need custom interactions, framework features like hooks and routing, or an existing component library.

Teams end up building separate frontends. That means a separate deployment pipeline, a separate auth system, REST endpoints to define and maintain, and glue code to connect it all. The orchestration layer runs your backend logic but has no opinion about how users interact with it.

For teams that need a custom frontend, we wanted them to build it where they already build the backend.

Full-code apps: one import, typed calls​

A full-code app is a directory containing your frontend code (React or Svelte) and a backend/ folder with scripts in any Windmill-supported language. Windmill bundles and serves the frontend. An auto-generated wmill.ts module provides typed functions to call your backend runnables.

Calling backend runnables from a full-code frontend with a typed API.

// App.tsx
import { useState, useEffect } from "react";
import { backend } from "./wmill.ts";

export default function App() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    backend.get_failed_payments({ days_back: 7, limit: 100 })
      .then(setData)
      .finally(() => setLoading(false));
  }, []);

  if (loading) return <div>Loading...</div>;

  return (
    <div>
      <h2>Failed payments ({data.failed_payments_count})</h2>
      <p>Total: ${(data.total_failed_amount / 100).toFixed(2)}</p>
      <table>
        <thead>
          <tr><th>ID</th><th>Amount</th><th>Reason</th></tr>
        </thead>
        <tbody>
          {data.failed_payments.map((p) => (
            <tr key={p.id}>
              <td>{p.id}</td>
              <td>${(p.amount / 100).toFixed(2)}</td>
              <td>{p.failure_code}</td>
            </tr>
          ))}
        </tbody>
      </table>
    </div>
  );
}

<!-- App.svelte -->
<script lang="ts">
  import { backend } from "./wmill.ts";

  let data = $state(null);
  let loading = $state(true);

  $effect(() => {
    backend.get_failed_payments({ days_back: 7, limit: 100 })
      .then((result) => { data = result; })
      .finally(() => { loading = false; });
  });
</script>

{#if loading}
  <div>Loading...</div>
{:else}
  <div>
    <h2>Failed payments ({data.failed_payments_count})</h2>
    <p>Total: ${(data.total_failed_amount / 100).toFixed(2)}</p>
    <table>
      <thead>
        <tr><th>ID</th><th>Amount</th><th>Reason</th></tr>
      </thead>
      <tbody>
        {#each data.failed_payments as payment}
          <tr>
            <td>{payment.id}</td>
            <td>${(payment.amount / 100).toFixed(2)}</td>
            <td>{payment.failure_code}</td>
          </tr>
        {/each}
      </tbody>
    </table>
  </div>
{/if}

The typed backend API​

backend.get_failed_payments is fully typed. During development, wmill app dev watches your backend/ folder and generates a wmill.d.ts file with typed signatures for each runnable. Given this backend script:

# backend/get_failed_payments.py
def main(stripe_ressource: stripe, days_back: int = 7, limit: int = 100):
    # ...

The generated types will be:

export const backend: {
  get_failed_payments: (v: {
    stripe_ressource: { token: string };
    days_back?: number;
    limit?: number;
  }) => Promise<FailedPaymentsResult>;
};

Your frontend gets autocomplete, type checking, and compile-time safety when calling runnables. No manual type definitions, no API contracts to maintain.

Beyond synchronous calls, the API supports async patterns for long-running tasks:

import { backendAsync, waitJob, streamJob } from "./wmill.ts";

// Start a long-running task, get a job ID immediately
const jobId = await backendAsync.generate_report({ query: "SELECT *" });

// Wait for completion
const result = await waitJob(jobId);

// Or stream results as they come
const finalResult = await streamJob(jobId, (update) => {
  console.log("Streaming chunk:", update.new_result_stream);
});

Example: AI chatbot with Windmill scripts as tools Open in new tab ↗

This app is a full-code app built entirely on Windmill. The frontend is a React chat interface. Behind it, a backend flow calls an AI model and passes Windmill scripts as callable tools.

When a user asks a question, the flow is:

1. The React frontend sends the message to a backend runnable via the typed API.
2. The backend flow calls an AI model with a set of Windmill scripts registered as tools.
3. The AI agent decides which tools to call (e.g. querying sales metrics, looking up marketing activations) and returns a response.
4. The result streams back to the frontend.

The entire app, frontend, backend logic, and AI tools, lives in a single Windmill workspace. No external API layer, no separate deployment for the chat UI.

Build full-code apps with Claude Code and Codex​

The Windmill CLI auto-generates AGENTS.md and DATATABLES.md context files so AI coding assistants understand your project structure, backend runnables, typed API, and data schema out of the box.

With Claude Code or Codex, you can prompt the app you want to build and get a working full-stack application: frontend, backend scripts, and typed connections between them. The AI agent knows how to create runnables in backend/, call them from your React or Svelte frontend via the typed wmill.ts API, and preview the result locally.

Prompting Claude Code to build a full-code app from scratch.

Or build from the web UI​

You can also build full-code apps directly from the Windmill UI with your own AI API key. Write your frontend and backend runnables, preview instantly, and deploy without leaving the browser.

Building a full-code app from the Windmill UI with AI assistance.

Why we built it this way​

Three design choices drove the architecture:

Any language on the backend. Your frontend is React or Svelte. Your backend can be anything: TypeScript, Python, SQL (PostgreSQL, MySQL, BigQuery, Snowflake, DuckDB), Go, Bash, Rust, PHP, Java, Ruby, C#, and more. Each runnable is a file in backend/ with the language inferred from the extension. A single app can mix Python data processing with TypeScript API calls and SQL queries.

Local development first. wmill app dev starts a local dev server with hot module replacement. You use your own editor, your own tools, your own npm packages. The workflow is standard: npm install, write code, see changes instantly.

No separate API layer. The frontend calls backend runnables directly through Windmill's execution engine via WebSocket. No REST endpoints to define, no API gateway to configure, no OpenAPI specs to maintain. You write a function in backend/, and it appears as a typed call in your frontend.

Example: project structure​

Here is what a typical full-code app looks like on disk:

my_app.raw_app/
├── frontend/
│   ├── App.tsx                # Main React component
│   ├── index.css
│   ├── index.tsx              # Entry point
│   ├── package.json
│   └── wmill.ts              # Auto-generated typed API to call backend runnables
└── backend/
    ├── sendAiMessage          # Send message to AI agent
    ├── getSalesMetrics        # Get sales metrics
    └── getMarketingActivations # Get marketing activations

Each file in backend/ becomes a callable runnable. The language is detected from the extension: .ts for TypeScript, .py for Python, .pg.sql for PostgreSQL, and so on. No YAML configuration is needed for simple runnables.

Full-stack apps on one platform​

Full-code apps are designed to work with the rest of Windmill. Combined with Data Tables and backend runnables, you get a complete full-stack setup with no external infrastructure:

• Frontend: React or Svelte, served by Windmill.
• Backend: scripts in 20+ languages, each running on isolated workers with full CPU and memory.
• Data: Data Tables for relational storage, Ducklake for analytics. No connection strings to manage.

Backend runnables reading and writing to Data Tables from a full-code app.

Your frontend calls backend runnables via the typed API, and those runnables read and write to Data Tables directly. Windmill handles execution, authentication, hosting, and monitoring.

Getting started​

1. Install or update the Windmill CLI.
2. Scaffold a new app:

wmill app new

3. Install dependencies and start the dev server:

cd f/folder/my_app.raw_app
npm install
wmill app dev

4. Deploy to Windmill:

wmill sync push

You can also create full-code apps directly from the Windmill UI by clicking "+ App" and selecting "Full-code App".

What's next​

Tomorrow is Day 2: Data Tables & Ducklake. Store and query relational data with managed SQL and an S3-backed data lakehouse. Follow along.

Windmill is an open-source and self-hostable serverless runtime and platform combining the power of code with the velocity of low-code. We turn your scripts into internal apps and composable steps of flows that automate repetitive workflows.

You can self-host Windmill using a docker compose up, or go with the cloud app.

The tooling to manage this is evolving fast. workmux uses the one-worktree-one-tmux-one-agent model. Cmux brings Ghostty-based terminal management with notification rings. Others have built internal solutions around tmux scripts, custom CLIs, or IDE extensions. We tried several of these approaches at Windmill, and none fully solved our problem.

On the other hand, writing code has become cheap, so building our own tooling would not take much time. The advantage is complete control over the experience: we implement exactly the features we need, and we iterate fast.

So we built Webmux, an open-source web dashboard and CLI for creating, monitoring, and managing parallel AI agents. It combines embedded terminals (xterm.js rendering real Claude/Codex sessions), GitHub PR and CI tracking, service health monitoring, and Docker sandboxing in one tool.

Webmux is open-source and MIT licensed. Check it out on GitHub or visit webmux.dev to get started.

Why a web UI around a terminal​

We started with workmux, which nails the core abstraction: one worktree, one tmux session, one agent per task. It's a great tool if you live in the terminal.

But as the number of parallel agents grew, we kept running into friction that no terminal-only tool could fully solve:

• Switching context between tmux windows to check agent progress
• Opening GitHub in a separate tab to see if a PR was opened, if CI passed, if there were review comments
• Checking service health manually (did the dev server in worktree #3 crash again?)
• Losing track of which agent was doing what across 5+ concurrent worktrees

The other extreme, building a custom UI per agent using the Claude or Codex SDK, would solve the aggregation problem but create a new one: every upstream release would require us to update our own renderer.

So we went with the hybrid approach: a web dashboard that renders real terminal sessions via xterm.js. You get everything in one browser tab (live terminals, PR status, CI results, service health, notifications) while the terminal stays the source of truth. Anthropic and OpenAI updates show up automatically, and plugging in another CLI like the Gemini CLI or OpenCode is just configuration.

How it works​

One-click worktree creation​

Pick a profile, name a branch, write a prompt. Webmux handles the rest:

1. Creates a git worktree
2. Allocates ports for dev servers (backend, frontend, etc.)
3. Spins up a tmux session with the configured pane layout
4. Starts the AI agent (Claude, Codex, or others) with the prompt and environment variables
5. Runs any postCreate lifecycle hook (install dependencies, seed data, etc.)

All of this is driven by a single .webmux.yaml config file at the root of your project.

CLI​

Everything you can do from the web UI is also available from the command line:

• webmux create: create a worktree with a profile and prompt
• webmux list: list active worktrees with their status
• webmux remove: tear down a worktree and run cleanup hooks
• webmux attach: attach to a worktree's tmux session

Since tmux is the source of truth, changes from the CLI and the web UI are always in sync. This also lets the agent spawn new worktrees for subtasks while working on a parent task.

PR and CI monitoring​

Webmux polls GitHub to track PRs for each worktree's branch. When an agent opens a PR, you see it immediately in the dashboard with:

• PR state (open, merged, closed)
• CI check status and details: click through to see failed test logs
• Review comments displayed inline, so you can read code review feedback without leaving the dashboard

Service health​

Each worktree can define services with allocated ports. Webmux periodically checks these ports and displays badges: green if the dev server is up, red if it crashed. At a glance, you know which worktrees have healthy environments and which need attention.

Sandboxed agents​

The sandbox profile runs agents inside Docker containers instead of on the host. Set runtime: docker in your profile and Webmux handles the rest:

• Mounts git credentials (~/.gitconfig, ~/.ssh, ~/.config/gh) read-only so the agent can push and open PRs
• Mounts AI credentials (~/.claude, ~/.claude.json, ~/.codex) so Claude Code and Codex work out of the box
• Forwards service ports on loopback (127.0.0.1) so dev servers are accessible from the browser without being exposed externally
• Runs as your host UID/GID so file ownership stays consistent across host and container
• Passes environment variables listed in envPassthrough (API keys, cloud credentials, etc.)

This gives agents full autonomy (install packages, run servers, execute tests) without risking your host environment.

Lifecycle hooks​

Each worktree can run scripts at key moments in its lifecycle via postCreate and preRemove hooks defined in .webmux.yaml. This is where you wire up environment-specific setup and teardown: provision a database, install dependencies, seed test data, or clean up resources when a worktree is removed.

For example, at Windmill each worktree needs its own isolated Postgres database so agents never collide. The postCreate hook provisions a fresh database and runs migrations automatically. Combined with profiles (one that clones an already-seeded database, another that starts from a blank slate), each engineer picks the exact starting point they need through the profile selector, without any manual setup.

Linear integration​

We use Linear for issue tracking at Windmill, and Webmux brings it right into the dashboard. You can browse your backlog, search by title, preview the full issue details, and hit Implement to spin up a worktree for it in one click.

Mobile friendly​

The web UI is fully responsive. On a phone you can check which agents are running, read PR comments and CI results, monitor service health, and create or remove worktrees. Combined with a Tailscale setup on a remote machine, you can supervise your agents from anywhere without needing a laptop.

Architecture​

The stack is intentionally simple:

• Backend: A single Bun server that orchestrates git, tmux, Docker, and the GitHub CLI. The codebase follows adapter/service/domain layering: adapters handle I/O (git commands, tmux sessions, Docker containers), services implement business logic (lifecycle management, PR monitoring, reconciliation), and the domain layer holds pure types and policies
• Frontend: Svelte 5 with xterm.js for terminal rendering

No database. The only external services are GitHub (for PRs and CI) and optionally Linear (for issue tracking). All state is derived from git worktrees and tmux sessions.

Everything is configured through a single .webmux.yaml at the root of your project. Key fields include: services to declare dev servers with auto-allocated ports, profiles to define pane layouts and choose between runtime: host or runtime: docker, and lifecycleHooks (postCreate, preRemove) to run setup and teardown scripts per worktree.

How we use it at Windmill​

Webmux works fine on a local laptop, but it really shines on a powerful remote machine. Windmill is a large Rust codebase, and each agent compiling in its own worktree is CPU- and memory-intensive. We run Webmux as an always-on service on a beefy remote server behind Tailscale, so it's accessible from anywhere.

Impact on our velocity​

This is not a controlled experiment, and plenty of other factors are at play, but the trend is hard to ignore. Between mid-January and late March 2026, our weekly merged PRs went from 36 to 96, an all-time high for the team.

Going from "how many things can one person do" to "how many agents can one person supervise" is a real shift, and Webmux is what makes the supervising part practical.

Windmill is an open-source and self-hostable serverless runtime and platform combining the power of code with the velocity of low-code. We turn your scripts into internal apps and composable steps of flows that automate repetitive workflows.

You can self-host Windmill using a docker compose up, or go with the cloud app.

AI agent steps in Windmill bring this capability to your workflows. Define the tools available, a Windmill script or any tools exposed by an MCP server. Then let the agent decide which to call, when to call them, and how to combine their results. The agent becomes a flexible orchestrator that adapts to each request rather than following a rigid script.

This post explores how AI agent steps make sense in the specific context of Windmill, then dives into two technical challenges we solved: making structured output work consistently across different AI providers, and maintaining MCP protocol compliance as the ecosystem matures.

What AI agent steps bring to Windmill​

Tool integration​

To sum up roughly, workflows in Windmill are state machines represented as DAGs (Directed Acyclic Graphs) to compose scripts together. With AI agent steps, any Windmill script becomes a tool the AI agent can invoke. Write your tools in any of the 20+ languages Windmill supports - Python, TypeScript, Go, Rust, PHP, Bash, SQL, and more. You can also use tools from the Windmill Hub.

Because every Windmill script already defines its inputs through a JSON schema, they naturally become tool definitions that AI agents can understand. The agent examines each tool's schema, understands its capabilities and required parameters, then reasons about which tools to use based on the user's request. No separate tool registration or documentation needed - the schema that defines how a script works is the same schema that tells the agent what the tool does.

MCP integration: Through Model Context Protocol support, agents can also connect to external MCP servers: file system browsers, database interfaces, API integrations, and custom business logic servers. This extends the agent beyond Windmill's internal capabilities to any MCP-compatible service.

Triggering AI agent workflows​

AI agent workflows can be triggered through multiple mechanisms. Use webhooks or HTTP endpoints to invoke agents programmatically from external systems. These triggers support both streaming and non-streaming modes, allowing you to choose whether to receive the agent's response incrementally or wait for the complete result.

Conversational workflows: For interactive use cases, enable Chat Mode in your flow, and Windmill transforms your workflow into a conversational experience directly in the UI. Instead of traditional form inputs, users interact through natural conversation.

This works through two key mechanisms. Conversation memory keeps context across the entire interaction - the agent remembers earlier messages and builds on previous exchanges. Configure how much history to maintain, and the agent will recall relevant information throughout the conversation, understanding the broader context of what you're trying to accomplish rather than treating each message in isolation.

Streaming makes the agent's work transparent. As the agent calls tools, processes results, and formulates responses, users can see real-time updates showing exactly what's happening. This visibility is particularly useful for complex workflows where the agent might call multiple tools sequentially - you can follow along rather than staring at a loading spinner.

The result is a workflow that feels truly conversational: the agent maintains context like a human would, and users can see its reasoning unfold in real-time.

Multi-provider support and configuration​

Configure your AI agent with any AI provider: OpenAI, Anthropic, Azure OpenAI, Mistral, Google AI, Groq, Together AI, OpenRouter, or any custom or local endpoint you operate.

Fine-tune your agent's behavior with configuration options: set system prompts to guide how the agent approaches tasks, adjust temperature to control creativity versus consistency, and set maximum output tokens to manage costs.

You can find the full documentation here.

Additional capabilities​

Structured output: Conversational text is useful, but sometimes you need data in a specific format that downstream systems can consume reliably. With JSON schema validation, you can ensure the AI's response conforms to a precise structure, returning a standardized object rather than free-form text.

Image support: AI agent steps support images as both input and output. Provide images for the agent to analyze, or have the agent generate images in response to your request. Generated images are automatically stored in your workspace's S3-compatible object storage, making them immediately available for subsequent workflow steps.

Technical challenges​

Building AI agent steps meant solving real technical challenges. Two stand out: making structured output work consistently across providers with different capabilities, and maintaining MCP protocol compliance in a maturing ecosystem.

Structured output across providers​

Supporting multiple AI providers reveals an ongoing challenge: many providers claim OpenAI compatibility, but real-world differences require effort to handle. Structured output illustrates this well.

Most providers support structured output through a response_format parameter. You specify a JSON schema, and the model ensures its response conforms to that structure. This works straightforwardly for OpenAI, Mistral, Google AI, and several other providers.

Anthropic's models don't support response_format. Rather than limiting functionality for Anthropic users, we implemented a workaround: define a special tool where the tool's input schema matches the desired output structure. The agent calls this tool as its final action, and the tool's arguments become the structured response.

From the user's perspective, structured output works uniformly across all providers. The implementation differs behind the scenes, but the interface remains consistent. This approach lets us support providers with different capabilities while maintaining a unified experience.

MCP protocol compliance​

Windmill uses the official rmcp Rust crate for MCP support. This is a well-engineered implementation that strictly follows the MCP protocol specification, exactly as it should.

However, MCP is still a young protocol. As the ecosystem develops, we've encountered servers that don't implement the specification precisely. These aren't malicious implementations, they're often early versions or experimental servers where the authors interpreted certain edge cases differently than the spec intended.

The types of issues that arise typically involve:

• Incorrect HTTP status codes in error responses
• Deviations in how servers signal unsupported features
• Inconsistent handling of optional protocol elements
• Subtle differences in message format expectations

When Windmill connects to a non-compliant server, the strict protocol implementation in rmcp correctly rejects the connection rather than trying to work around the deviation. This is a bet on the ecosystem's long-term health. By maintaining strict compliance, we provide clear error messages about what's wrong and create incentives for servers to fix protocol issues. As the MCP ecosystem matures, these compatibility problems should hopefully diminish.

A natural fit for workflow orchestration​

AI agent steps in Windmill aren't a separate system grafted onto the platform, they're a natural extension of what Windmill already does well. By building on Windmill's existing workflow engine, multi-language support, and schema-first design, we created a feature that feels native because it truly is.

The result is a system where AI agents orchestrate workflows the same way humans do: by calling tools, processing results, and making decisions based on context. The tools happen to be Windmill scripts in any language. The execution happens through the same job queue that runs every other workflow. The storage uses the same S3 integration that handles all large artifacts.

As the AI ecosystem evolves, Windmill's AI agent steps will evolve with it. Not because we're constantly rebuilding, but because we built on solid foundations from the start. If you want to help us build features like this, we're hiring.

Windmill is an open-source and self-hostable serverless runtime and platform combining the power of code with the velocity of low-code. We turn your scripts into internal apps and composable steps of flows that automate repetitive workflows.

You can self-host Windmill using a docker compose up, or go with the cloud app.

This case study shows why teams pick Windmill for SOAR and walks through a live demo we presented to FEMA, including an automated incident response flow.

The SOAR Problem and Solution​

Having worked in the security industry for 15+ years, including time in SOCs and managed security providers handling security incidents, I've seen the same pattern repeatedly: organizations outgrow managed SOAR platforms as their security infrastructure becomes more complex.

The challenges are consistent across organizations of all sizes:

• Rigid workflows that don't map to unique organizational structures and custom internal systems
• Waiting for vendor features when you need integration with proprietary or government-specific systems
• Limited to pre-built integrations while your security stack includes custom tools and APIs
• Complex pricing models that scale poorly as automation needs grow

As one security engineer noted: "Our workflows got very complex because our infrastructure is complex, and we weren't able to map our playbooks anymore in the managed system."

Windmill addresses these challenges by giving you the flexibility to build exactly what you need:

Code-first approach: Write and compose security scripts and workflows in Python, TypeScript, Bash, SQL, and more. Use your existing codebase as-is with no proprietary language or framework lock-in. Import existing scripts directly using the CLI and develop locally with the VS Code extension.

Performance and control: Fastest job orchestration and workflow engine with near-zero overhead built on PostgreSQL and Rust. Self-hosted and open-source, so you keep ownership of your automation without waiting on vendors or hitting API limits. See our benchmarks.

Rapid iteration: Test and deploy in minutes, not weeks. The built-in IDE, CLI, and AI assistance help engineers build faster. Use any library, any API, and the integrations your team already relies on. Windmill's AI assistant helps you write and debug code, compose flows, and helps users that may not be proficient in code to easily build and debug their workflows.

Building a Complete SOAR Workflow: From Alert to Remediation​

Let's see how this works in practice. In SOAR terminology, a "playbook" is a predefined sequence of actions that security teams follow to respond to specific types of incidents.

Common SOAR playbooks include incident response, threat hunting, vulnerability management, compliance reporting, and user provisioning. Windmill can handle all of these and more, from simple alert triage to complex multi-stage investigations.

After presenting Windmill's approach to security automation to FEMA's Office of the Chief Information Security Officer (OCISO) during their SOAR capabilities workshop, we decided to open-source the materials we had prepared for that event. This blog post shares those insights and the complete workflow demonstration, from initial detection through complete remediation.

Try it yourself: All the scripts, flows, and configurations shown in this example are available in our GitHub repository. You can deploy the complete SOAR demo to your own Windmill instance and test the workflows with realistic mock services.

The Trigger: IDS Alert Webhook​

In most SOAR setups, playbooks are kicked off by events coming from SIEM/IDS/IPS, EDR, TIPs, ticketing systems, email parsers, chat-ops, schedulers, or message queues (Kafka/SQS/Pub/Sub). Windmill supports these patterns via triggers. In this example, the flow is triggered by a webhook to start the flow and pass an initial alert context. (watch 12:00)

E.g. an intrusion detection system detects suspicious activity and sends a webhook to Windmill with:

• Username: jdoe
• IP address: 192.168.1.100
• Hostname: workstation-015
• Timestamp: 2024-01-15T14:30:00Z

Phase 1: Data Collection (Parallel Execution)​

The first phase is enrichment. Typical SOAR playbooks query sources like SIEM, IAM/HR/CMDB, EDR/NDR/AV, MDM/NAC, and threat intel (IP/domain/hash), plus geo/WHOIS and audit logs to add context and reduce false positives. In Windmill, each enrichment is its own flow step that runs in parallel across multiple workers; failures are isolated and do not block the rest. Error handling is built in and can be configured per step.

In this example, Windmill immediately launches five parallel enrichment flow steps:

SIEM Query

This script shows the pattern: call your SIEM over its API, then return a small, normalized payload that downstream steps can use. Use any HTTP client or vendor SDK, authenticate with variables and secrets, and keep the return shape simple for composition.

def main(username: str, ip: str, hostname: str) -> dict:
    # Query SIEM for related events
    events = siem_client.query(
        f"username:{username} OR ip:{ip} OR hostname:{hostname}",
        time_range="last_24h"
    )
    
    return {
        "events": events,
        "failed_logins": len([e for e in events if e.type == "login" and not e.success])
    }

Threat Intelligence

• Queries external threat feeds for IP reputation etc.
• Returns risk score (0-100) and malicious indicators

Identity System

• Fetches user details: department, role, managed devices
• Critical for determining blast radius and appropriate response

Virus/Malware Scan

• Scans all devices associated with the user
• Returns infection status and detected threats

Compliance & Audit Logs

• Checks recent permission changes and access requests
• Identifies potential insider threats or compromised credentials

Phase 2: Analysis & Classification​

The analysis phase is where SOAR playbooks combine all the collected signals to determine incident severity and appropriate response. This typically involves scoring models, rule-based logic, or machine learning to produce a severity level and rationale. Some teams plug in external scoring services or ML models, but the interface stays the same: produce a severity and rationale.

In this workflow, the outputs from Phase 1 are combined into a risk score and severity level.

Our example uses a basic heuristic that produces a numeric risk score and severity. It's intentionally simple and transparent: each signal contributes a fixed weight, and thresholds are easy to tune. Teams often start here and later evolve weights or swap in a learned model.

In Windmill, this logic lives in code and scripts that are easy to review, test, and version. You can swap it for a model or API without changing the flow structure.

Risk Scoring Algorithm

def main(failed_logins: int, threats: List[str], infected: bool, 
         risk_score_ip: int, is_malicious_ip: bool, permissions_ok: bool,
         compliance_risks: List[str], audit_logs: List[dict], department: str):
    
    score = 0
    
    # SIEM analysis
    if failed_logins >= 5:
        score += 20
    
    # Virus scan results  
    if infected:
        score += 40
    if threats:
        score += 10
    
    # Threat intelligence
    if risk_score_ip >= 80:
        score += 30
    elif risk_score_ip >= 50:
        score += 15
    if is_malicious_ip:
        score += 10
    
    # Identity context
    if department.lower() in ["finance", "admin", "security"]:
        score += 10  # Higher risk for privileged departments
    
    # Compliance violations
    if not permissions_ok:
        score += 20
    if compliance_risks:
        score += 10
    
    # Recent suspicious activities
    for entry in audit_logs:
        if entry["action"] in ["request_access", "add_user", "enable_ssh"]:
            score += 10
            break
    
    # Classification
    if score >= 100:
        severity = "critical"
    elif score >= 70:
        severity = "high"
    elif score >= 40:
        severity = "medium"
    else:
        severity = "low"
    
    return {
        "risk_score": score,
        "severity": severity,
        "should_auto_respond": severity in ["high", "critical"]
    }

AI-Powered Incident Summary

The enrichment outputs are consolidated into a structured prompt for ChatGPT or Claude to generate a concise, human‑readable incident summary. The result includes the key signals, a rationale for the severity, and a prefilled ticket body with recommended next actions.

This is where Windmill's AI Agent flow step comes into play. An AI flow step can use tools (e.g calling VirusTotal, a Threat Intelligence API, etc.) as well as outputs from other steps to generate a structured response based on an output schema provided.

Automatic Ticket Creation

The flow then creates a ticket in Linear or ServiceNow with the generated summary and deep links back to the live dashboard, so analysts can jump directly into the investigation.

Phase 3: Response Actions​

Response covers notification, ticketing, and containment: disable or lock accounts, revoke sessions/keys, quarantine devices, block indicators (firewall/EDR/SWG), reset credentials, and update ACLs. SOAR playbooks often gate destructive actions behind approvals. In Windmill, flows branch by severity, pause for approvals in Slack or Teams when needed, and then fan out actions in parallel with retries and full audit trails.

In this example, based on the calculated risk score, Windmill branches out the remediation steps:

🟢 Low Severity (Default branch):

• Log incident to SIEM
• No further action needed

🟡 Medium Severity:

• Send Slack alert to #security channel
• Create monitoring ticket for analyst review

🟠 High Severity:

• Interactive approval workflow via Slack
• Security analyst can approve/deny quarantine actions

🔴 Critical Severity:

• Immediate user account disable
• Automatic device quarantine
• Emergency Slack notification with dashboard link

Investigation Dashboard: Live Context and Controls​

This dashboard gives analysts a single place to review the incident, understand blast radius, and take action without switching tools. It pulls live signals from the workflow and overlays them with user and device context so the next step is obvious. (watch 29:20)

It is built with Windmill's app builder and connects directly to flow steps' data, SQL, and REST APIs. Components are bound to the run, which keeps the view in sync as enrichment completes and decisions are made. Actions on the page can trigger scripts and flows with approvals when needed.

Incident Overview Panel The dashboard opens with a live threat summary produced by the AI analysis, paired with a risk score that highlights the main contributing factors. It also surfaces the user and device context pulled from identity systems so analysts immediately see who is impacted and how.

Geographic Context Map A map provides IP geolocation with threat indicators and an at a glance topology view of affected systems, helping analysts understand blast radius and potential lateral movement.

Interactive Controls From the same screen, analysts can trigger manual quarantine actions, request or grant approvals, and launch custom investigation tools without leaving the dashboard.

Background Data Refresh Threat feeds and SIEM data refresh automatically every 60 seconds, and compliance status updates in real time to keep the view accurate throughout an investigation.

Key Security Features​

Windmill takes care of the security plumbing you expect from a platform built for operations. Credentials live in variables and secrets, or via OIDC for external key management such as HashiCorp Vault, AWS KMS, and Azure Key Vault. (watch 14:15)

Every run and approval is recorded in audit logs and can be exported to your SIEM when needed. Access is managed with roles and permissions, so you can control who runs, edits, or approves. (watch 15:57) When actions need human review, flow approvals work from the UI, Slack, or Teams, including on mobile. (watch 26:42)

Apps and assets inherit access from groups and folders, and you can keep changes safe with separate staging and production environments.

Getting Started with Windmill for SOAR​

Security teams need automation that matches the complexity of today's threats. Windmill lets you build the workflows you need, from simple alert handling to full incident response. After years of watching teams struggle with inflexible SOAR platforms, it's clear that the future belongs to platforms that adapt to your processes, not the other way around.

Join 2,000+ organizations already using Windmill for mission-critical automation, including government agencies, financial institutions, and security-first companies.

Start with a 30-day free trial that includes enterprise features like SAML, external secrets management, and dedicated support and deploy Windmill self-hosted on your infrastructure with Kubernetes, Docker, or bare metal.

Windmill is an open-source and self-hostable serverless runtime and platform combining the power of code with the velocity of low-code. We turn your scripts into internal apps and composable steps of flows that automate repetitive workflows.

You can self-host Windmill using a docker compose up, or go with the cloud app.

The assistant is now available on every screen: in the script editor, flow editor, app editor, and even while navigating. It's always nearby when you need it, yet unobtrusive when you don't.

All of the modes are evidenced in the video above.

A mode for every task​

To make the assistant more effective, we've introduced three specialized modes: Navigation, Script, and Flow. These modes help ensure more relevant responses and better user experiences, tailored to the task at hand.

Navigation mode​

Navigation mode is ideal for discovering Windmill's features and understanding how the platform works. It's especially helpful for new users, providing quick guidance and links to the docs. For more advanced users, it's still useful for uncovering less obvious functionalities without needing to search manually.

Script mode​

In the script editor, the assistant shines by working with rich context. You can provide specific context - like referencing a database schema, selecting a few lines of code, or comparing with the latest deployed version - all easily addable using the @ symbol or through a context dropdown.

Once provided, this context enables a range of quick actions. For example, if you test a step and it fails, you'll be offered options to fix the error or improve the code right from the chat. These actions are tuned to the situation, helping you move faster with fewer steps.

You can also choose to apply or discard specific parts of a suggestion. This granular apply/reject is built directly into the Monaco editor and makes AI suggestions easier to manage - not a flashy feature, just a necessary one.

Flow mode​

Flow mode turns natural language into fully structured workflows. You can describe your intent in plain English, and the assistant will build a flow step by step, connecting scripts, filling in parameters, and even handling branches and loops.

It pulls from your workspace and Windmill Hub, reusing existing components or generating new ones as needed. Based on the context, it sets inputs, chooses iterator expressions, and configures predicates to match the data structure of your flow.

Supported models and interface details​

Windmill AI is compatible with a range of language models. While we mostly test and optimize with OpenAI and Claude - and currently see the best results with Claude - the assistant is designed to work well with other configured models too.

You can easily switch between your available models from within the chat interface. For quick access, use Cmd + L to open the assistant at any time, from anywhere in the app. The assistant adapts to the screen you're on and the actions you're taking, aiming to assist without interrupting.

Looking ahead​

We see AI becoming an increasingly central part of the Windmill experience. We're focused on making it as helpful, flexible, and responsive as possible.

In the near future, expect a more intelligent AI chat, tighter integrations across the platform, and a redesigned autocomplete experience that speeds up scripting.

In addition to the MCP server we already provide for executing scripts we're also exploring the possibility of exposing a similar capability for creating, editing, deploying, and configuring scripts, flows, triggers, and other Windmill resources - accessible from local tools like Claude or Cursor.

The AI assistant is now live and available across Windmill cloud, and on all self-hosted instances after version v1.495.0

Windmill is an open-source and self-hostable serverless runtime and platform combining the power of code with the velocity of low-code. We turn your scripts into internal apps and composable steps of flows that automate repetitive workflows.

You can self-host Windmill using a docker compose up, or go with the cloud app.

"Windmill is invaluable for our end users, the indigenous communities. As simple as it is to deploy and scale, it saves them hours of work and provides near-instantaneous data access that previously took months of manual work."

This testimonial is based on conversations with Rudo Kemper from Conservation Metrics. Rudo is leading a program to build free and open-source software for data sovereignty for indigenous communities, in Brazil, Kenya, the Solomon Islands, and elsewhere.

What before Windmill?​

Conservation Metrics works with indigenous communities worldwide to provide tools and systems for environmental monitoring and protection. As part of our Guardian Connector toolkit, our team needed a workflow orchestrator that could handle data processing from various sources, particularly for centralizing data from many different field data collection applications used by communities, and monitoring illegal activities in protected territories.

Having migrated from Dagster, we found that Windmill offered the accessibility and ease of use we needed for our small teams and non-technical users. Its intuitive interface and flexibility allowed us to focus on our core mission, rather than spending time on framework configuration or building additional user interfaces.

How we use Windmill​

Our team leverages Windmill for several critical workflows:

Environmental monitoring pipeline​

Our core environmental monitoring workflow integrates with data provided by the Brazilian research institute Imazon or Global Forest Watch to monitor changes in forest cover. When potential illegal activities are detected, our system automatically:

• Processes the alert data (including conversion of GeoTIFF images to JPEG for browsing rendering)
• Triggers WhatsApp notifications to local communities
• Posts the alerts to a CoMapeo API for offline data collection
• Updates monitoring dashboards
• Logs the events for further analysis

This pipeline has been successfully implemented with community partners in Brazil, Suriname, and the Solomon Islands.

Data processing and integration​

We use Windmill for various ETL workflows:

• Extracting tabular and binary data from multiple environmental monitoring and field data collection sources (such as KoboToolbox, ODK, CoMapeo), and wildlife sensors (camera trap and bioacoustic devices)
• Transforming and processing the data
• Loading results into our databases
• Generating automated reports and alerts

All our scripts are open-source and available in our GitHub repository, making it easy for other organizations to adopt similar solutions.

A Windmill Workspace populated with some of the tools in the GitHub repository.

Real-world impact​

Windmill has enabled us to create tangible impact in protecting indigenous territories:

Combating encroaching gold mining in the Amazon rainforest​

Our system runs daily to detect new alerts about gold mining activities within indigenous territory. When detected, the system provides before/after images and coordinates of the activity. It also integrates field data from tools like CoMapeo, allowing teams to cross-reference remote sensing with ground observations. The automated notifications enable rapid response from local teams, who may alert authorities and law enforcement. This quick response is crucial as small-scale illegal mining often involves mercury, which can contaminate waterways and cause long-term environmental damage.

"In 2022, during a mapping expedition, we discovered an illegal mining site inside of one of the Indigenous territories. When we returned from the expedition and investigated the site using satellite imagery, we found out that the mining activity had actually been ongoing for a year already! Now, with this new alerts system, we will be able to know about it within a matter of days or weeks, inform the communities, and alert the authorities to take action. This is an invaluable boost to our ongoing monitoring efforts to keep the region safe from land invasions." — one of our partners in Brazil.

Solomon Islands: preventing illegal logging​

In the Solomon Islands, our Windmill-powered monitoring system helped detect and stop logging operations above 400m in elevation — areas that often overlap with Indigenous community lands and were deemed illegal under the 2018 Sky Islands pledge. Having demonstrated the effectiveness of automated environmental monitoring, the system is becoming a national-level methodology for monitoring alerts and has been received positively by the ministry of the environment.

Presentation of alerts dashboard for the Solomons ministry of the environment. [source]

Real-time dashboards for community-led monitoring​

Before Windmill, many of our Indigenous community partners relied on paper-based methods or apps that required manual processing, often taking weeks or months to generate useful insights. Now, we’ve built end-to-end workflows where users collect data or complete surveys in the field, and Windmill automatically retrieves that information every hour. When users open their dashboards, the latest data is ready for the entire village to review that same evening. Already, this has been a game changer for how these community organizations track impact and make decisions.

Why we chose Windmill​

Several key factors made Windmill the right choice for our organization:

• Accessibility: The intuitive UI and operator mode allow non-technical users to manage workflows without coding knowledge
• Open source: Our scripts remain in raw Python format, making them easily transferable and maintainable
• Quick implementation: Small teams can become productive quickly, crucial for organizations with limited resources
• Community support: Excellent documentation and responsive community on Discord
• Flexibility: Easy integration with various data sources and notification systems
• Portability: The ability to run raw Python scripts without special formatting means we can easily port our code to other frameworks if needed
• Low learning curve: New contributors can quickly understand and work with our codebase without needing to learn a specific framework

The power of automation for small teams​

What makes Windmill particularly valuable for mission-driven organizations like ours is its ability to replace multiple roles that would typically require dedicated staff:

• Server administration: Simple deployment and management through Docker
• Workflow orchestration: Intuitive interface for managing complex data pipelines
• User management: Role-based access control for different user types
• Frontend development: The built-in UI generation capabilities eliminate the need for separate frontend applications

This has allowed our small team to focus on our core mission of supporting indigenous communities rather than managing complex technical infrastructure.

Looking forward​

We're excited about Windmill's continued evolution and its potential to further empower organizations working in environmental conservation. The upcoming improvements to the app builder will make it even more valuable for our work.

Our experience with Windmill demonstrates how the right tools can amplify the impact of organizations working on critical environmental and social issues, even with limited technical resources.

We are grateful to our partners, including the community organizations and Nia Tero, for co-creating this resource with us.

Windmill is an open-source and self-hostable serverless runtime and platform combining the power of code with the velocity of low-code. We turn your scripts into internal apps and composable steps of flows that automate repetitive workflows.

You can self-host Windmill using a docker compose up, or go with the cloud app.

Why we chose Svelte at Windmill​

At Windmill, our frontend is built with Svelte, and there's a clear reason why: it's the most developer-friendly and productive framework we've found - especially for those of us with a backend-first mindset. Svelte lets us move fast, iterate on ideas directly in the app, and avoid a lot of the boilerplate you typically find in other frameworks.

This philosophy of simplicity was echoed by Rich Harris himself during the summit:

"I don't care about the framework; I just want to make people's lives easier."

For example, among the crowd was a team from Radio France - the largest public radio platform in France. Remarkably, they had migrated their entire website to Svelte four years ago, even though the project was still in its early stages at the time. Why take such a risk?

"We gathered three equally skilled dev teams and had them work on the same project using Vue, React, and Svelte. After four weeks, the Svelte team had delivered three times more features, achieving this with only half the amount of code." said Yann.

This sentiment captures the promise at the heart of the Svelte community. And from everything I saw and heard, Svelte is living up to that promise.

So it made total sense for us to sponsor the Svelte Summit. It was a way of giving back to a community that builds and maintains a tool we love using every day.

The event vibe: intimate, friendly, fun​

The event itself was cozy - think around a hundred attendees - and held in a beautiful venue that made the most of Barcelona's May sunshine. Over the course of two days (May 8–9), the space was packed but never overwhelming. There was enough room for spontaneous chats, hallway conversations, and of course, a lot of geeking out over JavaScript and animations.

If I had to sum up the crowd in one word, it would be passionate. Everyone was there because they love Svelte, not because they had to be (many were there at their own expense). One attendee had even flown in all the way from Taiwan just to be part of it.

Talks that dazzled like stage shows​

I went in expecting technical walkthroughs and code-heavy demos. Instead, what I experienced was a series of engaging and well-rehearsed presentations, much like the inspiring talks you'd find at TED conferences. From a deep dive into the Severance universe that ignited a full room's love of animation, to the tallest developer in the room unexpectedly becoming the evening's MC, there was never a dull moment.

Topics ranged from SSR strategies and building 3D animations with Svelte, to how folks are using it to power entire component libraries. Most of the sessions were less about deeply technical rabbit holes and more about sharing ideas, exploring creative directions, and inspiring new uses of the framework.

Networking, hiring and community​

The breaks between sessions were just as valuable. The venue layout encouraged mingling, the food was great, and you could really feel the community spirit. Conversations flowed naturally - about code, design, performance hacks, or just life. By day two, the after-effects of the previous night's party were showing on a few faces, but the mood stayed light, engaged, and welcoming.

One thing I noticed: the crowd skewed senior. I didn't meet any junior devs. Most folks were either experienced engineers or indie creators. That made it a less ideal venue for active recruiting, but still a great spot for long-term relationship-building.

Hiring Svelte devs is still tricky. Many developers love it, but few get to use it in their day jobs. "Do you use Svelte at work?" - "I wish." - was a common refrain. The migration stories I heard were all positive, though. It's clear that when teams do switch, they tend to love it. Some companies even hire React devs and convert them to Svelte later.

Would I go again?​

Absolutely. I'll be back next year - not necessarily to recruit (although we are hiring!), but to support the Svelte project, see how it evolves, and reconnect with the amazing people I met this time around. The summit was a celebration of creativity, a showcase of possibility, and a reminder of why developer tools matter - not just for code, but for community.

If you're a developer who cares about great DX, expressive code, and building things fast without burning out, you should consider giving Svelte a try - or better yet, join us at the next summit.

Windmill is an open-source and self-hostable serverless runtime and platform combining the power of code with the velocity of low-code. We turn your scripts into internal apps and composable steps of flows that automate repetitive workflows.

You can self-host Windmill using a docker compose up, or go with the cloud app.

"The most appreciatable thing about Windmill is the feedback and support. The UI is great, it was just easy to start and the functionality was really acceptable. Overall experience is great - it's evolving really fast."

This testimonial is based on conversations with Yonathan Adest (CTO at Investing.com) and Denis Cherepanov & Alex Avaneysan from the AI squad at Investing.com.

What before Windmill?​

Investing.com is one of the top financial markets platforms worldwide, providing real-time data, quotes, charts, financial tools, and news services. Our AI squad needed a workflow orchestrator to consolidate our various automation processes in one place.

While evaluating different tools like Airflow, our primary focus was on speed of implementation, as we needed a solution we could deploy quickly. We found that Airflow would have required significant setup time for our workflows, whereas Windmill offered us an intuitive UI, built-in tracing and logging, and rapid setup through Docker Compose. The ability to easily port our existing code and the self-explanatory interface made Windmill the obvious choice for our team.

How we use Windmill​

Our AI team leverages Windmill for various automation workflows:

Content automation pipeline​

Our core workflow manages content processing and distribution. When articles are submitted via webhooks, our system leverages AI and vector embeddings to automatically tag and link content to relevant financial entities. The system assigns relevance scores to each article, which determines whether push notifications should be triggered for specific user segments. Additionally, the pipeline assists with initial content translations, which are then refined through human review. We orchestrate this entire process—from content ingestion to smart distribution—through Windmill.

Automated stock analysis​

We recently launched a project generating comprehensive PDF reports for individual stocks. These reports include extensive data analysis and trading recommendations. Our workflow pulls data from multiple sources, processes it through our AI models, and generates detailed reports—all orchestrated within Windmill.

ETL & data processing​

We heavily rely on Windmill for our ETL workflows—extracting data from our various sources, transforming it (often using our AI models for tasks like summarization), and loading results into our PostgreSQL database. All processing happens within Windmill, which serves as our central hub for AI data operations.

Why we chose Windmill​

Several key factors made Windmill the right choice for our team:

• Quick setup: The intuitive UI and Docker Compose setup enabled us to get started immediately. The Helm chart and Kubernetes support allowed us to quickly scale up to production.
• Excellent support: We consistently receive responses within 15-30 minutes for technical questions.
• Comprehensive logging: Built-in logging capabilities make our debugging and monitoring straightforward.
• Evolving features: Regular updates that address our needs, like improved parallelism handling.
• API integration: The ability to expose workflows as APIs gives us additional flexibility.

We've been particularly impressed with how Windmill has evolved to address early challenges. For example, initial workarounds we needed for handling parallel processing of large datasets are no longer necessary thanks to recent updates.

While we primarily use Windmill for automated workflows rather than its UI generation capabilities, it has become an integral part of our infrastructure, handling everything from periodic data crawling to complex AI-driven content generation.

Windmill is an open-source and self-hostable serverless runtime and platform combining the power of code with the velocity of low-code. We turn your scripts into internal apps and composable steps of flows that automate repetitive workflows.

You can self-host Windmill using a docker compose up, or go with the cloud app.

Before Ansible, managing hundreds of servers meant either writing complex shell scripts or dealing with heavyweight configuration management tools that required significant setup. This article traces Ansible's journey from a solution to these everyday headaches to becoming one of the most widely-used automation tools in modern DevOps.

At its core, Ansible is an open-source automation tool that handles configuration management, application deployment, and task automation. What sets it apart is its simplicity: it uses SSH for connectivity, requires no agents on managed nodes, and employs YAML for defining automation tasks.

Chapter 1: The genesis of Ansible​

The IT landscape before Ansible​

Before Ansible emerged, we were stuck with limited options. Tools like Puppet and Chef were powerful but came with significant overhead:

• They required agents on every managed node
• Had steep learning curves with their DSLs (Domain Specific Languages)
• Needed complex master-slave architectures
• Required significant bootstrap configuration

For many teams, this meant either sticking with manual processes or investing heavily in training and infrastructure setup before seeing any benefits.

The founding of Ansible​

In 2012, Michael DeHaan, who previously worked on tools like Cobbler at Red Hat, created Ansible with a radical approach: what if we could have powerful automation without all the complexity? DeHaan founded Ansible, Inc. with a clear vision of making automation accessible to everyone, not just specialized teams.

YouTube video of Michael DeHaan on Ansible, back in 2014

What really resonated with developers and sysadmins was Ansible's core philosophy:

• Agentless Architecture: Using existing SSH infrastructure meant no new security concerns
• YAML-Based: Writing automation in YAML made it readable even for non-programmers
• Push-Based Model: Instead of agents polling for changes, control nodes push changes when needed
• Idempotency: Running the same playbook multiple times produces the same result

This approach was revolutionary because it aligned with Unix philosophy: do one thing well, make it simple, and make it work with other tools.

Ansible's first commit by mpdehaan

Chapter 2: Ansible's rise to prominence​

Early reception and adoption​

When Ansible was first released, the response from the community was overwhelmingly positive. The tool's simplicity and effectiveness resonated strongly with users. Unlike its competitors, Ansible didn't require a steep learning curve or complex infrastructure changes. This accessibility led to rapid adoption, especially among teams looking for a straightforward solution to automate their workflows.

Ansible's agentless architecture and use of SSH were game-changers. While tools like Puppet and Chef were powerful, they required agents and complex configurations. Ansible's approach was different: it was lightweight, easy to set up, and didn't require additional software on managed nodes. This made it particularly appealing to teams that needed to scale quickly without the overhead of managing additional infrastructure.

Key milestones in development​

• The Release of Ansible 1.1 (2013).
• Introduction of major features: Over time, Ansible introduced Playbooks, roles, and modules, which significantly enhanced its functionality. Playbooks allowed users to define complex automation tasks in a simple, readable format, while roles and modules provided reusable components that streamlined automation processes.

The Open Source Community​

Ansible's success can be largely attributed to its vibrant open-source community. Contributors from around the world played a crucial role in shaping the tool, expanding its capabilities, and integrating it with other technologies. The community-driven development model ensured that Ansible remained relevant and adaptable to the ever-changing needs of IT automation.

Ansible's commits over time

Expansion of modules and integrations​

The growth of Ansible's module library was a testament to its flexibility and extensibility. With modules for managing everything from cloud infrastructure to network devices, Ansible became a versatile tool that could handle a wide range of automation tasks. This expansion was driven by both community contributions and strategic partnerships, further solidifying Ansible's position as a leader in the automation space.

Ansible's modules (source: Coding Ninjas)

Chapter 3: Red Hat's acquisition of Ansible​

The acquisition process (2015)​

In October 2015, the automation world was shaken by significant news: Red Hat had acquired Ansible for a staggering $150 million. This wasn't just another corporate acquisition; it represented a strategic move that would reshape the future of automation tools. Red Hat, already a powerhouse in the open-source world, saw in Ansible what many developers had already recognized - a tool that could revolutionize enterprise automation while maintaining its open-source roots.

The acquisition came at a crucial time in the automation landscape. Organizations were increasingly moving towards DevOps practices, and the need for simple, scalable automation tools was greater than ever. Red Hat's decision to acquire Ansible wasn't just about adding another tool to their portfolio; it was about embracing a philosophy that aligned perfectly with their vision of enterprise automation.

Key aspects of the acquisition included:

• Maintaining Ansible's open-source nature
• Integration with Red Hat's enterprise products
• Expansion of development resources
• Preservation of the existing community structure

The acquisition brought significant changes to Ansible's development. With Red Hat's resources, Ansible evolved from a community tool to an enterprise solution.

Ansible became deeply integrated with Red Hat's product lineup:

• OpenShift integration for container orchestration
• CloudForms integration for hybrid cloud
• Satellite integration for system management
• Integration with Red Hat Insights

Community response and challenges​

The acquisition wasn't without its challenges. The open-source community, always protective of its tools, expressed various concerns about Ansible's future.

The community's worries were legitimate and touched on several key points:

• Fear of commercialization affecting the open-source nature
• Worries about community contribution processes becoming more complex
• Questions about the future of free features
• Concerns about the tool's independence

Online reactions following the acquisition on Hacker News

Red Hat's response to these concerns was both swift and thoughtful. Drawing from their experience with other open-source projects, they:

• Maintained the upstream open-source project with full transparency
• Continued supporting and encouraging community contributions
• Created a clear separation between community and enterprise features
• Kept the development process transparent through public repositories

Chapter 4: Modern Ansible ecosystem and enterprise adoption​

The years following Red Hat's acquisition (and later IBM's acquisition of Red Hat in 2019) saw Ansible evolve from a configuration management tool into a comprehensive automation platform. This transformation wasn't just about adding features; it represented a fundamental shift in how organizations approach automation.

Ansible's ecosystem expanded significantly with several key projects:

• AWX (2017): The upstream open-source version of Ansible Tower, providing a web-based UI and REST API (docs)
• Ansible Galaxy and Collections (2019): A new content structure that revolutionized how Ansible content is created and shared (docs)
• Ansible Automation Platform (2020): Red Hat's enterprise solution for scaling automation across organizations (docs)
• Event-Driven Ansible (2023): Bringing automation to event-based workflows and real-time responses (docs)

Ansible became deeply embedded in DevOps practices and modern IT operations, offering comprehensive solutions:

DevOps practices across the application lifecycle:

• Infrastructure as Code: Teams use Ansible playbooks as living documentation of their infrastructure
• CI/CD Integration: Native integration with tools like Jenkins, GitLab, and GitHub Actions
• Configuration Management: Standardized configurations across development, testing, and production environments
• Application Deployment: Automated, repeatable deployment processes that reduce human error

Critical IT automation capabilities:

• Cloud Management: Orchestrating resources across multiple cloud providers
• Network Automation: Managing network infrastructure through code
• Security Automation: Implementing security policies and responding to threats
• Container Orchestration: Working alongside tools like Kubernetes for container management

Organizations from startups to enterprises now rely on Ansible to automate complex workflows, maintain consistency, and accelerate their digital transformation initiatives. Its ability to adapt to new technologies while maintaining its core simplicity has made it an indispensable tool in the modern IT landscape.

Chapter 5: The future of Ansible​

As Ansible continues to evolve, it faces both exciting opportunities and significant challenges. The platform is embracing AI and machine learning capabilities, with features like predictive analytics for system failures and intelligent automation for complex deployments. Infrastructure as Code is also advancing, with Ansible developing better abstractions for multi-cloud environments and deeper integration with modern DevOps workflows.

While pushing innovation forward, Ansible must carefully balance maintaining its core simplicity with adding advanced features. Technical challenges include scaling for complex infrastructure and ensuring security in distributed environments, while also keeping pace with rapid cloud provider changes and maintaining quality across its growing ecosystem. Looking ahead, Ansible's roadmap focuses on enhancing container orchestration and cloud-native capabilities in the short term, while working toward seamless hybrid cloud management and advanced AI-driven automation for the future.

What has become of Michael DeHaan?​

After stepping away from Ansible, Michael DeHaan maintains a personal blog at https://laserllama.substack.com/ where he writes about a variety of topics. His posts range from tech reviews and IT industry news (Apple Pro XDR Monitor) to more niche content, such as yard sprinklers or ... rabbits in his garden.

Michael DeHaan's rabbits in the garden

He is also active on Bluesky and LinkedIn, where last year he said he wanted to create a new IT automation system built in Rust with "scalability, high performance, audit features, and a return to minimalism." Well, this project sounds very familiar.

Michael DeHaan's new project

Conclusion​

Ansible's journey from a simple automation tool to a comprehensive automation platform demonstrates several important lessons:

1. Simplicity wins: Ansible's success stems from its commitment to keeping things simple and accessible
2. Community matters: The vibrant community has been crucial to Ansible's growth and adaptation
3. Enterprise support: Red Hat's backing has provided the stability needed for enterprise adoption
4. Continuous innovation: Regular updates and new features keep Ansible relevant in a changing landscape

As automation becomes increasingly central to modern infrastructure management, Ansible's role continues to evolve. Its combination of simplicity, flexibility, and enterprise support positions it well for future challenges in automation and infrastructure management.

Modern Ansible integration with Windmill​

Today, Ansible continues to evolve through various platforms and integrations. One notable example is Windmill, which provides native support for Ansible playbooks alongside other scripting languages.

Windmill extends Ansible's capabilities by adding features like version control for playbooks, auto-generated UIs, webhook triggers, and seamless integration with other automation tools. It simplifies Ansible usage by handling inventory management, dependency installation, and resource management through a web-based IDE, while maintaining Ansible's core philosophy of simplicity and accessibility.

Further reading and resources​

For developers looking to deepen their Ansible knowledge:

• Official Ansible Documentation
• Ansible Galaxy
• Ansible Blog
• Red Hat Ansible Automation Platform

Windmill is an open-source and self-hostable serverless runtime and platform combining the power of code with the velocity of low-code. We turn your scripts into internal apps and composable steps of flows that automate repetitive workflows.

You can self-host Windmill using a docker compose up, or go with the cloud app.

Born for the web, Markdown is the darling of platforms like GitHub, Stack Overflow, and Reddit. In this guide, we'll explore how to use Markdown in React applications using the react-markdown package.

Markdown basics​

Let's dive into the essentials of Markdown syntax:

Headings​

To create headings, use number signs (#). The more signs, the smaller the heading:

# Big Boss Heading
## Slightly Smaller Boss
### Middle Management
#### Team Lead
##### Senior Dev
###### Junior Dev

This will be rendered as:

Big Boss Heading

Slightly Smaller Boss

Middle Management

Team Lead

Senior Dev

Junior Dev

Remember to include a space between the hash and your text.

Lists​

Markdown supports both ordered and unordered lists:

Ordered Lists:

1. Banana
2. Kiwi

This will be rendered as:

1. Banana
2. Kiwi

Unordered Lists:

- Banana
- Kiwi

* Banana
* Kiwi

+ Banana
+ Kiwi

This will be rendered as:

• Banana
• Kiwi

• Banana
• Kiwi

• Banana
• Kiwi

Links​

Create links using square brackets for text and parentheses for the URL:

[Windmill](https://www.windmill.dev/)

This will be rendered as:

Windmill

Images​

Add images with an exclamation mark, alt text in brackets, and the path in parentheses:

![Windmill logo](https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcTXrLXCq_Qrr9X9Yavf8jF3AonwSqLgHmAIKA&s)

This will be rendered as:

Typography​

Style text using asterisks:

**Bold move**
*Italic flair*

This will be rendered as:

Bold move Italic flair

Understanding react-markdown​

The react-markdown package transforms Markdown into React components that render as HTML in your app. Unlike other libraries that use dangerouslySetInnerHTML, react-markdown creates a syntax tree for a virtual DOM, making it both safer and more efficient.

Installation​

First, ensure you have Node.js installed, then create a new React project:

npx create-react-app markdown-app
cd markdown-app
npm install react-markdown

Basic implementation​

Here's a simple example of using react-markdown:

import React from 'react'
import ReactMarkdown from 'react-markdown'

export default function App() {
  return (
    <div>
      <ReactMarkdown>
        # Hello, *world*!
      </ReactMarkdown>
    </div>
  )
}

Advanced features​

Custom components​

You can customize how specific Markdown elements are rendered using the components prop:

import React from 'react'
import ReactMarkdown from 'react-markdown'

const CustomH1 = ({node, ...props}) => (
  <h1 style={{color: 'blue'}} {...props} />
)

export default function App() {
  return (
    <div>
      <ReactMarkdown
        components={{
          h1: CustomH1
        }}
      >
        # This heading will be blue
      </ReactMarkdown>
    </div>
  )
}

Plugins and extensions​

React Markdown supports various plugins through the unified ecosystem. Here's how to add syntax highlighting with react-syntax-highlighter:

npm install react-syntax-highlighter

Implementation example:

import React from 'react'
import ReactMarkdown from 'react-markdown'
import {Prism as SyntaxHighlighter} from 'react-syntax-highlighter'
import {dark} from 'react-syntax-highlighter/dist/esm/styles/prism'

export default function App() {
  const markdown = `\`\`\`javascript
const hello = 'world';
console.log(hello);
\`\`\``

  return (
    <ReactMarkdown
      components={{
        code({node, inline, className, children, ...props}) {
          const match = /language-(\w+)/.exec(className || '')
          return !inline && match ? (
            <SyntaxHighlighter
              style={dark}
              language={match[1]}
              PreTag="div"
              {...props}
            >
              {String(children).replace(/\n$/, '')}
            </SyntaxHighlighter>
          ) : (
            <code className={className} {...props}>
              {children}
            </code>
          )
        }
      }}
    >
      {markdown}
    </ReactMarkdown>
  )
}

Handling images and links​

You can customize how images and links are rendered:

import React from 'react'
import ReactMarkdown from 'react-markdown'

export default function App() {
  return (
    <ReactMarkdown
      components={{
        img: ({node, ...props}) => (
          <div style={{ textAlign: 'center', margin: '20px 0' }}>
            <img
              {...props}
              style={{
                maxWidth: '70%',
                borderRadius: '8px',
                boxShadow: '0 4px 8px rgba(0,0,0,0.1)',
                transition: 'transform 0.2s',
                cursor: 'pointer',
              }}
              onMouseOver={(e) => e.target.style.transform = 'scale(1.05)'}
              onMouseOut={(e) => e.target.style.transform = 'scale(1)'}
              loading="lazy"
              onError={(e) => {
                e.target.src = 'fallback-image-url.jpg'
                e.target.alt = 'Failed to load image'
              }}
            />
          </div>
        ),
        a: ({node, children, href, ...props}) => (
          <a
            href={href}
            target="_blank"
            rel="noopener noreferrer"
            style={{
              color: '#0066cc',
              textDecoration: 'none',
              borderBottom: '1px solid transparent',
              transition: 'border-bottom-color 0.2s',
            }}
            onMouseOver={(e) => e.target.style.borderBottomColor = '#0066cc'}
            onMouseOut={(e) => e.target.style.borderBottomColor = 'transparent'}
            onClick={() => console.log(`Link clicked: ${href}`)}
            {...props}
          >
            {children} ↗️
          </a>
        )
      }}
    >
      # Handling images and links
      
      ![Example Image](https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcTXrLXCq_Qrr9X9Yavf8jF3AonwSqLgHmAIKA&s)
      
      [Visit Windmill](https://www.windmill.dev/)
    </ReactMarkdown>
  )
}

Build custom UIs with Windmill​

This completes our guide on using React Markdown in your applications.

For teams looking to create content-rich applications, Windmill's App editor offers a compelling alternative to developing custom apps in React. While React requires coding Markdown implementations from scratch and managing complexities like component styling and rendering, Windmill simplifies these aspects.

The low-code App builder is designed to create custom User Interfaces by combining drag-and-drop functionality with code. It comes with +60 components that you can style and link to scripts and flows. We even have a ... Markdown component. Additionally, it supports the integration of custom React components and even entire React apps, providing flexibility for more advanced development needs.

This enables faster development with less overhead, making it a practical choice for projects where quick deployment and ease of maintenance are priorities.

Windmill is an open-source and self-hostable serverless runtime and platform combining the power of code with the velocity of low-code. We turn your scripts into internal apps and composable steps of flows that automate repetitive workflows.

You can self-host Windmill using a docker compose up, or go with the cloud app.

What is SMTP​

SMTP (Simple Mail Transfer Protocol) defines the protocol for transmitting emails. The general flow of an email from sender to recipient is as follows:

• The sender's email client sends the email to its configured SMTP server (e.g., Apple Mail to smtp.gmail.com for a Gmail sender's address).
• The sender's SMTP server then checks the recipient's email domain and sends the email to the corresponding SMTP server.

Note: The recipient's email client then retrieves the email from the recipient's SMTP server, typically using POP or IMAP.

The usual flow involves two SMTP exchanges:

sender_email_client \<-> sender_smtp_server \<-> recipient_smtp_server

In this article, we will focus on implementing the receiving part of the SMTP server, specifically receiving emails from other SMTP servers. The protocol for receiving emails from either email clients or other SMTP servers is the same; the only difference lies in the port used and the security process, which we will cover later.

A receiving SMTP server listens on a port for incoming TCP connections. Once connected, the sender's SMTP server sends commands to the receiving SMTP server. Our server needs to interpret these commands and respond appropriately.

Once the email content is received, we can process or store it as needed. In the context of Windmill, once we receive an email, we check the email address and trigger the appropriate runnable (script, flow) with the email content as an argument.

When SMTP servers communicate, they typically do so on port 25, and by default, this connection is not encrypted. Therefore, we will also implement STARTTLS, which upgrades the connection to a secure TLS connection, ensuring that the email content is encrypted in transit.

Note: Modern email clients (e.g., when sending an email from your computer) connect to SMTP servers on port 587 (or 465) directly over TLS.

What is Windmill​

For context, Windmill is an open-source workflow engine and developer platform. It's an alternative to the likes of Retool, Superblocks, n8n, Airflow, Prefect, and Temporal, designed to build comprehensive internal tools (endpoints, workflows, UIs).

This article was written following the implementation of the Email triggers feature, which allows scripts and flows to be triggered by sending emails to a specific email address.

Listening for incoming connections​

Let's use tokio to listen for TCP connections on port 2525 (in production, it should be exposed on port 25, which we will discuss later). We handle each incoming connection in a separate task using tokio::spawn to avoid blocking the listener thread.

use tokio::net::{TcpListener, TcpStream};
use tokio::io::{AsyncBufReadExt, AsyncWriteExt, BufReader, BufWriter};
use std::net::SocketAddr;

async fn listen() -> anyhow::Result<()> {
    let addr = SocketAddr::from(([127, 0, 0, 1], 2525));
    let listener = TcpListener::bind(addr).await?;

    tracing::info!("SMTP server listening on {}", addr);

    loop {
        match listener.accept().await {
            Ok((stream, _)) => {
                tokio::spawn(async move {
                    if let Err(err) = handle_connection(stream).await {
                        tracing::error!("Error handling SMTP connection: {:?}", err);
                    };
                });
            }
            Err(err) => {
                tracing::error!("Error establishing SMTP connection: {:?}", err);
            }
        }
    }
}

After establishing the connection, the server needs to send a 220 My SMTP server response to the client. This response indicates the server is ready to accept and process further commands from the client. The text after the code My SMTP server can be customized.

async fn handle_connection(stream: &mut TcpStream) {
    let (reader, writer) = stream.split();
    let mut reader = BufReader::new(reader);
    let mut writer = BufWriter::new(writer);
    writer.write_all(b"220 My SMTP server\r\n").await?;
    writer.flush().await?;

    // handle session 
}

Implementing the SMTP exchange loop​

Once the sender (server or client) connects, it begins sending commands. You can find the full list of possible commands in RFC 5321.

A simplified flow of commands could be:

- Sender: EHLO
- Receiver: 250 OK
- Sender: MAIL FROM: \<sender@mysenderdomain.com>
- Receiver: 250 OK
- Sender: RCPT TO: \<receiver@myreceiverdomain.com>
- Receiver: 250 OK
- Sender: DATA
- Receiver: 354 End data with \<CR>\<LF>.\<CR>\<LF>
- Sender: Subject: Test email
- Sender: Test email content
- Sender: .
- Receiver: 250 OK
- Sender: QUIT
- Receiver: 221 Bye

The sequence of commands is straightforward: the client begins with a greeting, specifies the sender and recipient, and then transmits the email content. To transmit the email content, the client issues the DATA command. Everything sent after this command is considered part of the email content until a single dot . on a line by itself signals the end of the email. Upon receiving the complete email, the receiver responds with a 250 OK if the email was successfully received. Finally, the client sends the QUIT command to terminate the connection.

The following code implements the SMTP exchange. It processes commands one by one, with commands separated by a line break \r\n. At the start, the state is SmtpState::Command, we then process the command and depending on it, we store the received data if any, and update the state. We have three states:

• SmtpState::Command: The state after the connection is established and the client is waiting for a command.
• SmtpState::Data: The state after the DATA command has been received and the email content is being accumulated.
• SmtpState::Quit: The state after the QUIT command has been received, the connection is closed.

We use Framed with LinesCodec from the tokio-util crate to split the stream by lines. We use regular expressions to parse the sender and receiver addresses.

For each command, we check if it is valid and respond accordingly. If the command is valid, we send a response to the client with the appropriate code from RFC 5321. The message following the code is customizable. If the command results in an error, such as an invalid command or attempting to send an email before specifying the recipient, we send the corresponding error code and message to the client.

use tokio_util::codec::{Framed, LinesCodec, LinesCodecError};
use futures::{stream::iter, SinkExt, StreamExt};

async fn handle_session(mut stream: TcpStream) -> anyhow::Result<()> {
    let RE_SMTP_MAIL = regex::Regex::new(r"(?i)from: ?<(.+)>").unwrap();
    let RE_SMTP_RCPT = regex::Regex::new(r"(?i)to: ?<(.+)>").unwrap();
    let mut message = String::new();
    let mut state = SmtpState::Command;
    let mut mailfrom: Option<String> = None;
    let mut rcpts: Vec<String> = Vec::new();
    let mut framed = Framed::new(stream, LinesCodec::new());
    while let Some(line_str) = framed.next().await {
        let line = line_str?;
        match state {
            SmtpState::Command => {
                let space_pos = line.find(" ").unwrap_or(line.len());
                let (command, arg) = line.split_at(space_pos);
                let arg = arg.trim();
                match &*command.trim().to_uppercase() {
                    "HELO" | "EHLO" => {
                        send_commands(&mut framed, vec!["250 Hello".to_string()]).await?;
                    }
                    "MAIL" => {
                        // Handle MAIL FROM command
                        if let Some(address) = RE_SMTP_MAIL.captures(arg).and_then(|cap| cap.get(1)) {
                            mailfrom = Some(address.as_str().to_string());
                            send_commands(&mut framed, vec!["250 OK".to_string()]).await?;
                        } else {
                            send_commands(&mut framed, vec!["501 Syntax: MAIL From: <address>".to_string()]).await?;
                        }
                    }
                    "RCPT" => {
                        // Handle RCPT TO command
                        if mailfrom.is_none() {
                            send_commands(&mut framed, vec!["503 Error: Send MAIL first".to_string()]).await?   ;
                        } else {
                            if let Some(address) = RE_SMTP_RCPT.captures(arg).and_then(|cap| cap.get(1)) {
                                rcpts.push(address.as_str().to_string());
                                send_commands(&mut framed, vec!["250 OK".to_string()]).await?;
                            } else {
                                send_commands(&mut framed, vec!["501 Syntax: RCPT TO: <address>".to_string()]).await?;
                            }
                        }
                    }
                    "DATA" => {
                        if rcpts.is_empty() {
                            send_commands(&mut framed, vec!["503 Error: MAIL FROM and RCPT TO must be set before sending DATA".to_string()]).await?;
                        } else {
                            state = SmtpState::Data;
                            send_commands(&mut framed, vec!["354 End data with <CR><LF>.<CR><LF>".to_string()]).await?;
                        }
                    }
                    "NOOP" => {
                        send_commands(&mut framed, vec!["250 OK".to_string()]).await?   ;
                    }
                    "RSET" => {
                        mailfrom = None;
                        rcpts = Vec::new();
                        message = String::new();
                        send_commands(&mut framed, vec!["250 OK".to_string()]).await?;
                    }
                    "QUIT" => {
                        send_commands(&mut framed, vec!["221 Bye".to_string()]).await?;
                        state = SmtpState::Quit;
                    }
                    _ => {
                        send_commands(&mut framed, vec!["500 Unknown command".to_string()]).await?;
                    }
                }
            }
            SmtpState::Data => {
                if line.trim() == "." {
                    // The end of the email content has been received
                    send_commands(&mut framed, vec!["250 OK".to_string()]).await?;
                    // reset the state and variables for the next email
                    mailfrom = None;
                    rcpts = Vec::new();
                    message = String::new();
                    state = SmtpState::Command;
                    // we can now handle the email:
                    handle_email(mailfrom, rcpts, message);
                } else {
                    // Add the received line to the email content
                    message.push_str(&line);
                    message.push_str("\n");
                }
            }
            SmtpState::Quit => {
                break;
            }
        }
    }
}