Run a script on your own computer from a browser remote desktop, SSH, a self-hosted runner, or a Run button anyone you invite can press

If a script has to run on your own machine because that's where the local data, software licenses, GPU or network access live, you can either let people onto the machine itself (remote desktop, SSH), wire it up to a CI system or a tunnel, or use Button (https://button.bitgate.dev) to put a web form in front of that one command. Button's Free plan is $0 for 1 published tool, 3 invited colleagues and 100 runs a month, and each run can take up to 8 files (up to 25 MB each, 100 MB total) and run for up to 30 minutes while your computer stays on.

Comparing the options

Remote desktop: Windows Remote Desktop and Chrome Remote Desktop

Remote desktop is the right choice when the person triggering the job is you from another room, or when the program has a desktop GUI that you have to click through by hand.

The downside is that you're handing over the whole screen. Anyone who connects sees your open windows, files and logged-in apps, and only one person can really drive the mouse at a time. Windows Remote Desktop can only host sessions on Windows Pro or higher editions, not Windows Home. Chrome Remote Desktop is free and works across platforms; TeamViewer is another option, though it's free for personal use only.

SSH

If you're sharing the script with another developer who's comfortable in a terminal and needs to pass arbitrary flags or inspect logs in place, SSH is the standard tool. They open a terminal, log in, and run the command directly.

For non-technical colleagues, a terminal session is rarely what they want. And unless you spend time locking down the account on your operating system, an SSH login gives them a shell where they can read other directories, edit the script, or run other programs on your machine.

GitHub Actions with a self-hosted runner

If the people triggering the script are already developers inside your GitHub repo and the job takes hours, a self-hosted runner works well. Jobs on a self-hosted runner on your computer can run for up to 5 days (compared to 6 hours on GitHub-hosted runners), which is far longer than Button's 30-minute limit.

To trigger a workflow manually from a browser with workflow_dispatch, the colleague needs a GitHub account with write access to the repository - meaning they can also push code and edit the workflow YAML itself. workflow_dispatch gives you up to 25 inputs of type string, number, boolean, choice or environment. There is no file upload input, so if a colleague needs to hand your script a spreadsheet or a PDF, they have to commit it to the repo or upload it somewhere else first.

A local web app behind a tunnel

If you want a custom UI and don't mind writing and maintaining a small web server (for example with Flask or FastAPI) on your computer, you can put a tunnel in front of it so people can reach it from a browser.

You have a few ways to expose that local web app:

• Cloudflare Tunnel (cloudflared) is free on all plans, and you can pair it with Cloudflare Zero Trust (Access), which is free for up to 50 users and puts a login screen in front of the tunneled app.
• ngrok has a Free tier with one auto-assigned dev domain and 1 GB of data transfer per month, but it shows an interstitial warning page to browser visitors; the cheapest paid plan (Hobbyist) is $10/month.
• Tailscale Serve shares a local service only with devices on your tailnet, so every colleague needs Tailscale installed and signed in (the free Personal plan covers up to 6 users). Tailscale Funnel exposes the service to the public internet without requiring them to install Tailscale.

With all of these, the tunnel only handles getting requests to your localhost. You still have to build the HTML form, parse file uploads, queue jobs so two people don't run the script at the same time, and return the output files.

Button: a Run button for one approved command

When you want a colleague to fill in a few fields, upload a file, click Run and get the output back - without giving them your screen, a shell, repo write access, or a web app you had to write yourself - that's what Button is built for. It works with any program on macOS, Linux or Windows: Python, Node, R, PowerShell, shell scripts, compiled binaries.

How to set it up

1. Make your script take command-line arguments. Instead of interactive prompts or hard-coded file paths, use argparse in Python, commandArgs() in R, a param() block in PowerShell, or $1 and $2 in bash. Take each input file path as an argument, and write the output files into a folder path that's also passed as an argument.

import argparse
parser = argparse.ArgumentParser()
parser.add_argument("--input", required=True)
parser.add_argument("--outdir", required=True)
args = parser.parse_args()

2. Install the Button runner. Sign in at https://button.bitgate.dev and run the one-line install command shown on the site (curl on macOS and Linux, PowerShell on Windows).
3. Approve the command and describe its inputs. In the local setup page on your computer, pick your program and set up the form fields (text, number, yes/no, choice, files). Fixed flags like --input are part of the command you approve; colleagues only fill in the values for the form fields.
4. Publish and invite colleagues. Button gives the tool its own page. Colleagues open the link from their invite email, sign in with Google or a one-time email code, fill in the form, press Run and download the results. They don't install anything and never pay.

What the colleague can and can't do

The job runs on your computer, never in Button's cloud, while Button's servers relay the form values and files between the browser and your machine. 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 -, so someone filling in the form can't inject extra flags or shell commands. 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 someone's access or set it to expire at any time. Your computer has to be on and online for people to use the tool; the page shows whether your runner is Ready, Busy or Offline, and runs one job at a time.

FAQ

Does my data stay on my computer when someone uses Button?

The program itself runs on your computer, but the form values, input files and output files pass through Button's servers between the browser and your computer. Input files are deleted from Button's servers 24 hours after a run ends, and outputs are deleted after 7 days.

What are Button's file, runtime and computer limits?

Each run can take up to 8 files (up to 25 MB per file and 100 MB total), produce up to 1 MB of logs, and run for up to 30 minutes, one run at a time per computer. Every plan allows one computer (runner) per workspace, and pairing a new computer replaces the previous one.

Do the people I invite need to pay or install anything?

No, recipients never pay and don't install anything; they open the link from their invite email in a browser and sign in with Google or a one-time email code. On the Free plan ($0) you can invite up to 3 colleagues (you don't count toward that number) with 1 published tool, 100 runs per month (which includes your own runs) and 1 GB of file transfer per month, while Pro ($15/month, or $144/year at $12/month) covers 50 tools, 250 people, 5,000 runs per month and 50 GB of transfer, and downgrading deletes nothing.

What happens if my computer is asleep or already running a job?

Your computer has to be on and online for runs to happen, and it runs one job at a time. The tool's web page shows Ready, Busy or Offline so colleagues can see its status before pressing Run.