Let non-developers run a GitHub Actions workflow with inputs? workflow_dispatch limits, and a simpler form for colleagues

Non-developers can run a workflow_dispatch workflow in GitHub Actions if you give them a GitHub account and write access to the repository, and if they don't need to upload files. If you want a plain web form where colleagues can also upload files, Button (https://button.bitgate.dev) turns a script on your own computer into a page you can share by email, with file inputs up to 25 MB each and a free tier that covers 1 tool, 3 people and 100 runs per month (or Pro at $15/month for 50 tools and 250 people).

How workflow_dispatch works and where it gets awkward

Putting on: workflow_dispatch at the top of a workflow file gives you a "Run workflow" button in the GitHub Actions tab. You can define up to 25 inputs (GitHub raised the limit from 10 in December 2025), and each input can be a string, number, boolean, choice or environment.

For engineers who already live in GitHub, this works fine. It gets awkward when you hand it to someone in finance or ops, for a few reasons:

• To see the "Run workflow" button, the person running it has to have a GitHub account and write access to the repository.
• There is no file upload input type. If the script needs a CSV or PDF from a teammate's desktop, workflow_dispatch has nowhere for them to drop it.

Here is what a typical workflow_dispatch header looks like in .github/workflows/run-script.yml:

name: Run monthly script
on:
  workflow_dispatch:
    inputs:
      month:
        description: "Month to process"
        required: true
        type: choice
        options:
          - Jan
          - Feb
          - Mar
      dry_run:
        description: "Dry run"
        required: false
        type: boolean
        default: false
jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: python3 script.py "$MONTH" "$DRY_RUN"
        env:
          MONTH: ${{ inputs.month }}
          DRY_RUN: ${{ inputs.dry_run }}

Passing inputs through env rather than pasting ${{ inputs.month }} straight into the run line keeps a typed value from being read as shell code.

If you want to set this up for a colleague in GitHub, the steps are:

1. Commit that workflow file to the repository's default branch.
2. Have your colleague create a GitHub account if they don't have one.
3. Grant their account write access to the repository.
4. Show them how to open the repository, click the Actions tab, select the workflow on the left, open the "Run workflow" dropdown, fill in the fields and trigger the run.

When to stay on GitHub Actions vs when to use Button

Stick with workflow_dispatch when the people running the job are already in your repository with write access, when you don't need them to upload files, when you want the job to run on GitHub-hosted runners without relying on your own machine being awake, or when a single job takes more than 30 minutes (GitHub Actions allows up to 6 hours on GitHub-hosted runners and up to 5 days on self-hosted runners).

Use Button when you're sharing a script with finance or ops people who shouldn't have write access to a repo (or a GitHub account at all), when they need to upload files as inputs and download the output files, and when you're happy for the script to run on your own computer.

Turning your script into a web form with Button

Button runs whatever program you already have on your computer - Python, Node, R, PowerShell, shell scripts or compiled binaries - and puts a web form in front of it. Your computer does the actual execution; Button's servers only relay the form inputs and files between your colleague's browser and your machine.

Step 1: Make sure the script takes command-line arguments

Before you set up Button, check that your script takes its inputs as command-line arguments rather than reading hard-coded file paths or stopping for interactive prompts. You can use argparse in Python, commandArgs() in R, a param() block in PowerShell, or $1 and $2 in bash.

If the script reads files or produces files for your colleague to download, take each input file path as an argument and write the result files into an output folder whose path is also passed in as an argument. Any fixed flags you use, like --month, become part of the base command you approve on your machine; your colleagues only fill in the values for the form fields.

Here is a minimal Python example:

import argparse

parser = argparse.ArgumentParser()
parser.add_argument("--input-file", required=True)
parser.add_argument("--month", required=True)
parser.add_argument("--output-dir", required=True)
args = parser.parse_args()

Step 2: Install the Button runner and publish the tool

1. Sign in at https://button.bitgate.dev.
2. Install the Button runner on your computer (macOS, Linux or Windows) using the one-line command the site shows you - that's curl on macOS and Linux, or PowerShell on Windows.
3. Open the local setup page, pick your program and describe its inputs (text, number, yes/no, choice or files).
4. Publish the tool to get its own page, and invite your colleagues by email.

When you publish, the runner pins the exact command you approved on that computer by hash. When someone runs the tool, each form value is passed to your program as its own argument without a shell, and values aren't allowed to start with -. If you ever edit the tool, your colleagues have to confirm the new version before they can run it again.

Step 3: How colleagues run it (and what to keep in mind)

1. Your colleague opens the link from their invite email.
2. They sign in with Google or a one-time email code. They don't install anything and they never pay.
3. They fill in the form, press Run and download the results when it finishes.

Because the job runs on your computer, your machine needs to be turned on and online when they use it. The tool page shows Ready, Busy or Offline so they can see its status right away, and your computer handles one run at a time.

Every run is logged with who ran it and when, with logs up to 1 MB per run. Button deletes inputs 24 hours after a run finishes and deletes outputs after 7 days. You can revoke someone's access or set it to expire whenever you want.

On both Free and Pro, you get one computer (runner) per workspace. "People" means the distinct colleagues you have invited (you don't count), while monthly runs include your own test runs. Downgrading deletes nothing.

FAQ

Can someone run a workflow_dispatch workflow without write access to the repo?

No. Running a workflow_dispatch workflow manually in GitHub requires a GitHub account that has write access to that repository.

Can you upload a file into a workflow_dispatch input?

No, workflow_dispatch only supports string, number, boolean, choice and environment inputs (up to 25 of them). If your colleagues need to pass files into a script, Button accepts up to 8 files per run, up to 25 MB per file and 100 MB total.

Where does my script run when someone uses a Button form?

It runs on your own computer, never in Button's cloud, so your computer has to be on and online for the tool page to show Ready. Button's servers relay the form values and files between your colleague's browser and your computer, and then delete inputs after 24 hours and outputs after 7 days.

How does Button stop someone from injecting shell commands through the form?

The Button runner only executes the exact command you approved on your computer, pinned by hash. Every form value is passed directly to the program as its own argument with no shell, and form values cannot start with -.

Do the colleagues I invite have to pay for Button or install anything?

No, recipients never pay and don't install anything; they open the link from their invite email and sign in with Google or a one-time email code. You can invite up to 3 people on the $0 Free plan, or up to 250 people on the Pro plan ($15/month, or $144/year at $12/month).