CipherShell is a Windows launcher that bundles a complete PowerShell 7 runtime and runs your scripts entirely in memory. Two things that don't normally go together — modern PowerShell on machines that don't have it installed, and scripts containing plaintext secrets that never get exposed at rest — become routine. If you have PS scripts that include API keys, database passwords, service account credentials, license tokens, or vendor strings that have to be passed in plaintext to the cmdlets and APIs that consume them, CipherShell turns those scripts into encrypted blobs that decrypt only at execution time, in process memory, on machines you authorize.

Bundled PowerShell 7 — works on machines that can't run it natively.

The .NET 8 launcher ships with the PowerShell 7 SDK embedded. Your scripts run against a real, in-process PS7 runspace whether or not PS7 is installed on the host:

• Windows Server 2012 / 2012 R2 boxes that only ship with PS 5.1 can run PS7-only syntax: ForEach-Object -Parallel, ternary operators (? :), null-coalescing (?? ??=), pipeline chain operators (&&, ||), the modern JSON cmdlets, improved error views, all the System.Text.Json improvements, every cross-edition module load.
• Locked-down workstations where IT policy or change-control prevents installing PS7 still get the modern runtime. The launcher carries it with itself — no admin install, no execution-policy tweak, no pwsh.exe PATH conflict.
• No hardware refresh required to use modern PowerShell. If the machine runs .NET 8 (Windows 10 1809+ or Server 2016+), it runs your PS7 scripts. No "upgrade your fleet" project. No "we need to wait for the next refresh cycle."

The bundled runtime is a real PowerShell host, not a sandbox or a subset. Pipelines, jobs, classes, modules, ASTs, custom runspaces, advanced functions — everything PS7 normally does, the launcher does.

Scripts decrypt only in memory — plaintext secrets stop being a problem.

This is the part most people don't notice matters until they hit it head-on. A surprising number of cmdlets and external interfaces only accept plaintext credentials:

• Legacy SOAP and REST APIs that take an Authorization header as a literal string.
• Database connection strings where the password is part of the URI.
• SMTP servers, FTP endpoints, and older mail relays that predate secure credential standards.
• Vendor command-line tools wrapped in PowerShell that expect --password <plaintext> arguments.
• Service account tokens, license keys, webhook secrets, hardcoded SSH passwords, Bearer tokens, registration codes.

The conventional answers — SecureString, DPAPI-encrypted credential files, Windows Credential Manager, external secret vaults — fall apart the moment the consumer of the credential refuses anything but a plaintext string. So scripts end up with literal secrets pasted into them, which then becomes a .ps1 file on disk that anyone with read access can open in Notepad.

CipherShell removes the trade-off. Write the script with the plaintext credentials in it. The launcher encrypts it with AES-256-GCM (fresh 256-bit key per script, generated by the licensing backend). The encrypted blob is what's stored, what's transferred, and what sits on the host's disk. At execution time, the launcher fetches the decryption key over a cert-pinned HTTPS connection, decrypts the script into a memory buffer, hands it to the PS7 runspace, and discards both buffer and key the moment the script ends.

The plaintext form of your script — the form that contains your secrets — only exists in process memory, only for the duration of the run. It never appears in temp files, never gets written to swap-friendly disk locations, and isn't recoverable from forensic disk imaging.

For compliance contexts this is the difference between "plaintext credentials at rest on the filesystem" (a finding) and "credentials encrypted at rest, decrypted only in process memory under controlled execution" (acceptable).

Native to the host — environment variables, modules, and file paths all work.

The bundled runtime isn't a sealed container. Scripts run with the host machine's identity, environment, and installed software, exactly as if PS7 had been installed normally:

• Environment variables — $env:USERNAME, $env:COMPUTERNAME, $env:ProgramFiles, custom variables set by your deployment tooling, RMM-injected variables, anything the host process exposes. The script reads them as-is.
• PSModulePath — extended at launch to include both PowerShell 7 and Windows PowerShell 5.1 module directories. Modules installed system-wide (Posh-SSH, PowerCLI, ImportExcel, ActiveDirectory, anything from Install-Module) are importable without re-installing or reconfiguring.
• File system access — full host filesystem, network shares, mapped drives, UNC paths. Scripts run under the current Windows user and inherit their access rights.
• Networking — DNS, system proxy settings, Windows certificate store, Kerberos tickets, NTLM, IPv6 — all work as PS7 would from a regular terminal. Calling internal APIs, hitting AD, talking to vSphere or Hyper-V or Exchange — all functions identically to running PS7 directly.
• Registered handlers — COM objects, .NET assemblies in the GAC, native DLLs in PATH — all accessible.

The launcher is a delivery and protection layer for the script. The script itself runs against the host system unchanged.

Live terminal — colored, interactive, cancellable.

Scripts don't run in a black box. They run in a terminal pane that behaves like Windows Terminal:

• Full colored output. ANSI color codes, Write-Host -ForegroundColor, error/warning streams all render correctly.
• Categorized, pinnable scripts. Group scripts by any category string ("Maintenance", "Reporting", "VDI", "AD"). Pin frequently-used ones to a tab strip. Pin state persists between app launches.
• Multi-instance execution. Open the same script in three tabs and run them in parallel against different parameters.
• Inline interactive input. Read-Host, Read-Host -AsSecureString, $Host.UI.RawUI.ReadKey() all work directly in the terminal pane. Cursor sits next to the prompt; keystrokes go straight to the script. No popup dialogs, no separate console window — same UX as Windows Terminal.
• Mid-run cancel. Every running script has a Stop button (Ctrl+C also works when the output pane is focused). Cleanly cancels the pipeline including long-running operations — PowerCLI's Stop-VM, Posh-SSH sessions, anything that takes time to unwind. Cancellation runs off the UI thread so the app stays responsive while the pipeline closes.

Access control.

For scenarios where you need to control which machines can execute the encrypted scripts, the launcher includes a license-based activation layer:

• Each install activates against a small Cloudflare Worker backend (~300 lines, deploys in 5 minutes on Cloudflare's free tier).
• Activation binds the install to one machine via a hardware fingerprint (motherboard UUID + disk serial + machine SID).
• 12-hour signed session tokens — the install can run offline for up to 12 hours after last check-in, but can't run forever without backend approval.
• Revoke or unbind from the admin panel; affected machines lose access on next session refresh.
• Backend hardened: AES-256-GCM script storage, HMAC-SHA-256 session tokens, SHA-256 admin password hashing, TLS certificate pinning in the client, hardcoded allowlists on every write endpoint.

This is access control, not anti-piracy theater — you get a real audit trail of which machine ran what and the ability to cut off access cleanly without redistributing anything.

Admin panel.

Same binary, launched with -admin and a password:

• Upload .ps1 files; they're encrypted client-side with a fresh 256-bit key before being pushed to KV. The plaintext never leaves your admin machine.
• Assign a category at upload, or edit category inline on existing scripts.
• Generate, revoke, unbind, and expire license keys.
• See which machine each license is bound to, the IP that originated it, the IP of last activity.
• Set custom display names for the title bar.

What you don't need:

• PowerShell 7 installed on the target machine. The launcher carries its own runtime.
• Newer hardware. If the host runs .NET 8 (Windows 10 1809+ / Server 2016+), your PS7 scripts run.
• A separate secrets vault, KMS, or HSM. The script is the secret, the script is encrypted, the launcher handles it.
• A custom deployment pipeline for credentials. Bake them into the script in plaintext; the encryption is the deployment.
• A dedicated server or VM. The licensing backend runs on Cloudflare's free tier for most workloads.
• Code-signing certificates. Optional. Sign the binary yourself if your environment requires it.

Updates included while your membership is active.

Every release ships through the Gumroad member feed — new features, security patches, runtime upgrades, UI improvements.

If you let your membership lapse, the launcher binary you've deployed, the worker you've stood up, and the licenses you've issued keep working indefinitely. You just stop receiving new versions.