Jenkins for non-developers to run scripts with parameters? Simpler ways to give them a Run button with inputs

Jenkins can run scripts with parameters for your coworkers, and you should keep it if you already maintain a server and the people clicking "Build" are technical enough to navigate its UI. If you just want to hand non-developers a clean web form that runs a script on your own machine without hosting a server, Button (https://button.bitgate.dev) does that for $0 on the Free plan (1 published tool, 3 people, 100 runs per month) or $15/month on Pro (50 tools, 250 people, 5,000 runs per month). Your script still runs locally on your computer, while your colleagues just sign in through their browser, fill out the inputs and download the output files.

What it takes to use Jenkins as a script runner

Jenkins is an open-source Java automation server that you host and secure yourself, and its interface is built for developers.

Getting a script in front of a non-developer takes a few moving parts:

1. Enable "This project is parameterized" on the job. Jenkins gives you string, multi-line string, boolean, choice, password and file parameters. File parameters work out of the box in freestyle jobs, but if you use Pipelines you have to install the File Parameters plugin.
2. Connect the machine where the script needs to run as a Jenkins agent, then restrict the job to that machine with a label.
3. Lock down permissions so non-admins can only start jobs. That means installing the Matrix Authorization Strategy or Role-based Strategy plugin and granting users Job/Read and Job/Build.

It works. The catch is that you're running a Java server, managing plugins, and asking people from ops, finance or support to find "Build with Parameters" and dig through build histories to get their files.

How the alternatives compare

Here is how Jenkins stacks up against four other ways to put a web form in front of a script (checked October 2026):

Walking through the alternatives

Rundeck

Rundeck Open Source is maintained by PagerDuty, whose commercial edition is PagerDuty Runbook Automation. Unlike Jenkins, Rundeck's interface is meant for running operational jobs: job options show up as a form with text, file and multi-line options, allowed values and regex checks, and jobs run locally on the Rundeck server or on remote nodes over SSH or WinRM.

You still host it yourself: a Java 17+ server and, in production, a database. Pick Rundeck when you want a self-hosted runbook server that dispatches jobs across multiple machines.

GitHub Actions (workflow_dispatch)

If your team lives in GitHub, you can trigger a workflow manually with workflow_dispatch, with up to 25 inputs of type string, number, boolean, choice or environment. Jobs run on GitHub-hosted runners (up to 6 hours per job) or on a self-hosted runner on your own computer (up to 5 days per job).

There are two big blockers when your users aren't developers. First, there is no file upload input, so you can't use it for "take this spreadsheet and process it" scripts. Second, triggering a workflow_dispatch run requires a GitHub account with write access to the repository, which you probably don't want to hand to someone who just needs to run a script. Use GitHub Actions when the people running the script are already developers with repo write access and none of the inputs are files.

Script Server

Script Server is a smaller open-source option: a Python web server you install and host yourself (Linux first, with a Docker image). A script's parameters become form fields, including file uploads; runs show live output and offer output files for download; and it supports LDAP, Google OAuth and htpasswd logins with execution history and audit logs.

Its latest tagged release is 1.18.0 from August 2023, though the main branch still gets commits. Pick it when you want a lightweight self-hosted script runner on a Linux box and you're fine maintaining the server.

Button

Button (https://button.bitgate.dev) is for the case where the script lives on your computer (macOS, Linux or Windows) and you don't want to host a web server at all. Any program works: Python, Node, R, PowerShell, shell scripts, compiled binaries.

Jobs run on your computer, never in Button's cloud, while Button's servers relay the form values and files between the browser and your machine. Because it runs on your hardware, your computer has to be on and online when people use it (tool pages show Ready, Busy or Offline).

The runner only executes the exact command you approved on that computer, pinned by hash, passes every form value as its own argument with no shell, and rejects values that 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.

There are hard limits to keep in mind:

• One run at a time per computer, up to 30 minutes per run.
• Files up to 25 MB each, and up to 8 files and 100 MB per run.
• Logs up to 1 MB per run.
• Inputs are deleted 24 hours after a run ends, and outputs after 7 days.

The Free plan is $0 for 1 published tool, 3 people and 100 runs per month; Pro is $15/month, or $144/year, for 50 tools, 250 people and 5,000 runs per month. Recipients never pay and install nothing, and downgrading deletes nothing.

Turning a local script into a Button tool

Before you hook a script up to Button, make it take its inputs as command-line arguments (argparse, commandArgs(), a param() block, or $1 and $2) instead of hard-coded paths or prompts, including each input file path and an output folder for the results:

import argparse

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

Fixed flags such as --currency are part of the command you approve; your colleagues only supply the values for the form fields.

Once your script takes arguments, setting it up on Button takes a few minutes:

1. Sign in at button.bitgate.dev.
2. Install the Button runner on your computer with the one-line command the site shows you (it'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, files).
4. Publish the tool. Button gives the tool its own page.

When you invite colleagues, they 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.

When to use which tool

• Keep Jenkins when you already run a Jenkins server and the people triggering the scripts are technical enough to use its interface.
• Use Rundeck when you want to self-host a dedicated runbook server with a database and run jobs across nodes over SSH or WinRM.
• Use GitHub Actions (workflow_dispatch) when your users already have write access to the repo and none of the inputs are files.
• Use Script Server when you want a lightweight self-hosted script runner with file uploads.
• Use Button when the script is on your macOS, Linux or Windows computer, it finishes within 30 minutes with files under 25 MB, and you want to give non-developers a simple form without hosting a server.

FAQ

Does Button run my scripts in the cloud?

No, jobs always run on your own computer, never in Button's cloud. Button's servers only relay the form values and files between the user's browser and your computer, which means your computer needs to be on and online when someone runs a tool.

Can non-developers upload files to a GitHub Actions workflow?

No. A manual workflow_dispatch trigger supports up to 25 inputs (string, number, boolean, choice or environment), but it has no file upload input, and the user also needs a GitHub account with write access to the repository.

How long does Button keep the uploaded files and results?

Input files and values are deleted 24 hours after a run ends, and output files are deleted after 7 days. Each run can take up to 8 files (up to 25 MB each, 100 MB total per run) and log up to 1 MB.