PowerShell GUI for a script Show-Command, Windows Forms, PowerShell Universal, or a web form colleagues open in any browser

If you want to put a graphical interface in front of a PowerShell script, you have four options: the built-in Show-Command cmdlet, a custom Windows Forms or WPF script, a self-hosted web portal like PowerShell Universal, or a web form through Button. With Button (https://button.bitgate.dev), you keep the script on your own PC and publish a browser form your colleagues can run without installing anything. The Free plan is $0 for 1 published tool, up to 3 people and 100 runs per month, and individual runs can last up to 30 minutes.

Option 1: Built-in cmdlets (Show-Command and Out-GridView)

Before writing UI code, check if the tools built into Windows PowerShell and PowerShell 7 on Windows desktop (though not on Server Core) are enough. Show-Command reads a script's param() block and pops up a basic input window for the parameters, and Out-GridView displays your output in a sortable, filterable window.

1. Put a standard param() block at the top of your .ps1 file.
2. Give your coworker a shortcut or batch file that runs Show-Command .\Your-Script.ps1.
3. Pipe the script's results to Out-GridView if they need to sort or filter the output on screen.

Show-Command .\Your-Script.ps1

Notice what isn't solved here: the script still runs on the coworker's own PC, so they need the right PowerShell version, modules, and permissions already set up on their machine. If they all have those things and just hate typing parameters into a console, stop here and use Show-Command.

Option 2: Windows Forms or WPF

When you want a custom window with specific buttons, labels, and layout control, you can write a GUI in PowerShell using Windows Forms or WPF.

This takes a lot more code than a param() block. You have to build the window controls, wire up click events, and handle UI state inside your script. And just like Show-Command, a Windows Forms or WPF script still runs locally on each user's PC under their own permissions, using whatever modules they happen to have installed. If you're distributing a self-contained utility to other admins or technicians who already have the right access on their workstations, Windows Forms or WPF is a solid fit.

Option 3: PowerShell Universal

If you want colleagues to run scripts from a browser instead of on their own machines, PowerShell Universal (sold by Devolutions, formerly Ironman Software) is a full platform you host yourself on Windows, Linux, or macOS. It reads your PowerShell scripts and turns their parameters into web forms, and it also includes schedules, job history, role-based access, REST APIs, apps, and dashboards.

There is a free Developer edition for non-production use, while a production Server license costs $499.99 per server per year. If you want a self-hosted automation server with role-based access, scheduled jobs, dashboards, and REST APIs, PowerShell Universal is the better choice.

Option 4: A browser form that runs on your PC with Button

If you don't want to set up and maintain a server, and you don't want to debug module or permission problems across ten different coworkers' laptops, Button takes a different route. You install a small runner on your own computer (Windows, macOS, or Linux), and Button gives your script a web page. When an invited colleague fills out the form and clicks Run, Button's servers relay the form values and files to your computer, your computer runs the script, and the results go back to their browser to download.

Nothing runs in Button's cloud, and your colleagues don't install PowerShell modules or pay for an account.

1. Prepare your PowerShell script

Instead of interactive Read-Host prompts or hard-coded file paths, set up your script to take its inputs as command-line arguments using a param() block. If the script reads files or creates output files, take each input file path as an argument, and write the results into an output folder that is also passed in as an argument.

param(
    [Parameter(Mandatory=$true)]
    [string]$Department,

    [Parameter(Mandatory=$true)]
    [string]$InputCsv,

    [Parameter(Mandatory=$true)]
    [string]$OutputFolder
)

$rows = Import-Csv -Path $InputCsv | Where-Object { $_.Dept -eq $Department }
$outFile = Join-Path -Path $OutputFolder -ChildPath "filtered.csv"
$rows | Export-Csv -Path $outFile -NoTypeInformation
Write-Output "Saved $($rows.Count) rows."

Button's runner executes pwsh or powershell.exe directly without a shell, passing every form value as its own separate argument, so positional parameters in a param() block map cleanly. Form values also can't start with -, so a colleague can't inject extra flags into your command. If your script needs fixed flags (like -File), you include those in the command you approve during setup; colleagues only provide the values for the form fields.

2. Install the runner and publish the form

1. Sign in at https://button.bitgate.dev.
2. Install the Button runner on your computer by pasting the one-line command the site shows you (it uses PowerShell on Windows, or curl on macOS and Linux).
3. In the runner's local setup page, pick your PowerShell executable and script, and describe the inputs your script expects: text, number, yes/no, choice, or files.
4. Approve the command on your computer (the runner pins it by hash so it will only ever execute that exact command) and publish the tool.
5. Invite your colleagues by email.

3. How colleagues run it

Your colleagues open the link from their invite email, sign in with Google or a one-time email code, fill in the fields, and press Run. Once the script finishes on your machine, they download the output files right from the page.

Every run is logged with who ran it and when. You can revoke someone's access or set it to expire whenever you want, and if you edit the tool's configuration later, invited users have to confirm the new version before they can run it.

Keep in mind that because jobs run on your computer, your PC has to be turned on and connected to the internet when someone needs the tool (the tool page shows Ready, Busy, or Offline). Button runs one job at a time per computer, and each workspace links to a single computer - pairing a new machine replaces the old one.

Comparison of PowerShell GUI options

FAQ

What happens if my computer is asleep or offline when a colleague needs the tool?

Because the script runs on your computer, it has to be on and online for a job to run. The tool's web page shows whether your computer is Ready, Busy, or Offline so colleagues know right away.

What are the file and runtime limits on Button?

A single run can take up to 30 minutes, produce up to 1 MB of logs, and accept up to 8 files (up to 25 MB per file and 100 MB total per run). Button deletes uploaded input files from its servers 24 hours after a run finishes, and deletes output files after 7 days.

Do my colleagues have to pay or install PowerShell to use a Button form?

No, recipients never pay and don't install anything on their machines. They just click the link in their invite email, sign in with Google or a one-time email code, and use their browser.

How does Button count "people" and "runs" on the Free and Pro plans?

"People" counts the distinct colleagues you've invited across your workspace (you don't count toward that limit), while monthly runs include both your colleagues' runs and your own test runs. If you ever downgrade from Pro ($15/month, or $12/month billed at $144/year) back to Free, nothing gets deleted.

Can I use Button with languages other than PowerShell?

Yes. Any program that can take command-line arguments works the same way, including Python, Node, R, shell scripts, and compiled binaries.