Pode: a web server that lives inside a PowerShell script block

A server defined by a script block rather than a compiled artifact

Pode is a cross platform PowerShell framework for creating web servers. The unit of work is a script block: you call Start-PodeServer, pass it a script block, and inside that block you register endpoints and routes. The framework then serves traffic for as long as the process lives.

That design is the whole pitch and the whole trade-off. A compiled web framework gives you a binary you deploy, and the artifact is the same on every machine. Pode gives you a script that a PowerShell host reads at startup, so the deployment story is a script, a PowerShell dependency and a runtime. In exchange you get the parts of the framework catalogue that usually require separate packages: middleware, sessions, CSRF support, flash messages, request authorisation by roles, groups and scopes, Basic, Windows and Azure AD authentication, IP and subnet allow and deny rules, basic rate limiting, request and response compression, and in memory caching with optional external providers such as Redis.

The audience is Windows oriented operations teams that already script with PowerShell, and Linux or Raspberry Pi operators who want the same service definition on a Pi. The project describes itself as cross platform using PowerShell Core with support for PS5, and the repository topics list docker, active directory, session, swagger, openapi, serverless and raspberry pi alongside the rest.

Add-PodeEndPoint and Add-PodeRoute are the whole server model

The mechanics are compact. An endpoint is the listening socket: an address, a port and a protocol. A route binds a method and a path to a script block that runs when the request arrives. The response is written by a cmdlet, for example Write-PodeJsonResponse, which serialises a hashtable to JSON.

Start-PodeServer -ScriptBlock {
    Add-PodeEndPoint -Address localhost -port 32005 -Protocol Http

    Add-PodeRoute -Method Get -Path '/ping' -ScriptBlock {
        Write-PodeJsonResponse -Value @{ value = 'pong' }
    }
}

Run that and the service answers on http://127.0.0.1:32005/ping with a JSON body. Nothing else is required: no application object, no DI container, no configuration file to begin with.

The framework then fills in the parts you would otherwise assemble yourself. The protocol set covers HTTP(S), WS(S), SSE, SMTP(S) and TCP(S), so the same process can be a REST API and a mail or socket server at once. It can listen on a single address or several, over IPv4 and IPv6 and hostnames. Static content can be served with caching, custom error pages are supported, and incoming requests are handled on multiple threads. Cross state variable access across multiple runspaces is listed as a feature, which is the mechanism that lets a route read a variable set during startup rather than re-reading configuration per request.

Installing from Chocolatey, the PowerShell Gallery or the Docker image

Three install routes are documented, and they suit different situations. Chocolatey and the PowerShell Gallery install Pode as a module into your PowerShell environment, which is what you want when the service runs on a Windows host you manage with PowerShell. The Docker route pulls a published image.

# chocolatey
choco install pode

# powershell gallery
Install-Module -Name Pode

# docker
docker pull badgerati/pode

The image is worth a closer look because it shows how the framework is packaged. The Dockerfile starts from the .NET SDK base image, sets POWERSHELL_TELEMETRY_OPTOUT, creates a directory for the module under /usr/local/share/powershell/Modules/Pode, and copies the built package into it. In other words the container ships the Pode module into a PowerShell module path rather than shipping a standalone binary, which is what you would expect from a framework that is a PowerShell module first. There are separate Dockerfiles in the repository for Alpine and for 32 bit ARM, matching the ARM and Raspberry Pi support in the project description.

If you use a package manager, the module lands in your PowerShell module path, and updating means re-running the install, since the project does not describe a self update command.

A .pode view is embedded PowerShell, and third party template engines are optional

Rendering is where Pode diverges from a typical API framework. A .pode file is described as embedded PowerShell, so a view is a script that emits output rather than a template parsed by a separate engine. The project also documents support for third party template engines, so a team that prefers one can use it.

The project offers Pode.Web for building web pages using purely PowerShell, and describes it as currently a work in progress. That caveat is worth taking seriously if your plan depends on it. The examples directory in the repository tells a similar story from the other direction. It contains HelloWorld, PetStore, FileBrowser and OpenApi examples, but also files with names like OpenApi-SimplePotato and OpenApi-TuttiFrutti, which is the maintainer's shorthand for minimal and fully featured API samples.

For content that is not a web page, the framework also handles scheduled and background work: async timers for short running repeatable processes, scheduled tasks driven by cron expressions for longer running processes, and scheduled routes, so a scheduled job can be exposed over HTTP as well. There is a Looping-Service example and Schedules-CronHelper, Schedules-LongRunning and Schedules-Routes examples. If you came for a REST API and find yourself reading the cron helper example, that is the framework being honest about what it does in a single process.

The same service definition runs under IIS, Azure Functions, AWS Lambda and Docker

Hosting options are where Pode differs from a single server binary. The feature list names Azure Functions, AWS Lambda and IIS support alongside Docker, and the repository topics include serverless, active directory and https.

This matters because the deployment surface of a PowerShell script is wider than a compiled service. IIS gives Windows operators process recycling, a service manager and certificate handling for free, at the cost of learning IIS configuration. Azure Functions and AWS Lambda turn the same route definitions into a function app, which is a different cost model entirely: you pay per invocation and you inherit the platform's cold start behaviour. Docker gives you the same module packaging you saw in the Dockerfile, on Linux and on a Raspberry Pi.

The feature list also covers the security and operational edges a small framework usually leaves out: generating and binding self signed certificates, loading secrets from vaults, logging to the CLI, to files or to custom logic for services like LogStash, restarting the server through file monitoring or on defined periods and times, and file watchers as a first class feature. That last pair is a genuine two sided design decision, and it is the one that catches people out, which is why it deserves its own attention.

File monitoring restarts the server, so a stray file save can bounce your service

The feature list includes restart the server via file monitoring, or defined periods or times, and also support for file watchers as a distinct feature. Both rely on the same underlying observation of the file system, and both are convenient and dangerous in a specific way.

For a deployment, file monitoring means you can edit a route script and let the server pick it up. For a developer with a file watcher in their editor that writes on every save, it means the service you are debugging restarts underneath you, mid request, repeatedly. The same applies to a build step that regenerates files in a watched directory, or to a log directory that happens to sit under the watched root.

There is a second consequence. The repository examples include a File-Monitoring example and a File-Watchers directory, so the mechanism is well supported. That is exactly the kind of detail you need before you point the framework at a directory tree that something else is writing to, and it is the detail to look for in the documentation pages for file monitoring before you deploy rather than after.

The related example, Dot-SourceScript.ps1, suggests the other supported way to load code, which sidesteps file monitoring entirely if you would rather control when a change takes effect.

Seven OpenAPI documentation front ends ship in the package manifest

OpenAPI generation is a headline feature, with support for specification versions 3.0.x and 3.1.0, and the documentation is served through a choice of viewers: Swagger, Redoc, RapidDoc, StopLight, OpenAPI-Explorer and RapiPdf. That is six named viewers in the list, and the package manifest explains where the seventh comes from.

The package.json in the repository root is a web component rather than the PowerShell module itself, and it pulls in the front end assets: swagger-ui-dist, redoc, rapidoc, rapipdf, swagger-editor-dist, openapi-explorer and @stoplight/elements, along with bootstrap for styling and @highlightjs/cdn-assets for code highlighting in the docs pages. Versions are pinned, for example swagger-ui-dist at 5.33.0 and redoc at 2.5.4.

The practical implication is that the OpenAPI surface is not a single built in page but a bundle of JavaScript front ends that someone else maintains, hosted from a CDN in the browser. If your documentation is for internal use on an air gapped network, or if you have a policy against loading assets from a CDN, it is worth checking how the assets are served before you publish your API docs to a customer facing endpoint.

The project also supports a self signed certificate flow and HTTPS, so serving the docs over TLS is possible. Swagger is an interactive editor, and a writable specification endpoint is a decision you should make deliberately rather than inherit from a default.

Building and testing on the develop branch with Invoke-Build

The contributor workflow is documented and worth knowing before you fork. Pode is built with Invoke-Build, and the module is required for that. The build script is pode.build.ps1 at the repository root, and the solution file Pode.sln sits alongside it.

Invoke-Build Build

That is the step to run before trying any example, since the examples load the built module. The test target is separate, and it will build the project and auto install Pester and .NET if they are missing.

Invoke-Build Test

There is a third target for documentation, which serves the docs for a release, branch or tag locally so you can read the version that matches your code rather than the latest published documentation.

Invoke-Build Docs

After that, navigate to http://127.0.0.1:8000 in the browser. That the docs build is a first class target rather than an afterthought tells you something about how the project treats versioned documentation, and it is also the mechanism by which a team can read the docs for an older Pode version before upgrading.

The branching model is conventional and worth respecting: pull requests go against the develop branch, and the default branch in the repository is develop. The contributing guide lives in .github/CONTRIBUTING.md, and the request is that each pull request has an appropriate issue created. A SECURITY.md file at the root signals that security reports have a designated path.

Editorial conclusion

Pode fits teams that already live in PowerShell and need a small service, a scheduled worker or an internal API without adding a second language to the build, and it fits Windows operators who want an IIS host or a self signed certificate without leaving the platform. It does not fit a team that needs compile time guarantees, a typed schema enforced by the compiler, or a service whose hot reload you would rather not have. Check three things before you adopt it. Confirm your host works for your case, because the same framework runs under IIS, Azure Functions, AWS Lambda and Docker, and the support for each is not the same as the standalone server. Confirm your dependencies, since the framework offers in memory caching with optional external providers such as Redis, and its package manifest pulls in a set of OpenAPI documentation front ends. And confirm your process model, because Pode restarts on file monitoring, so an editor that saves on every keystroke will bounce your service. The last push was on 2026-10-18, the newest listed release is v2.14.1 from 2026-08-29, and the license is MIT with no copyleft obligation.

Frequently asked questions

Official sources

1. Badgerati/Pode on GitHub
2. License: MIT
3. Project website
4. README
5. Releases