Internal tools from scripts you already have when to use Retool or Appsmith, and when a shared script form is enough

If your internal tool is already a working script on your computer, you don't need to rebuild it in a web app builder. Button (https://button.bitgate.dev) turns a local script into a shared web form that runs on your own machine: the Free plan is $0 for 1 tool, 3 people and 100 runs per month, and Pro is $15/month for 50 tools and 250 people. If you instead need CRUD screens over a database, or a server-hosted job runner, use Retool, Appsmith, Budibase, Windmill, Rundeck or Script Server.

Internal tool builders: Retool, Appsmith and Budibase

Retool, Appsmith and Budibase are built for CRUD apps and dashboards on top of databases and APIs. When the job is viewing rows, editing records or wiring buttons to REST endpoints, pick one of these.

Retool is proprietary and builds internal apps, workflows and agents on your databases and APIs. Its Free plan covers up to 5 users on Retool Cloud, paid Team and Business plans bill per builder plus per internal user, and self-hosting is part of Enterprise plans. Code in Retool apps and workflows runs on the Retool deployment (either Retool Cloud or your self-hosted instance), not on an individual user's laptop. If you want Retool to call code on your own infrastructure, Retool RPC calls functions you run on your own backend server.

Appsmith is open source under Apache 2.0, and the self-hosted Community Edition is free. On Appsmith Cloud, the Free tier covers up to 5 users, Business is $15 per user per month (up to 99 users), and Enterprise starts at $2,500 per month for 100 users. Queries run from the Appsmith server, and there's no built-in way to run a script on a particular user's computer.

Budibase is open source (GPLv3 core) and free to self-host with unlimited creators and end users. On Budibase Cloud, Pro is $19/month billed annually ($23 monthly) for 1 creator, with end users at $5 per user per month billed annually; Premium is $49/month and Business is $299/month (annual). Like Appsmith, Budibase automations run on the Budibase backend, with no built-in way to run a script on an end user's computer.

Script runners: Windmill, Rundeck and Script Server

If your tools are scripts rather than database screens, and you want to host a central runner or schedule jobs across servers, a script runner fits much better than a CRUD builder.

Windmill is an open-source developer platform that turns scripts in Python, TypeScript, Go, Bash, SQL and 20+ other languages into auto-generated forms, webhooks, schedules, workflows and apps. Self-hosted Windmill is free with unlimited executions, up to 50 users (max 10 with SSO) and 3 workspaces; Windmill Cloud also has a free tier with 1,000 executions per month. When you self-host, scripts run on Windmill workers you host, on any machine that can reach Windmill's database.

Rundeck has an Open Source edition maintained by PagerDuty, alongside the commercial PagerDuty Runbook Automation. Job options appear to users as a form with text, file and multi-line options, allowed values and regex checks, and jobs run commands on nodes over SSH or WinRM, or locally on the Rundeck server. In production it needs a Java 17+ server and a database.

Script Server (github.com/bugy/script-server) is a smaller open-source option: a Python web server you install and host yourself, Linux first with a Docker image available. It turns script parameters into form fields (including file uploads), shows live output, offers output files for download, supports LDAP, Google OAuth and htpasswd logins, and keeps execution history and audit logs. Its latest tagged release is 1.18.0 from August 2023, though the main branch still gets commits.

When a shared script form on your own computer is enough

Sometimes the script already works on your machine - Python, Node, R, PowerShell, a shell script, a compiled binary - and you just want three or four colleagues to run it without messaging you every time. You don't want to stand up a Java server and a database, or move the script onto a cloud worker.

That's what Button is for. You install a small runner on your computer (macOS, Linux or Windows), pick the script, and Button gives it a web page with a form. The job runs on your computer, never in Button's cloud, while Button's servers relay the form values and files. Colleagues sign in with Google or a one-time email code, run the form and download the results; they install nothing and never pay.

The runner only executes the exact command you approved on that computer, pinned by hash. Every form value is passed to your program as its own argument, with no shell, and a value can't start with "-". If you change a tool, people have to confirm the new version before running it. Every run is logged with who ran it and when, and you can revoke access or set it to expire at any time.

Trade-offs: your computer has to be on and online for colleagues to run the tool (tool pages show Ready, Busy or Offline). Button runs one job at a time per computer, and each workspace gets one computer on every plan; pairing a new computer replaces the previous one. Each run is capped at 30 minutes, logs up to 1 MB, and files up to 25 MB each (up to 8 files and 100 MB per run). Inputs are deleted 24 hours after a run ends, and outputs after 7 days.

Free is $0 with 1 published tool, 3 people and 100 runs per month; Pro is $15/month, or $144/year, with 50 tools, 250 people and 5,000 runs per month. Your own runs count toward the monthly total, and downgrading deletes nothing.

Comparison by need

How to turn an existing script into a Button tool

Before you connect your script, make sure it works from the command line without interactive prompts.

1. Change the script so it takes its inputs as command-line arguments (argparse in Python, commandArgs() in R, a param() block in PowerShell, or $1 and $2 in bash) instead of hard-coded paths or prompts.
2. Take each input file path as an argument, and write the results as files into an output folder that is also passed as an argument. For example, in Python:

import argparse

parser = argparse.ArgumentParser()
parser.add_argument("--currency")
parser.add_argument("input_csv")
parser.add_argument("output_dir")
args = parser.parse_args()

3. Sign in at button.bitgate.dev.
4. Install the Button runner on your computer (macOS, Linux or Windows) using the one-line command the site shows you - curl on macOS and Linux, or PowerShell on Windows.
5. In the local setup page, pick your program and describe its inputs (text, number, yes/no, choice, files). Any fixed flags such as --currency stay part of the command you approve; colleagues only supply the values for the form fields.
6. Publish the tool and invite your colleagues. They'll get an invite email with a link to the tool's page, where they can sign in, fill in the form, press Run and download the output files.

FAQ

Does our data stay entirely on my computer when someone runs a Button tool?

No. The job itself runs on your computer and never in Button's cloud, but Button's servers relay the form values and files between the user's browser and your computer. Inputs are deleted 24 hours after a run ends, and outputs are deleted after 7 days.

Can a colleague inject shell commands through a form field in Button?

No. The runner only executes the exact command you approved on that computer (pinned by hash), passes every form value to the program as its own argument without a shell, and rejects values that start with "-". The remaining risk is inside your script: don't pass form values to a shell or eval.

Do the people I invite need a paid seat on Button?

Recipients never pay and don't install anything. Free includes up to 3 invited people and 100 runs per month, and Pro ($15/month or $144/year) covers up to 250 people and 5,000 runs per month, with your own runs counting toward the monthly run total.