DOCSEARCHbyAlgolia
Submit Docs

Windmill Developer Platform

website·Indexed 35 days ago

https://www.windmill.dev/docs/intro

An open-source and self-hostable workflow engine and developer platform for building, orchestrating, and monitoring internal software. Features include a CLI (wmill) for workspace management, browser automation with Playwright, Git sync for bidirectional deployment, and client libraries for Python, Rust, and TypeScript.

Tokens
288.5K
Snippets
966
Records
2.3K
Agent score
72%

What's inside Windmill

  1. Overview of AgGrid table in Windmill

    The AgGrid table component is a wrapper around the AgGrid library, providing advanced data grid features. It is distinct from the standard Table component (which is simpler and uses object keys as headers) and the Database Studio (a full database management tool). AgGrid requires two primary inputs to function: rowdata and column definitions.

  2. Overview of Kafka triggers in Windmill

    Windmill can connect to Kafka broker servers to trigger runnables (scripts or flows) upon receiving messages. Listening is performed by the server, meaning it does not consume worker resources. This is a self-hosted Enterprise feature.

  3. Overview of Windmill AI sessions

    AI sessions are full-page environments that tie an AI chat to a specific workspace or workspace fork. They provide a live preview panel where the AI creates and edits scripts, flows, and full-code apps as drafts. Users can review diffs and deploy these changes once satisfied. AI sessions are enabled by default for most users (except Operators) and replace the legacy AI chat side panel.

  4. Overview of Windmill MCP capabilities

    Windmill supports the Model Context Protocol (MCP), enabling LLMs to interact with Windmill workspaces. When connected, an LLM can trigger scripts and flows and access API endpoints for the following operations:

    • Jobs: Monitor/manage executions, track progress, retrieve logs, and view results.
    • Resources: Create, read, update, and delete third-party system connections (e.g., databases, APIs).
    • Variables: Manage workspace variables and secrets.
    • Schedules: Control CRON-like automation for scripts and flows.
    • Workers: Monitor worker status, groups, and resource allocation.

  5. Overview of Windmill Email Triggers

    Windmill allows scripts and flows to be triggered by sending email messages to specific email addresses via SMTP. On the Community Edition, email triggers are limited to 100 emails per day.

  6. Overview of Windmill Runnable types

    Windmill provides five types of runnables to handle logic and data within an app:

    • Inline scripts: Scripts defined directly in the app editor, which can be attached to a component or detached.
    • Workspace/Hub runnables: Scripts or flows defined in the broader workspace or the Windmill Hub and linked to a component.
    • Background runnables: Server-side scripts not linked to a specific component. They run in the background and can be triggered on app refresh or input changes.
    • Frontend scripts: JavaScript executed in the browser. They can be linked to components or act as background runnables (though background frontend scripts only run if manually set to run on start/reload).
    • Evals: Used to connect data sources to components or parameters. They are automatically evaluated when their identified output dependencies change.

  7. Overview of Windmill Native Triggers

    Native triggers enable external services to push real-time events directly to Windmill via webhooks, triggering scripts or flows immediately. This is an alternative to scheduled polling. Currently, Windmill supports native triggers for Nextcloud (file, folder, and calendar events) and Google (Drive and Calendar events).

  8. Overview of Windmill Schedules

    Windmill provides a UI-based scheduler for Scripts and Flows that replaces the need for manual CRON management. A Schedule consists of a Script or Flow, its arguments, a CRON expression for frequency, and optional Error and Recovery Handlers for failed executions. Unlike standard system cron, Windmill provides built-in run history, centralized UI for permissions, and integrated error handling/notifications.

  9. Overview of Windmill Workspace Dependencies

    Workspace dependencies allow for central management of dependencies at the workspace level. By creating shared dependency files, multiple scripts can reference the same set of packages, ensuring consistent environments and controlled dependency resolution across the workspace.

  10. Overview of GCP Pub/Sub triggers

    Windmill can connect to Google Cloud Pub/Sub to trigger runnables (scripts or flows) when messages are published on topics. It supports both Pull (Windmill consumes messages) and Push (GCP pushes messages to auto-generated endpoints) delivery types. This is a self-hosted Enterprise feature.

  11. Overview of Windmill Full-code apps

    Full-code apps allow developers to build custom frontends using React or Svelte that connect to Windmill backend runnables and data tables. Unlike low-code apps, full-code apps provide complete control over the UI, allowing for custom CSS (including Tailwind), complex interactions, and the use of full framework features like hooks, stores, and routing. The frontend communicates with the Windmill execution engine via a WebSocket connection through an auto-generated wmill.ts module.

  12. Overview of Windmill Assets

    Assets in Windmill track data flows and visualize data sets by automatically detecting references in code. They power asset lineage and pipelines, where writing to an asset can automatically trigger scripts that read from it. Assets are referenced using specific URIs:

    • S3 objects: s3://storage/path/to/file.csv
    • Resources: res://path/to/resource
    • Volumes: volume://name
    • dbt models: dbt://warehouse/schema/model

    Currently, assets are supported for Python, JavaScript, TypeScript, and DuckDB. Volume assets are an exception; they are detected via volume: annotations in any language, including PHP and Go.