Callables vs Windmill and Airplane: a repo-first alternative

If you've looked for a way to turn scripts into internal tools, you've probably come across Windmill, and maybe used Airplane before it shut down. Both are good products built by people who understood the problem. Callables solves the same problem from a different starting point, and this post explains where they differ so you can pick what fits.

Airplane

Airplane let developers turn scripts into internal tools: you wrote tasks in code, deployed them with a CLI, and your team ran them from generated forms, with schedules, permissions and run history. Many teams loved it. Airtable acquired the company in early 2024, and the product shut down on March 1, 2024, leaving its users to find somewhere else to go.

Callables follows the same idea Airplane got right: the code is the source of truth, and the interface is generated from it. If you used Airplane for Python tasks, a Callables function will feel familiar: a typed function with a decorator becomes a form, a schedule and a run history.

The main difference is how code gets deployed. Airplane deployed from your machine with its CLI. Callables connects to GitHub and deploys on every push, so what's running is always what's on your branch, and anyone who can push can ship a change.

Windmill

Windmill is a broad, open-source platform: scripts in more than 20 languages, flows with retries, approvals and parallel branches, a low-code app builder, triggers, AI agents, and the option to self-host. It's a strong choice if you want one platform for workflows, internal apps and data pipelines.

Its center of gravity is the Windmill workspace. You can write code in its built-in editor with its AI tools, or locally with its CLI and VS Code extension and sync it in. Either way, the code follows Windmill's layout: each script is a main function with its own metadata file and lockfile, kept in sync with a workspace.

Callables starts from the other end. Your repo is the product. There's no workspace to sync and no project layout to adopt:

• Add @deploy to functions in the project you already have, with its own requirements.txt or pyproject.toml.
• Write them in your own editor, with your own AI agent. call init adds instructions for Claude Code, Cursor and other agents, so they know how to write, check and run Callables functions. See building with AI agents.
• Check and run them locally with call check and call local, then push. Every push to your branch deploys.

from typing import Literal

from callables import deploy


@deploy(title="Refund an order", secrets=["STRIPE_KEY"])
def refund(
    order_id: str,
    reason: Literal["duplicate", "fraud", "other"] = "duplicate",
) -> str:
    """Refunds the order in full and emails the customer."""
    ...

That function is the whole setup. Your team gets a form with a text box and a dropdown, the result, and a history of every run.

Pricing

Pricing reflects the different approaches.

Windmill charges per seat plus compute. On its published Enterprise example, people who build cost $20 a month each, people who only run things cost $10, and each standard worker is a $50-a-month compute unit. The open-source edition is free to self-host, and the cloud Team plan is billed on usage. Check Windmill's pricing page for current numbers.

Callables has no per-seat price. Pro is $20 a month per team, with $20 of usage included and unlimited people, so adding the ops team who just runs things doesn't change the bill. Hobby is $5 a month for your own scripts and a few teammates, and every team starts with a 30-day trial with no card required. See pricing.

At a glance

When Windmill is the better fit

Choose Windmill if you need to self-host, want visual multi-step flows or a drag-and-drop app builder, or write automations in many languages. Those are real strengths, and Callables doesn't try to match them.

When Callables is the better fit

Choose Callables if your automations are Python that already lives in a repo, you want to keep writing them in your own editor with your own agent, and you want the people who run them, not just the people who write them, on the team without paying per seat. Write a function, push it, and your team has a tool.