Transok shares folders and files across the LAN from a Wails desktop widget

A LAN share widget, not a storage service

Transok is a desktop widget for handing files to people on the same network, and the scope is deliberately narrow. The project describes itself as an efficient LAN file sharing tool, and the feature list is built around that single job: upload, enable a share, open a download page, delete when you are done. Two properties are stated up front. The tool does not take up excess storage space, and there is no limit to the number and size of files transferred. A third option lets you set a password when sharing files so a link is not an open invitation to anyone on the network segment. This suits a contractor who needs the current drawings, a student moving a course folder between two laptops, or a studio handing a client a render. It is not a general purpose file service, and the mechanism below explains why.

One binary holds the widget, the backend and the download page

Transok is a Wails v2 application, so the desktop shell, the Go backend and the web frontend ship together instead of requiring a server and a separate client to deploy. The go.mod file names the parts: github.com/wailsapp/wails/v2 v2.12.0 for the shell, github.com/gin-gonic/gin v1.10.0 for the HTTP surface, github.com/betamos/zeroconf for local network discovery, github.com/google/uuid for identifiers, go.uber.org/zap for logging and gopkg.in/natefinch/lumberjack.v2 for log rotation. The module declaration also pins the toolchain expectations.

module transok
go 1.22.0
toolchain go1.24.5

So the shell runs on Go 1.22 or newer with a 1.24.5 toolchain selected by the module, which matters if you build on a machine that has an older Go installed and no toolchain download available.

Folder sharing reads the disk on every visit

Folder sharing changes the shape of the workflow. You add a whole folder, and recipients browse the subfolders, then take either a single file or the current directory as a zip. Contents are read on each visit, so a change on disk appears in the share without a re-import step. Item identity is separate from list position: the feature list calls it a stable per-item ID, and the stated effect is that detail and download links keep working after the share list is reordered. That is the small decision that decides whether a shared link survives an afternoon of tidying up. Two conveniences round it out. The share can be revealed in the system file manager, which the project lists as Finder, Explorer and Files, and any shared file can carry an additional note that the recipient sees on the download page.

Interrupted downloads resume, and a captcha gates the link

Large files get a dedicated path. The project describes resilient large-file downloads built on a Service Worker, HEAD and ETag checks, and 256KB streaming, so a dropped transfer can pick up instead of restarting. The download page also renders image thumbnails, and a detail dialog gives multi-line text and image preview. Protection is layered in two ways. You can set a password when sharing files, and a separate encrypted file sharing mode is described as captcha-gated download, where the recipient answers a captcha before the file is released. Discovery is handled by zeroconf, so devices advertising on the local network appear inside the app instead of needing an IP address typed in, and a custom port is supported for networks where the default is already taken.

The only documented path is building from source

There is no installation walkthrough for end users, so the files that describe how to get Transok running are the build scripts and the Go module. The package.json in the repository root is a private monorepo manifest, and its scripts block is the practical entry point for a first build.

  "scripts": {
    "dash:install": "pnpm -F transok-download install",
    "dash:dev": "pnpm -F transok-download dev",
    "dash:build": "pnpm -F transok-download build",
    "dash:preview": "pnpm -F transok-download build && pnpm -F transok-download preview",
    "build:dash": "bash scripts/build-dash.sh",
    "version:set": "node scripts/set-version.mjs",
    "version:check": "node scripts/set-version.mjs --check",
    "frontend:install": "cd frontend && npm install",
    "frontend:dev": "cd frontend && npm run dev",
    "frontend:build": "cd frontend && npm run build",
    "wails:dev": "wails dev",
    "wails:build": "wails build"
  },

The workspace splits along three lines. The dash download app is installed and run through pnpm filters on the transok-download package, the widget frontend uses npm inside the frontend directory, and the desktop shell itself is driven by the Wails CLI. The repository root also carries a pnpm-workspace.yaml, plus both package-lock.json and pnpm-lock.yaml, so pick one package manager for the dash side and be consistent. The scripts/build-dash.sh helper and the scripts/set-version.mjs versioning script are the two shell scripts referenced by the manifest, and the version:set and version:check scripts are the two entry points that manage the VERSION file at the repository root.

Everything the widget can do stops at the LAN edge

The feature list has one entry still unchecked: right-click to add in Finder and File Explorer, so the macOS and Windows integration stops at revealing a shared folder rather than a context menu action. Everything else is local network work. There is no public sharing path, no account system and no relay outside the LAN, which is the point, but it also means a recipient outside your network cannot be served at all. The password and the captcha gate control access at the download page, and neither is a substitute for transport security, since the files travel over the plain HTTP surface that gin provides. Logging is handled by zap with lumberjack rotation, yet the project does not document how to read those logs, how to change the default port, or how to roll back to an earlier release, so an operator inherits that guesswork.

What a general purpose file server does differently

Set beside a general purpose HTTP file server, the difference in approach is assembly. Transok puts the widget, the sharing state and the download page into one application, so there is no separate daemon to deploy and no directory to expose by hand. What you give up is generality. A static file server has no notion of a share, a per-file note, a captcha gate or a device list, and it will serve a directory tree that Transok cannot describe. Against a cloud drive, the trade is reach and control: Transok keeps the bytes on the local disk and inside the local network, while a cloud option serves a counterpart who is not on your network. Neither side of that trade is free.

Three releases in seven weeks under the MIT licence

The project is not archived, and the recorded history shows three releases: v0.4.8 on 2026-04-14, v0.5.1 on 2026-05-27 and v0.5.2 on 2026-05-30, with the last push on 2026-05-30. The licence is MIT, which permits use, modification and redistribution with the notice of the copyright retained. Dependencies carry their own terms, so a distribution review has to cover the dependency tree and not only this repository. The right-click integration that is still unchecked is a reasonable thing to look for in a later release, and its absence today is a small cost rather than a blocker.

Editorial conclusion

Transok suits people who need to hand files to someone on the same network today, and it should not be adopted by teams that need public links, accounts or an audit trail. Before switching, confirm that a captcha-gated download suits your recipients' devices, that your network lets zeroconf discovery packets through, and that the custom port setting in the widget can reach a free port on your subnet.

Frequently asked questions

Official sources

1. bent2685/transok-wails on GitHub
2. Issues
3. License: MIT
4. README
5. Releases