TinyWall: the Windows firewall that stays out of the kernel

Default-deny application blocking without a kernel driver

TinyWall's stated job is narrow: sit in the system tray and deny network access to any application the user has not explicitly allowed. The project describes itself as free, lightweight, non-intrusive and secure by default, and the interesting part is where enforcement happens. It installs no kernel drivers, which the project links directly to system stability, since a misbehaving filter driver can take a machine down in a way a user-mode component cannot.

That choice has consequences for anyone assessing it. A firewall that blocks at the network filtering layer can stop an application from reaching the internet, but it does not sandbox the process, does not inspect content and does not police what the application does with data it already had. TinyWall is a traffic gate, not a behavioural sandbox. Its value on an ordinary desktop is convenience: default-deny for new programs without a dialog every time a game updater appears.

The source tree backs the general shape of this. Top-level entries include pylorak.Windows.WFP, pylorak.Windows.Services and pylorak.Windows, alongside the main TinyWall project and MsiSetup. The WFP directory name points to the Windows Filtering Platform, and the services directory suggests the component that keeps rules alive across restarts. The listing alone does not tell you how those pieces communicate, so anyone who needs certainty should read the source rather than the marketing line.

The JSON profile database that drives the block decisions

The rules come from a database of known applications. According to the build instructions, the source files live as individual JSON files in the TinyWall\Database folder, and they feed two things: the database of known applications, and the built-in Special Exceptions list. A separate command line utility turns that folder into a single file called profiles.json, which is what the application consumes.

The implication for a packager is that this database is build output, not a config file a user edits at runtime. The project gives a Debug path for it, TinyWall\bin\Debug, and the release packaging steps stage the same assets into the installer source tree. A fork cannot simply patch one rule in place; it has to regenerate the single file and let the normal build pick it up.

Special Exceptions is a named feature in the documentation, described only as built-in exceptions shipped from the same JSON sources. The documentation does not enumerate what those exceptions are, and it does not describe a way for an end user to add one after installation. Anyone who needs a specific program permanently allowed should expect to work through the JSON source files and a database rebuild rather than through a UI setting.

Building the application and regenerating the profiles database

Building from source has two halves. The application needs Microsoft Visual Studio 2026 (or 2022), the Wix v3.14 Toolset, and the Visual Studio extension for the Wix v3 Toolset. The project states that you open the solution file in Visual Studio and compile the TinyWall project, and that the other projects referenced inside the solution do not need to be built separately because they are statically compiled into the application.

The database is a separate step, and the utility that produces it is embedded in the application itself, so the application has to be built first. You then point the utility at the JSON source folder and at a destination:

TinyWall.exe database-creator /source-folder <path to TinyWall\Database> /output-folder <any-folder>

That command reads the individual JSON files and writes a single profiles.json into the output folder. Copy the result into TinyWall\bin\Debug to make use of it in Debug builds. This is the concrete sequence a developer follows, and it is short enough that a rebuild after every rule change is realistic.

If the goal is a full setup rather than a Debug run, the project routes you to a separate automated path, described in the next section. No Docker image, package recipe or headless build recipe is given anywhere in the documentation, so every environment is a Windows workstation with the Visual Studio toolchain installed.

build.ps1 is the only ground truth for release builds

Official releases go through a different path. The setup is produced by a WiX-based setup project, and it needs its source files staged in a specific directory structure under MsiSetup\Sources, with the binaries, the database, the hosts file, docs and license copied there. Staging by hand is unnecessary, because a build script handles it, normalizes the resx language resources into their correct form, signs the output, and creates a complete update package for server distribution for the built-in updater.

Signing can be skipped with the --skip-sign switch. The script is described as commented and numbered so that you can follow what it does, and the built setup files end up in MsiSetup\bin. The configuration lives in a text file:

build-config.ini.template

You copy that template to build-config.ini, edit it, and then run the script from a PowerShell:

build.ps1

One warning deserves attention. A CI build workflow exists in the repository, but it is described as intended for external contributors, is not used for official releases, and may be out of date. The project states plainly that build.ps1 remains the only ground truth for official build and release steps. Anyone who wires the GitHub workflow into a production release path is automating something the maintainer does not stand behind. The repository also has no GitHub releases, so versioned artifacts are not published there, and later versions arrive through the built-in updater and its update package. Changelog.txt at the top level is the version history available to a reader.

Where TinyWall is the wrong tool

There are several clear cases where this project does not fit. It is a Windows firewall, so a Linux or macOS host is out of scope by definition. It is a desktop tool: the whole model is a system tray icon and an allow list of local applications, with no host grouping, no policy server and no central reporting, so it does not answer the needs of an organisation running a few hundred managed machines.

It is also the wrong choice when the requirement is content filtering or application sandboxing, because blocking a network connection does not restrict what a program can do with files it already has. The documentation does not document a rollback of a rule set, an undo path for a misclicked deny, or a command for exporting and restoring the allow list. An administrator who wants reversible automation would have to design that layer themselves.

The last limitation is practical rather than architectural. Every documented build path needs Windows, Visual Studio and WiX, and the release output is a Windows installer. There is no container image, no package for a headless host, and no published release archive that can be pulled into an image build. Teams that build their own machine images should plan for a fork and a private release pipeline rather than for fetching an artifact.

Two routes to the same behaviour, with different costs

There are two practical ways to get this behaviour, and they differ in cost rather than in effect.

The first is to use the upstream project as it stands. The documentation links a website and a download page for the setup, and the built-in updater handles later versions through the update package. The cost is that you inherit the upstream rule set, the upstream update cadence, and the upstream decision about what stays in maintenance mode.

The second is to fork and ship your own binary. The build script is parameterised through build-config.ini, so a fork can point it at its own signing setup and its own staged assets. The known-application database is regenerated from the fork's own JSON files, which means the application list and the Special Exceptions can be rewritten before the single file is produced. The price is stated in the project: if the goal is to build and distribute your own binaries rather than contribute code, you should choose a name dissimilar to TinyWall so users are not confused about what they are running. The maintainer also asks that large changes be discussed first when they fall within the vision of TinyWall staying small, efficient and simple.

The driver boundary is the design point that matters most. The project states that TinyWall installs no kernel drivers and connects that to its claim of not negatively influencing system stability. A requirement for kernel-level inspection cannot be met by this source tree, so anyone who needs that has to look at a different category of product entirely.

Licence mix, contribution rules and a maintenance-mode project

TinyWall's own code is GPLv3, and the repository carries a LICENSE.txt at the top level. Forking it to distribute your own binary means distributing a GPL work, with the source availability obligations that licence implies. The project asks for a different product name in that case, but it does not ask you to relicense the code, so a renamed binary is still GPLv3 and still needs its corresponding source published.

The tree also vendors third-party components, each under its own terms. Microsoft.Samples\TaskDialog\ is listed as Public Domain, DarkModeCS.cs as MIT, and Microsoft.Samples\Privilege.cs as covered by its own Privilege.cs.LICENSE file. A build that ships all of them inherits all three terms, and that table in the project documentation is the place to check them.

On maintenance, the position is stated by the maintainer rather than inferred. TinyWall is in maintenance mode, responses to issues are often delayed, and all issues and requests are looked at. New features are more likely to be implemented if the pull request includes the code changes itself. The last push to the repository was on 2026-10-17, so the code is current, but the direction is upkeep rather than expansion. The contribution path is the usual one, fork, branch, commit, push, pull request, and the project names the branch command:

git checkout -b feature/AmazingFeature

Editorial conclusion

TinyWall suits individual Windows users and small teams that want default-deny application blocking without a kernel driver. It does not fit managed fleets, non-Windows hosts, or anyone needing kernel-level inspection. Before adopting, check the last push date of 2026-10-17 against the stated maintenance mode, read the licence mix across the vendored components, and confirm the known-application database covers the software you actually run.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. pylorak/TinyWall on GitHub
4. README