It's on GitHub Trending today with about 64,000 stars. It's licensed under Apache-2.0, and the project pledges no features behind a paywall.

What it does

Point Coolify at a server, whether that's a VPS, a bare-metal box or even a Raspberry Pi, and it becomes a deployment platform. The README's feature list covers most of what you'd pay a PaaS for:

• Deploy any app from GitHub, GitLab, Bitbucket or Gitea, built with Nixpacks, Railpack, a Dockerfile, Docker Compose or a prebuilt image.
• Run databases and services: managed databases plus more than 360 one-click services, with persistent storage and generated credentials.
• Automate deployments: deploy on every Git push, spin up previews for pull requests, trigger builds by webhook, and roll back to earlier images.
• Handle networking: custom domains, automatic HTTPS, reverse proxying, health checks and container networks.
• Look after it: backups for databases and storage, scheduled tasks, secrets, notifications, logs, and terminals into running containers.
• Script it: a dashboard, an API, a CLI, an MCP server for AI agents, and team-based access controls.

How it works

Coolify is a control panel that manages your servers over SSH and runs your workloads as Docker containers. The recommended setup puts Coolify on one server and deploys your apps to one or more others, so your control plane and your workloads don't compete for resources. A single small server works for tinkering.

The design choice I like most is that it doesn't lock you in. Your configuration lives on your own servers, and the README says that if you stop using Coolify, "your running resources continue to work and remain manageable." Your apps don't stop when the dashboard goes away.

Trying it

Installing it on a supported server is one command:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

The project links straight to the install script so you can read it before piping it into a root shell, which you should. The installation guide covers supported systems and requirements. Once it's running, you open the dashboard in a browser, connect a Git provider or pick a one-click service, and deploy.

If you'd rather not maintain the Coolify server itself, there's Coolify Cloud, a paid hosted control panel that still deploys to your own servers. It adds high availability, email notifications and extra support.

The fine print

• You're the ops team now. Coolify takes care of deploys, certificates and backups, but you still own the servers: OS updates, disk space, firewalls and what happens when hardware dies. That's the trade you make for leaving a managed platform.
• Read the install script. One-line installs are convenient, but the script sets up Docker and system services as root. The README invites you to review it, so take it up on that.
• Donation-funded. Coolify stays free without paywalled features by relying on sponsors, donations and the Cloud offering. That's worth knowing if you're betting a business on it, and it's a good reason to chip in if you do.

Who it's for

Coolify is for indie developers tired of PaaS bills that grow faster than their side projects, small teams who want Heroku-style workflows on a couple of cheap VPSes, homelabbers who want one dashboard for everything they run, and anyone who wants their apps to keep working on their own hardware no matter what happens to a vendor.

The GitHub repo and coolify.io are the places to start, and it's in the resource index now.

End of transmission.

It's on GitHub Trending today with about 10,800 stars, and the software is licensed under Apache-2.0.

What it does

The README lists the tricks:

• It walks. Pick up a gamepad and drive it around.
• It rolls. Put wheels on, ask for roller mode, and it loads a different policy.
• It picks things up. Beak to the floor, one button.
• It gets back up. Knock it over and it stands itself up.

It also sits, kicks a ball, and quacks "in a voice that is its own." The command-line cheat sheet even lists "chorale" and "theremin" commands, which tells you something about the people who built it.

How it works

The movement comes from reinforcement learning. Instead of hand-coding each joint for a walking gait, Pollen trains policies in the MuJoCo physics simulator with PPO, a standard RL algorithm. It uses domain randomisation, meaning the simulated physics is varied during training so the policy holds up against the messiness of a real robot. The trained policy is then exported to ONNX and loaded onto the duck. That training pipeline lives in a sister repo, microduck_rl.

On the robot itself, a Rockchip RK3566 runs a 50 Hz control loop that drives fifteen servos from those policies. The software is written in Rust, with no framework, as a set of small daemons, each owning one job:

• robotd owns the control loop and the motor bus.
• updaterd installs signed releases and rolls them back if the robot comes up unhealthy.
• configd handles wifi and identity, btd is the Bluetooth path a phone uses, and padd reads the gamepad.
• mediad streams the camera over WebRTC, and tofd serves the depth sensor.

They all speak one JSON-RPC contract over Unix sockets. The phone app, the console, the gamepad and your own scripts all send exactly the same calls, so anything the app can do, a script can too.

The update system deserves a mention. The README says every update is "verified, health-gated and reversible," which is exactly what you want from a small robot that would otherwise be one bad firmware flash away from a paperweight.

Trying it

The robot itself is sold through Pollen's Microduck page. If you have one, robotctl is the main tool, and the cheat sheet in the repo covers driving, configuration, voice, wifi, updates and logs. There's also duckctl, which drives the robot from a laptop over Bluetooth, with no network or ssh needed.

You don't need a duck to start, though. The repo includes a simulated duck that runs the real robot daemons against a body in MuJoCo:

scripts/duck-sim

It runs either one duck in a window or four as separate machines you can log into. That's a neat way to hack on the software, or just to see how a real robot stack is put together. The docs also cover setting up a dev board from scratch and pushing your own branch builds to a robot in about a minute.

The fine print

• This repo is the software. It's the brain, not a parts list, and the hardware comes from Pollen. The simulator lets you work on the code without buying anything.
• Training lives elsewhere. If you want to teach the duck new moves, you'll be working in microduck_rl with MuJoCo and PPO. That means real compute and some reinforcement learning background.
• It's honest about its rough edges. The repo keeps a docs/project/ folder of "what has gone wrong and what would close it," alongside design notes explaining why things are the way they are. That's rare and useful.

Who it's for

Microduck is for robotics tinkerers, anyone curious how sim-to-real reinforcement learning works in practice, Rust developers who want to see a clean embedded daemon architecture, and frankly anyone who has wanted a small robot duck that gets back up when you knock it over. Even if you never buy one, the design docs and the simulator make it one of the more approachable real robot codebases out there.

The GitHub repo and the Microduck page are the places to start, and it's in the resource index now.

End of transmission.

It's on GitHub Trending today with about 18,700 stars, and it's licensed under Apache-2.0.

What it does

Every agent runs in its own isolated sandbox. A policy you write decides which files it can read and write, which processes and system calls it can use, and which network hosts and APIs it can reach. When an agent wants something new, say a package registry it hasn't touched before, the change goes through an approval step instead of just happening.

The part I like best is how it handles credentials. Agents never see your real API keys or tokens. OpenShell adds credentials to outgoing requests only when those requests are headed for endpoints you've approved. An agent that gets talked into sending its secrets somewhere has no secrets to send.

How it works

The README describes two layers.

Kernel-level enforcement. OpenShell instruments the kernel to check every file access, system call and network connection at runtime. Network traffic passes through a policy check before it leaves the sandbox. These rules aren't suggestions in the agent's system prompt. They're enforced whether the agent cooperates or not.

Formally verified policy changes. When a policy changes, OpenShell uses formal verification to work out what new access the change would actually grant, flagging things like "this lets the agent reach a new host with credentials" or "this allows a new API method." Risky changes wait for a human to review them. The docs call these tools the policy advisor and the prover.

Around that sits a gateway, the control plane that manages sandboxes, policies and access. It can run locally or on Kubernetes via Helm. Sandboxes run under Docker, Podman or host virtualization, and the docs cover custom images, GPUs and lifecycle management. Credentials are handled by "providers," which also route model inference traffic.

Trying it

You need Linux, macOS on Apple Silicon, or Windows with WSL 2 (experimental), plus Docker, Podman or host virtualization. Then:

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo

That installs the CLI and a local gateway, then creates a sandbox. The default image is a minimal Ubuntu with no agent inside, so it's an empty room until you put something in it. The "Run Your First Agent" guide runs the OpenCode coding agent against a free OpenRouter model and walks through approving new access as the agent asks for it.

There are SDKs for driving a gateway from your own code in Python (uv add openshell), TypeScript, Go and Rust. There's also a set of agent skills that teach coding assistants to use the CLI and write policies:

npx skills add NVIDIA/OpenShell

The fine print

• It's young. The 0.1.x series just introduced a stable release cadence, new isolation primitives and new APIs, with an upgrade guide for people coming from earlier builds. Expect things to keep shifting.
• Telemetry is on by default. The project says it collects only anonymous operational counts, with no prompts, paths, hostnames, credentials or model names. You can turn it off with OPENSHELL_TELEMETRY_ENABLED=false on the gateway, or compile it out entirely.
• Kubernetes needs real network policy. If you deploy the gateway on a cluster, your CNI has to enforce NetworkPolicy, or the network rules don't mean much.
• A sandbox is only as good as its policy. OpenShell gives you the enforcement and the review tooling, but deciding what an agent should be allowed to do is still your job.

Who it's for

OpenShell is for anyone letting AI agents run unattended: teams running coding agents in CI, companies running fleets of agents that touch internal systems, and individuals who want to try an agent without giving it their home directory and every API key on the machine. If you've ever approved an agent's shell command and hoped for the best, this replaces hope with a policy.

The GitHub repo and the documentation are the places to start, and it's in the resource index now.

End of transmission.

It's on GitHub Trending today with about 59,000 stars and nearly 800 contributors. It ships fast, too: v2.50.0 landed yesterday. The core is AGPL-3.0, with some important exceptions covered in the fine print below.

What it does

Twenty gives you the usual CRM building blocks: records for people, companies and opportunities, customizable views like tables and kanban boards, workflows that automate the repetitive parts, and AI agents that work inside the data. The README's pitch is that it's "the CRM you build, ship, and version like the rest of your stack."

That last part is the real idea. Most CRMs are customized by clicking around an admin panel until nobody remembers why a field exists. Twenty lets you define your data model and logic as code, review it in a pull request, and deploy it like any other software.

How it works

Customizations are packaged as "apps." You scaffold one with the Twenty CLI, then declare objects, fields and views in TypeScript. This example from the README adds a deal object with name, amount and close-date fields:

import { defineObject, FieldType } from 'twenty-sdk/define';

export default defineObject({
  nameSingular: 'deal',
  namePlural: 'deals',
  labelSingular: 'Deal',
  labelPlural: 'Deals',
  fields: [
    { name: 'name', label: 'Name', type: FieldType.TEXT },
    { name: 'amount', label: 'Amount', type: FieldType.CURRENCY },
    { name: 'closeDate', label: 'Close Date', type: FieldType.DATE_TIME },
  ],
});

Then you publish it to your workspace from the command line. Apps can also contain views, agents and "logic functions," which are small pieces of code the platform runs for you. There are official agent skills too, so coding assistants like Claude Code, Codex or Cursor can build Twenty apps for you.

Under the hood it's a TypeScript monorepo: a NestJS backend on PostgreSQL and Redis with BullMQ for background jobs, a React front end, and REST and GraphQL APIs plus webhooks for integration.

Trying it

The fastest way is the hosted version at twenty.com. To self-host, the docs walk through Docker Compose. Grab the example environment file and compose file:

curl -o .env https://raw.githubusercontent.com/twentyhq/twenty/refs/heads/main/packages/twenty-docker/.env.example
curl -o docker-compose.yml https://raw.githubusercontent.com/twentyhq/twenty/refs/heads/main/packages/twenty-docker/docker-compose.yml

Fill in the secrets in .env, then start it with docker compose up -d. The stack runs a server, a background worker, PostgreSQL 16 and Redis. The server applies its own database migrations on startup. The docs also offer a one-line install script, and an upgrade guide that's worth reading before your first version bump. Back up the database first.

To build your own app on top:

npx create-twenty-app my-app
npx twenty app:publish --private

The fine print

• It's mostly AGPL, not all AGPL. The licence file is worth reading. Files marked /* @license Enterprise */ are under a commercial licence and need a paid Enterprise Edition subscription for production use. You can still use them for development and testing. The app toolkit (the CLI, SDKs, create-twenty-app) and the UI component library are MIT.
• Your apps can stay proprietary. A special "Twenty Application Exception" to the AGPL says apps that talk to Twenty only through its published APIs and SDKs aren't covered by the AGPL, so you can license your own customizations however you like. Modifying Twenty itself still triggers the AGPL in full, including the clause requiring you to share source with users of a network service.
• Self-hosting means running a real stack. Postgres, Redis, a worker process, encryption keys and regular upgrades are all on you. It's well-documented, but it isn't a single binary.
• It moves fast. 133 releases so far. That's great for features, but it means upgrades are routine maintenance.

Who it's for

Twenty suits technical teams who've outgrown spreadsheets but don't want to rent Salesforce, plus companies that need their customer data on their own servers and developers who want their CRM schema under version control next to the code that uses it. If you'd rather click than code, the hosted version and the built-in views cover the basics without writing a line.

The GitHub repo and the documentation are the places to start, and it's in the resource index now.

End of transmission.

It's back on GitHub Trending today, with around 140,000 stars. It's licensed under GPL-3.0.

What it does

Most image-generation tools give you a prompt box and a Generate button. ComfyUI gives you the plumbing instead. A workflow is a graph: one node loads a model, another encodes your prompt, another samples, another decodes the result and saves it. You can rearrange any of it, add a ControlNet or a LoRA, branch off an upscaler, or feed one model's output into another.

The README's model list is long. A few highlights:

• Images: Stable Diffusion 1.5, SDXL and SD3.5, Flux.1 and Flux.2, Qwen Image, HiDream, Chroma and more, plus editing models such as Flux Kontext and Qwen Image Edit.
• Video: Wan 2.1 and 2.2, LTX-Video, HunyuanVideo 1.5, CogVideoX and Mochi.
• Audio: ACE-Step 1.5, Stable Audio 3 and others.
• 3D and vision: Hunyuan3D 2.1, SAM 3, Depth Anything 3, SUPIR upscaling.
• Text: Gemma and Qwen3 models, including multimodal inputs.

Built-in tools cover inpainting and outpainting, masks and compositing, model merging, upscaling, frame interpolation, segmentation and depth estimation. It also handles 16-bit PNG, 32-bit EXR and HDR video, which matters if you're doing real post-production work.

How it works

ComfyUI is a Python backend with a browser front end. A few design choices make the node graph more than a pretty diagram:

• It only runs what changed. Submit the same graph twice and only the first run executes. Change the last node and only that node and its downstream dependencies re-run. Nodes without a complete path to an output don't run at all.
• Workflows travel with their images. Drag a generated PNG back onto the canvas and ComfyUI rebuilds the entire workflow that made it, seeds included. Workflows also save as plain JSON.
• It's careful with memory. The README claims it can run "even the biggest open source models on as low as 4GB vram + 8GB ram relatively quickly," using what it calls asynchronous weight streaming, plus model offloading and quantized model support.

Around the core there's a lot more: reusable subgraphs, templates, an "App Mode" that wraps a complicated workflow in a simple UI, a local API for plugging workflows into other software, and a huge ecosystem of custom nodes, managed with the optional ComfyUI-Manager.

Trying it

On Windows and macOS the project recommends the desktop app. There's also a portable Windows build for NVIDIA, AMD and Intel GPUs. The quickest command-line route is comfy-cli:

pip install comfy-cli
comfy install

For a manual install, clone the repo, install the PyTorch build for your GPU (the README has exact commands for NVIDIA CUDA, AMD ROCm, Intel XPU and Apple Silicon), then:

pip install -r requirements.txt
python main.py

Model files go in the matching folders, such as models/checkpoints for checkpoints and models/vae for VAEs. If you already have models downloaded for another UI, extra_model_paths.yaml lets ComfyUI share them instead of keeping duplicates. To add custom nodes, install the manager and launch with it enabled:

pip install -r manager_requirements.txt
python main.py --enable-manager

The fine print

• Offline by default, with paid extras. Core ComfyUI doesn't download anything unless you ask. It also ships optional "partner nodes" for closed models like Nano Banana and Seedance through Comfy's paid API. Launch with --offline to keep everything local, or --disable-partner-nodes to switch off just those nodes.
• Custom nodes are other people's code. The ecosystem is ComfyUI's superpower, but every custom node is third-party Python running on your machine. Install the ones you trust.
• Master moves fast. Stable releases land roughly every two weeks, and the README warns that commits between them "may be very unstable and break many custom nodes." Stick to tagged releases if you depend on a particular node pack.
• Model licences are separate. GPL-3.0 covers ComfyUI itself. Each model you load comes with its own terms.
• There's a learning curve. The node graph is the point, but if you just want to type a prompt and get a picture, it's more interface than you need. App Mode and templates soften that.

Who it's for

ComfyUI is for anyone who wants to see and control every step between a prompt and the output: artists building repeatable pipelines, VFX and video people who need high bit depth and compositing, developers who want a local generation backend with an API, and tinkerers who want to try each new open model the week it drops. If a one-box generator has ever felt like a black box, this is the opposite.

The GitHub repo and comfy.org are the places to start, and it's in the resource index now.

End of transmission.

It's one of the biggest repos on GitHub Trending right now, with roughly 76,000 stars. The application is licensed under AGPL-3.0, with a big caveat about model weights that's covered below.

What it does

The README groups everything into three columns:

• Create: clone a voice from a reference recording, or design a new one from a description. A floating dictation widget handles speech-to-text anywhere on your desktop.
• Produce: dub videos with timed speech, and build stories, audiobooks and batch jobs.
• Connect: a local API and an MCP server so AI agents can drive it, plus reusable "recipes" and watch folders for automation.

The feature catalog also lists vocal isolation, speaker diarization (working out who spoke when), a batch queue, GPU auto-detection and an AI watermark option for generated audio.

How it works

VoiceStudio isn't one model. It's a desktop shell around a large set of open-source speech engines that you install and switch between in a model manager.

Speech generation defaults to its own engine, which is powered by k2-fsa's OmniVoice. The catalog lists over a dozen alternatives, including CosyVoice 3, IndexTTS 2.5, KittenTTS, MLX-Audio, VoxCPM2, GPT-SoVITS, sherpa-onnx and MOSS-TTS, several with their own setup guides.

Transcription defaults to WhisperX, with Faster-Whisper, MLX Whisper, NVIDIA's Parakeet, Moonshine and FunASR as options. Live dictation uses sherpa-onnx. You can also point it at any OpenAI-compatible server if you'd rather not run speech-to-text locally.

The front end is an Electron app with a Python backend. (Version 0.5.3 was the last release built on Tauri. Electron is now the only desktop app, so Tauri users have to install it separately.) The project says local workflows run entirely on your machine, remote services are optional, and usage analytics only run if you consent.

Hardware

The README is straightforward about what runs where:

• NVIDIA GPU on Windows or Linux gets CUDA acceleration.
• Apple Silicon gets Metal acceleration.
• No dedicated GPU: it runs on the CPU, more slowly, using a small CPU build of PyTorch that needs about 5 GB of free disk.
• Windows on ARM is experimental and CPU-only, with the Python backend running under x64 emulation.
• Intel Macs get the UI only and have to connect to a backend running on another machine.

Requirements vary a lot by engine. The project keeps separate performance and benchmark docs.

Trying it

On macOS or Linux it's a one-line install:

curl -fsSL https://voicestudio.sh/install | sh

On Windows, in PowerShell:

irm https://voicestudio.sh/install | iex

The installer keeps your settings, projects and models across upgrades, and --uninstall removes the app while leaving your data. If you'd rather not pipe a script into your shell, there are .dmg, .exe, .AppImage and .deb downloads on the releases page, plus a Docker guide. To run from source:

git clone https://github.com/debpalash/VoiceStudio.git
cd VoiceStudio
bun install
bun run setup:api
bun run dev

Once it's running, open Voice cloning, pick a voice or add a clean reference recording, type your text and generate. The app prompts you to install the model it needs.

The fine print

• The licence covers the app, not the models. AGPL-3.0 applies to VoiceStudio's own code. Model weights, tokenizers, voices and any conditions on generated output are separate, and the README says outright that even a paid app licence doesn't grant those rights. The model manager shows each model's source notices and flags gaps in the licence review, but the project says this doesn't certify commercial use. If you plan to sell anything you make with it, check each model's terms yourself.
• Consent matters. "Clone voices only with permission," says the README. The optional AI watermark helps mark generated audio as synthetic.
• It's a big, fast-moving app. A dozen-plus engines, an Electron shell, a Python backend, and a recent switch from Tauri make for a lot of moving parts. Expect some setup friction, especially on less common hardware.

Who it's for

VoiceStudio fits people who want ElevenLabs-style tools without sending their audio to someone else's servers: podcasters and video makers dubbing their own content, writers producing audiobooks, anyone who wants offline dictation, and tinkerers who want to compare speech models side by side. The local API and MCP server also make it a handy speech backend for automation and agent setups.

The GitHub repo and voicestudio.sh are the places to start, and it's in the resource index now.

End of transmission.

BRUTAL is developed by Ahwoo in collaboration with RocketWerkz, both of them Hall's Auckland companies. Work started in 2022, and it's free to use in commercial games with no royalties.

A framework, not an engine

The README is blunt about what BRUTAL isn't: "There is no editor, no scene graph and no renderer, and we're not adding them." The team says it will reject pull requests that try to grow it in that direction, because "adding everything is how the industry ended up with the kind of engines we don't want to use."

What you get instead is a foundation. The project compares it to the Linux kernel versus a distro like Ubuntu: BRUTAL handles the low-level layer and you build the game-specific systems on top. RocketWerkz built Kitten Space Agency directly on it. Ludeon Studios built a whole engine on it instead.

What's in the box

The core is Brutal.Interop, a custom interop layer that gives modern C# and .NET direct access to native APIs and C/C++ libraries. Around that sit 48 libraries, each its own NuGet package, so you reference only what you need:

• Foundations: unmanaged memory and allocators, collections and string handling that don't allocate, vector and matrix maths, a job system, logging and localisation.
• Graphics: Vulkan bindings plus the Vulkan Memory Allocator, OpenGL, shader compilation through ShaderC and Slang, and texture, KTX, glTF and mesh-optimisation loaders.
• Windowing and UI: GLFW and SDL (with SDL's image, mixer and font add-ons), Dear ImGui on the docking branch, and ImPlot.
• Everything else: Jolt and Box2D for 3D and 2D physics, FMOD and OpenAL for audio, RakNet for networking, RenderDoc capture integration, native file dialogs, and even NotCurses for terminal UIs.

The design goal running through all of it is what Hall calls an "obsessive focus on reducing allocations and unnecessary overhead." BRUTAL uses unmanaged memory and unsafe code wherever it makes sense, which keeps the .NET garbage collector out of the hot path.

The RimWorld test

The strongest argument for BRUTAL is RimWorld. On October 12, Ludeon announced update 1.7, which moves the game from Unity to Waylith, Ludeon's own engine, built with BRUTAL as its foundation. Ludeon's numbers:

• 2 to 4 times better performance overall in their tests.
• 2.2 times better on a stress-tested late-game colony compared with 1.6.
• A 1,500-mod pack went from 14 minutes to 6 minutes to load.

The bigger achievement is what didn't break. Ludeon says the game looks and plays exactly the same, 1.6 saves load in 1.7 (and back again), and "the vast majority of mods work on 1.7 without any changes." For a game whose community runs thousands of mods, that's the hard part. Modders also get the latest C# language features. The one casualty: PCs more than about ten years old may not run 1.7. It's on Steam's unstable beta branch now.

Ludeon also says Waylith will power its next, unannounced game.

Built for a solar system at real scale

BRUTAL grew out of Kitten Space Agency, a free pre-alpha spaceflight sim that runs a solar system at real scale. A game like that needs to track a spacecraft precisely as it crosses interplanetary distances, then just as precisely as it docks with another ship, and general-purpose engines aren't built around that. BRUTAL let RocketWerkz design positions, coordinates and rendering around the simulation and dig into performance problems directly. KSA won Most Innovative Hi-Tech Creative Technology Solution at the 2026 NZ Hi-Tech Awards.

Felipe Falanghe, who created Kerbal Space Program, collaborates on KSA and is building his next game on BRUTAL too. "Coming from Unity to working in BRUTAL, initially it was a bit daunting," he said. "But once you're there, you own everything that you've created."

The README lists six projects so far: RimWorld via Waylith, plus Kitten Space Agency, Torpedia, Art of the Rail and Gruntz from RocketWerkz, and Afterskies from Floating Origin Interactive.

Trying it

You need the .NET 10 SDK, Windows or Linux, and a Vulkan 1.3 GPU if you're rendering. (Ahwoo's site lists macOS as a target too.) The README's hello-world just opens a window:

dotnet new console -n HelloBrutal
cd HelloBrutal
dotnet add package Ahwoo.Brutal.Core
dotnet add package Ahwoo.Brutal.Glfw

using Brutal.GlfwApi;
using Brutal.Numerics;

if (!Glfw.Init())
    throw new Exception("Failed to initialize GLFW");

Glfw.WindowHint(GlfwWindowHint.ClientApi, 0);
var window = Glfw.CreateWindow(new GlfwWindow.CreateInfo
{
    Title = "Hello BRUTAL",
    Size = new int2(1280, 720),
});

while (!window.ShouldClose)
    Glfw.PollEvents();

Glfw.Terminate();

That's a window with no graphics API attached. Everything after that is up to you: add the Vulkan packages to write a renderer, ImGui for debug UI, the job system for parallelism, FMOD and RakNet for audio and networking.

The licence, read closely

Headlines say BRUTAL only asks for a credits line. The actual licence asks for a little more. It's MIT-based with an attribution clause, and a game built with it has to:

1. include the BRUTAL copyright notice in its credits screen or equivalent,
2. show the BRUTAL logo before gameplay starts, and
3. ship NOTICE.txt with the product.

The logo requirement is waived for non-profit projects, and Ahwoo will arrange a separate commercial licence if you don't want to show it. The licence isn't OSI-approved yet. The team says it simply hasn't submitted it, and plans to refine it with community feedback.

The fine print

• The name is a warning. "We called it BRUTAL because it can be brutal to use at times," says Ahwoo's head of engineering, Rian Drake. "There are no guardrails." It's aimed at experienced programmers who want to make their own architecture decisions.
• It's a day-one open-source project. The repo has no build scripts, project files or solution yet, so for now you use the NuGet packages and read or fork the source. Early forum posts also pointed out that the linked API docs weren't public at launch.
• Contributions are scoped tightly. Commits need a sign-off, AI-assisted contributions have their own rules, and anything that drifts from the "few low-level things done well" mission gets turned away.

Why Hall did it

Part of the motivation is personal. In May 2025, Unity sent RocketWerkz a notice threatening to revoke its licences, and Hall said the evidence included two people who had never worked there. He told PC Gamer the episode confirmed the studio's existing move away from Unity for new projects.

The broader argument is about dependence. Hall told GamesIndustry.biz he worries that as AI coding tools erode software companies' competitive moats, engine vendors will try to squeeze more out of developers who feel they can't leave, "whether through royalties, subscriptions, or more restrictive licensing." He's careful not to tell anyone to drop Unity or Unreal tomorrow: "For many projects, they're absolutely the right choice." The point is having a way out. The README puts it in one line: "You are only as independent as your tools are."

He also expects more frameworks like BRUTAL to appear as the cost of building alternatives falls, and he's given his own an exit hatch: "If one day we stop being accountable to developers ourselves, they should have the ability to fork the framework and go their own way."

Who it's for

BRUTAL isn't the place to make your first game. It's for teams whose game doesn't fit a general-purpose engine, like real-scale simulations or colony sims with thousands of mods, and for studios that want to own their technology all the way down. RimWorld showed a successful game can make that move without breaking its community. If your game is hard to make, BRUTAL is worth a look.

The GitHub repo, the BRUTAL site and the forums are the places to start, and it's in the resource index now.

End of transmission.

It was on GitHub Trending today, picking up more than a thousand stars in a day. It's written in Swift and licensed under MIT.

What it does

xtool reimplements the parts of Xcode you need to get an app onto a phone, using open standards instead of Xcode's project format. The project lists three jobs:

• Build a SwiftPM package into an iOS app. No .xcodeproj, just a Package.swift.
• Sign and install iOS apps on a real device.
• Talk to Apple Developer Services from code: certificates, provisioning profiles, app IDs.

It also ships a library called XKit, so your own Swift programs can talk to Apple Developer Services and iOS devices the same way xtool does:

// package dependency:
.package(url: "https://github.com/xtool-org/xtool", .upToNextMinor(from: "1.2.0"))
// target dependency:
.product(name: "XKit", package: "xtool")

How it pulls it off

xtool doesn't pretend Apple's SDK doesn't exist. It uses the SDK, just without Xcode around it. Four pieces fit together:

The Swift toolchain. You install the official open-source Swift toolchain for Linux from swift.org. That gives you the compiler and SwiftPM.

A Darwin Swift SDK built from Xcode.xip. You download Xcode's .xip archive from Apple's developer site, but you never run it. During setup, xtool unpacks it and generates an iOS Swift SDK, the cross-compilation bundle SwiftPM uses to target another platform. Afterwards swift sdk list shows a darwin entry.

usbmuxd for the device. On Linux, xtool talks to your iPhone over USB through usbmuxd, the open-source daemon behind the libimobiledevice tools. On Windows you pass the USB device through to WSL with Microsoft's USBIPD.

Apple Developer Services. Signing means talking to Apple's servers. You can log in with an App Store Connect API key, which needs a paid Developer Program membership, or with an Apple ID and password, which works with any account but uses private APIs. The docs say your credentials only go to Apple.

With those in place, xtool compiles your package against the Darwin SDK, wraps the result in an app bundle, provisions and signs it, and installs it on the phone.

Trying it

The Linux/Windows install guide has the full steps. In short:

# prerequisites: Swift toolchain (swift.org), usbmuxd, and Xcode.xip from Apple
sudo apt-get install usbmuxd

# install xtool (it ships as an AppImage)
curl -fL \
  "https://github.com/xtool-org/xtool/releases/latest/download/xtool-$(uname -m).AppImage" \
  -o xtool
chmod +x xtool
sudo mv xtool /usr/local/bin/

# one-time setup: log in, then point it at Xcode.xip to build the SDK
xtool setup

After that, the command line will feel familiar if you've used cargo or npm:

xtool new       # create a new xtool SwiftPM project
xtool dev       # build and run it
xtool devices   # list connected devices
xtool install   # install an .ipa on your device
xtool launch    # launch an installed app
xtool ds        # interact with Apple Developer Services

The README's screenshot shows the whole loop running from VS Code, which makes sense as the editor once Xcode is out of the picture. The first-app tutorial walks you from an empty folder to an app on your phone.

The fine print

• You still need Apple's SDK. xtool replaces the Xcode app, not Apple's SDK. You download Xcode.xip with an Apple ID, and Apple's license terms for it still apply.
• Signing still goes through Apple. Free Apple IDs come with Apple's usual limits on sideloaded apps, and the password login relies on private APIs that Apple could change at any time.
• It builds and deploys. That's all. There's no Interface Builder, Instruments or Simulator in its feature list, and App Store submission isn't a listed feature either.
• It's SwiftPM-first. Your app is defined as a Swift package. That's cleaner, but an existing .xcodeproj app needs restructuring first.

Who it's for

• Swift developers on Linux or Windows who want an app on their own iPhone without buying a Mac.
• CI setups that would rather build iOS artifacts on cheap Linux runners than on macOS ones.
• Mac users who are tired of .xcodeproj merge conflicts and want a declarative, package-based workflow from the terminal.
• Tool builders who want to script Apple Developer Services and devices with XKit.

xtool won't retire Xcode overnight. What it does is turn "building an iOS app requires a Mac" into "building an iOS app requires a Swift toolchain and a USB cable." That opens iOS development to a lot more people.

The GitHub repo and the docs at xtool.sh are the places to start, and it's in the resource index now.

End of transmission.

It's one of the busiest repositories in the console-preservation scene right now, with tens of thousands of stars and thousands of commits, and it's licensed under the GPL-2.0.

Emulation vs. porting

An emulator pretends to be the console. It simulates the hardware and the operating system every frame while the game runs, and that pretending costs a lot of CPU. AnyPS5 does the work once, ahead of time:

• It converts the executable into the native format of the target system.
• It replaces the console's system libraries with native shared libraries that your OS loader links in, the same way any other program pulls in a .so or .dll.
• It translates the GPU shaders into SPIR-V so they run on Vulkan, and caches the results to disk.

There's no separate runtime process sitting between the game and your hardware. Once converted, it's just a program.

The three moving parts

The relinker. This is the command-line tool you actually run. It reads the executable's imports, checks its system calls, filters out functions the game never uses, converts any bundled modules that ship with it, and writes out a Linux ELF or a Windows PE. An optional --to-intel pass rewrites AMD-only CPU instructions so the result runs on Intel chips too.

The system libraries. PS5 games call into the console's own libraries by numeric ID rather than by name. AnyPS5 reimplements those libraries from scratch as native shared libraries and labels each function with the ID the game expects, so the OS loader can match them up without knowing anything about PlayStation. The project tracks how much of each library it has implemented on its progress page.

The shader recompiler. The PS5's GPU is AMD RDNA, and its shaders are compiled for that hardware. The recompiler decodes them, rebuilds their control flow, converts them to an intermediate form, optimizes it and emits SPIR-V for Vulkan. Compiled shaders are cached in memory and on disk, so the stutter of compiling one only happens the first time.

Where it stands

Early, and honest about it. The compatibility list has one verified game so far: Dreaming Sarah, a 2D platformer, playable on Windows. It holds a steady 60 fps on a GTX 1050 Ti with an i5-7500, and around 36 fps on Intel HD 620 laptop graphics. Linux status for it is still marked unknown.

The project also fails loudly on purpose. Anything it doesn't support yet throws an error, prints what went wrong and exits, rather than limping along with glitches. For a project at this stage that's the right call: crashes with a clear message are much easier to fix than mystery bugs.

Controllers work through SDL, including analog sticks and triggers, and keyboard and mouse can be mapped with an anyps5-input.ini file. The input mapping doc has the format.

Trying it

There are no prebuilt releases yet, so you build it yourself. The build guide covers it, but in short you need:

• An x86-64 machine with Git, CMake 3.22.1 or newer, Ninja and a C++20 compiler.
• On Linux, GCC and binutils.
• On Windows, one specific MinGW-w64 build: WinLibs GCC 15.2.0 (UCRT, POSIX threads). Other compilers aren't supported.
• A GPU with Vulkan support to actually run the result.

Building produces the relinker plus the replacement system libraries. You point the relinker at a game's executable and pick Linux or Windows output, and it lays out a folder with the converted program, a libs/ directory of system libraries and the game's own resources. The usage guide walks through the options.

The legal part

AnyPS5 ships no games, no console firmware, no encryption keys and none of Sony's libraries. Everything it provides is written from scratch. The project frames itself as an interoperability, research and preservation tool, and it puts the responsibility on you: any game you feed it has to be one you obtained and use legally.

Why it's worth watching

Most console preservation work has meant emulators, and emulators for modern consoles are hard: they need beefy hardware and years of work before anything big runs well. Converting the game into a native program sidesteps a lot of that overhead. It's a long road from one 2D platformer to the rest of the library, but the architecture is clean, the documentation is unusually good for a project this young, and the pace of commits is fast.

If you want to follow along, the GitHub repo is the place to start, and it's in the resource index now. The architecture doc is a good read even if you never build it.

End of transmission.

Paperless-ngx replaces the drawer. Scan a document, or drop in a PDF, and it reads the text with OCR, figures out who sent it and what it is, tags it, and files it into a searchable archive on your own server. It's one of the most popular self-hosted apps there is, with around 45,000 stars on GitHub, and once it's running it quietly changes how you deal with paper.

Where it came from

Paperless-ngx is the third generation of the idea. The original Paperless was followed by Paperless-ng, a rewrite with a modern interface. When that project's single maintainer stepped back, the community forked it as Paperless-ngx so that a team would carry it forward instead of one person. It's GPL-3.0 licensed, built on Django and Angular, and on the 3.x release line.

What it does

• OCR on everything. It uses the open-source Tesseract engine to read more than 100 languages, adding searchable, selectable text even to image-only scans.
• Archival PDFs. Each document is stored as a PDF/A, the format built for long-term storage, next to the untouched original.
• Automatic filing. A machine-learning classifier trained on your own documents suggests and assigns tags, correspondents and document types.
• Full-text search with autocomplete, relevance ranking, highlighted matches and "more like this".
• Many file types. PDFs, images and plain text work out of the box. Word, Excel, PowerPoint and LibreOffice files work with an optional add-on.
• Email import. It watches mail accounts and pulls in attachments according to rules you define.
• Workflows that assign metadata, send emails, call webhooks and more, based on triggers.
• Multiple users with global and per-document permissions, two-factor login, and share links that can expire.
• Your files stay plain. Documents are ordinary files on disk, in a folder layout you control. Nothing is locked inside a database.

The four things every document has

Paperless doesn't use folders. Everything is organized with four kinds of metadata, and understanding them is the key to the whole app:

CORRESPONDENT   who it's from or to      Electric Co, IRS, Dr. Patel
DOCUMENT TYPE   what kind of thing it is  invoice, contract, statement
TAGS            any labels you like       taxes-2026, car, paid, inbox
STORAGE PATH    where the file lands      {{ correspondent }}/{{ created_year }}/{{ title }}

Tags are the clever part. A document can carry many tags, so "car insurance renewal" can live under car, insurance and taxes-2026 at the same time. A folder can't do that. Add custom fields (amounts, due dates, policy numbers) and an archive serial number that matches the label on the physical copy in your binder, and you can find anything, digital or paper.

Install it with Docker

The quickest route is the official install script. It asks a few questions, writes the compose files, starts the containers and creates your admin account:

bash -c "$(curl --location --silent --show-error \
  https://raw.githubusercontent.com/paperless-ngx/paperless-ngx/main/install-paperless-ngx.sh)"

If you prefer to see every piece, set it up by hand. The project ships compose files for SQLite, PostgreSQL and MariaDB, each with an optional -tika variant that adds Office document and email support. PostgreSQL is the recommended choice for new installs. Trimmed down, the Postgres version looks like this:

services:
  broker:
    image: docker.io/valkey/valkey:9-alpine
    restart: unless-stopped
    volumes:
      - redisdata:/data
  db:
    image: docker.io/library/postgres:18
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql
    environment:
      POSTGRES_DB: paperless
      POSTGRES_USER: paperless
      POSTGRES_PASSWORD: paperless
  webserver:
    image: ghcr.io/paperless-ngx/paperless-ngx:latest
    restart: unless-stopped
    depends_on: [db, broker]
    ports:
      - "8000:8000"
    volumes:
      - data:/usr/src/paperless/data
      - media:/usr/src/paperless/media
      - ./export:/usr/src/paperless/export
      - ./consume:/usr/src/paperless/consume
    env_file: docker-compose.env
    environment:
      PAPERLESS_REDIS: redis://broker:6379
      PAPERLESS_DBHOST: db
      PAPERLESS_DBENGINE: postgresql
volumes:
  data:
  media:
  pgdata:
  redisdata:

Grab the matching docker-compose.env and .env from the repo's docker/compose folder, then set at least these in docker-compose.env:

# Required. Generate one with:
#   python3 -c "import secrets; print(secrets.token_urlsafe(64))"
PAPERLESS_SECRET_KEY=change-me

PAPERLESS_TIME_ZONE=America/New_York
PAPERLESS_OCR_LANGUAGE=eng

# Your host user's IDs (run: id -u / id -g), so you can
# write into the consume folder
USERMAP_UID=1000
USERMAP_GID=1000

# Only if you'll reach it from a domain
#PAPERLESS_URL=https://paperless.example.com

Then:

docker compose pull
docker compose up -d
# open http://localhost:8000 and create your superuser

Getting paper in

There are four doors into Paperless, and most setups end up using all of them:

• The consume folder. Anything dropped into ./consume is picked up, processed and moved into the archive. Point your scanner's "scan to network folder" at it through a Samba share or FTP, and scanning becomes a one-button job. (The file leaves the consume folder once it's processed. That's expected.)
• Drag and drop. Drop a file anywhere in the web interface.
• Email. Add an IMAP account under Settings → Mail, then write rules: which folder to watch, which attachments to take, which tags to apply, and what to do with the message afterwards.
• Phone. Community mobile apps scan and upload straight from your camera. The project wiki keeps a list of them.

Tip: if your consume folder lives on an NFS share, set PAPERLESS_CONSUMER_POLLING_INTERVAL. Network file systems don't send the change notifications Paperless listens for, so without polling, new files just sit there.

Let it file things for you

This is where Paperless earns its keep. Every tag, correspondent, document type and storage path has a matching rule that runs against each new document's text:

Any      any of the words appear        "electric power"
All      every word appears, any order  "invoice 2026"
Exact    the exact phrase appears       "Bank of America"
Regex    a regular expression           Policy\s+No\.\s*\d+
Fuzzy    close-enough partial match     Hydro Quebec
Auto     learn from how you've filed things before

Auto is the default, and it gets good fast. File your first few dozen documents by hand and the classifier learns your habits. A new statement from your bank arrives already tagged, typed and assigned. Use the explicit rules for the cases where you want certainty, such as "anything containing my policy number goes under insurance".

Workflows

Workflows go a step further: when this happens, do that. Triggers include a document starting to be consumed, being added, being updated, or a scheduled date. Actions include assigning or removing metadata, sending an email, calling a webhook, removing a PDF password, or moving a document to the trash. Some real-world uses:

• Everything that arrives by email from your accountant gets the taxes tag and is shared with your partner's account.
• Warranty documents trigger a scheduled reminder email 30 days before a custom "warranty ends" date field.
• Bank statements, which always come password-protected, get the password stripped on arrival so they can be OCR'd and searched.
• A webhook pings your home-automation system whenever a new invoice lands.

Barcodes and ASNs

For heavy paper users: Paperless reads barcodes on PDF pages. Print a sheet of ASN barcode stickers, put one on each paper document before scanning, and the archive serial number is set automatically. To find the original later, read the ASN off the screen and pull that number from your binder. Barcode pages can also split a big batch scan into separate documents.

The optional AI features

Recent versions add opt-in AI features on top of the classic classifier: LLM-written suggestions for titles, dates and tags, chatting with a single document or your whole archive, and similar-document search. They're off by default and work with a local model through Ollama or any OpenAI-compatible API.

Think before you switch them on. With a remote provider, your document text leaves your server, and that defeats much of the point of self-hosting tax returns and medical letters. If you want these features, a local model keeps everything at home.

Backups, and one big warning

The project says it plainly: Paperless stores your documents unencrypted, and you should never run it on an untrusted host. Run it on your own hardware or a server you control, keep it off the open internet (use a VPN like WireGuard or Tailscale to reach it from outside), and back it up.

For backups, use the built-in exporter. It writes every document plus all metadata into a folder that can be re-imported into a fresh install:

docker compose exec -T webserver document_exporter ../export

Put that on a nightly cron job and copy the export folder off the machine with your usual backup tool. A document archive with no off-site backup is just a fancier drawer that can burn down.

Running it on small hardware

Paperless runs fine on a Raspberry Pi 4 or a cheap mini PC. On low-power machines:

• Use SQLite instead of Postgres to save memory.
• Set PAPERLESS_OCR_PAGES=1. The first page is usually enough to find a document.
• Lower PAPERLESS_TASK_WORKERS and PAPERLESS_THREADS_PER_WORKER, so a big batch doesn't freeze the machine.
• Set PAPERLESS_WEBSERVER_WORKERS=1.
• Let your scanner do the OCR if it can, and leave PAPERLESS_OCR_MODE on auto.

Tips from the trenches

• Use an inbox tag. New documents get the inbox tag automatically. Review the inbox once a week, fix anything mis-filed, and remove the tag. Every correction trains the classifier.
• Start with the backlog in batches. Scanning ten years of paper in one go is overwhelming. Do a box a weekend.
• Keep the paper you're legally required to keep. A scan isn't always a legal substitute. Put an ASN on those originals and keep them in a binder in number order.
• Try the demo first. There's a public demo at demo.paperless-ngx.com (login demo / demo). It resets often, so don't upload anything real.

Paperless-ngx or Mayan EDMS?

The other big name in self-hosted document management is Mayan EDMS, which gets its own transmission today. The short version: Paperless-ngx is built for a household or small office that wants paper to vanish into a searchable archive with as little effort as possible. Mayan is built for organizations that need formal document types, approval workflows, version control and fine-grained access control, and it asks for more setup and more server in return. For most homelabs, Paperless is the right first stop.

Verdict

Paperless-ngx is the rare self-hosted app that pays you back in time every week. The setup is a compose file. The first weekend of scanning is a chore. After that, paper stops being a problem: it goes in the scanner, comes out tagged and searchable, and the drawer gets recycled.

Start with the GitHub repo and the documentation, which is excellent. Links are also in the downloads directory and the resource index.

End of transmission.

Mayan is an electronic document management system in the enterprise sense. It has OCR and search like the others, but its real strengths are structure and control: document types with required metadata, multi-step approval workflows, version history, digital signatures and permissions down to a single document. It's free and open source (GPL-2.0), written in Python on Django, has been developed for more than a decade, and is on the 4.12 release line.

The mental model

Mayan has more moving parts than a home-scanning app, and they make sense once you see how they fit together. Everything hangs off the document type:

DOCUMENT TYPE   "Invoice", "Contract", "HR Record"
  ├─ metadata types   vendor, amount, due date (required or optional)
  ├─ OCR + parsing    on/off, language
  ├─ workflows        which processes this type goes through
  ├─ retention        trash after N days, delete after N more
  └─ antivirus        scan uploads with ClamAV or not

Then, on top of documents:
  TAGS       colored labels
  CABINETS   hand-made folder trees (a document can be in several)
  INDEXES    folder trees Mayan builds for you from templates
  ACLs       who can do what, per document, type or object

The distinction between cabinets and indexes is the most important one to grasp. Cabinets are folders you curate by hand. Indexes are generated automatically: you write a template once, and Mayan sorts every document into a virtual folder tree from its metadata, updating it as documents change.

Feature tour

• Metadata. Typed fields per document type, with defaults, lookups and validation. "Invoice" can require a vendor and an amount, while "Contract" requires parties and an expiry date.
• OCR and parsing. Tesseract is built in, and the work can be spread across several worker machines. Text from born-digital files is parsed directly. Built-in file metadata (author, camera settings, GPS) is extracted automatically.
• Workflows. Real state machines with states, transitions, actions on entry and exit, and automatic expiry and escalation. Every change is logged.
• Versions. Multiple versions of a document, each of which can be downloaded or restored, with an audit trail.
• Check-out and check-in, so two people don't edit the same document at once.
• Signatures. Verify embedded cryptographic signatures, attach detached ones, and record captured handwritten signatures.
• Smart links that connect related documents automatically by their metadata, such as a purchase order and its invoices.
• Duplicate detection, with exact-file and exact-label matching out of the box.
• Search. Full-text search over content and metadata. A built-in backend is the default, and Elasticsearch is available for big archives.
• Access control. Unlimited roles, a permission for every single operation, and ACLs on individual objects, with LDAP, OpenID Connect and other single sign-on options.
• Antivirus. Optional ClamAV scanning of uploads, switched on per document type.
• A full REST API with OpenAPI documentation, so other systems can push documents in and pull them out.

Install it with Docker

The official route is Docker Compose, and getting started really is three commands:

curl https://gitlab.com/mayan-edms/mayan-edms/-/raw/master/docker/docker-compose.yml -O
curl https://gitlab.com/mayan-edms/mayan-edms/-/raw/master/docker/.env -O
docker compose up --detach

Read this before you run the last command. The compose file falls back to default passwords for its database, message queue and cache (mayandbpass and friends). Set your own in .env before the first start, because they're baked into the database when it's created:

# add to .env
MAYAN_DATABASE_PASSWORD=a-long-random-string
MAYAN_RABBITMQ_PASSWORD=another-long-random-string
MAYAN_REDIS_PASSWORD=and-another-one

# the web UI listens on port 80 by default; move it if 80 is taken
MAYAN_FRONTEND_HTTP_PORT=8080

The stack is assembled with Compose profiles. The default in .env is:

COMPOSE_PROFILES=all_in_one,postgresql,rabbitmq,redis

That runs the Mayan app (web interface and workers in one container) with PostgreSQL for data, RabbitMQ for the task queue and Redis for locking and caching. Add profiles as you need them:

elasticsearch       a faster search backend for large archives
traefik             reverse proxy with automatic Let's Encrypt HTTPS
postgresql-backup   scheduled database dumps
index_mirror        expose an index as a read-only folder tree on the host
cabinet_mirror      the same, for a cabinet
extra_worker_*      split workers out to scale up

On first load, the login page shows automatically generated admin credentials. Log in with them, change the password straight away (the notice disappears once you do), and create real user accounts.

Be realistic about resources. Even the all-in-one setup runs four services, including a database and a message broker. Plan on a few gigabytes of RAM and a few CPU cores, more if you'll OCR a lot. This is a VPS or homelab-server app, not a Raspberry Pi one.

A worked example: invoice approval

Here's what Mayan is built for. Say invoices arrive by email, need a manager's approval, and must be kept for seven years.

1. The document type

Create an Invoice document type with required metadata types vendor, amount and due_date. Under its retention settings, keep files for seven years before they move to the trash. Turn on ClamAV for it, since email attachments are where malware arrives.

2. The source

Add an email source (IMAP or POP3) pointed at invoices@, assigned to the Invoice type. Attachments come in typed and ready for metadata. For paper, a watch folder that your scanner drops into works the same way, and a staging folder lets you preview files before uploading them.

3. The workflow

[Received] --submit--> [Awaiting approval] --approve--> [Approved] --pay--> [Paid]
                               |
                               +--reject--> [Rejected]

Awaiting approval: escalate to the finance lead if untouched for 3 days
Approved:          action = add tag "approved", email accounts payable

Each transition can be limited to specific roles: only managers can approve, and only finance can mark something paid. Every step is recorded in the document's workflow log with who did it and when.

4. The index

Finally, an index that files invoices automatically by year, then vendor. Each level is a small template:

Level 1:  {{ document.date_added|date:"Y" }}
Level 2:  {{ document.metadata_value_of.vendor }}

Browse the index and you see 2026 / Electric Co / …, rebuilt live as invoices arrive. Turn on the index_mirror profile and the same tree appears as a read-only folder on the server, which is handy for backup tools or a file share.

Things to know before you commit

• There's a learning curve. Document types, metadata types, indexes, smart links and workflows are each separate screens. Budget an afternoon to model your documents before you upload anything, because restructuring later is much harder.
• The interface is functional, not fancy. It's a dense admin-style UI built for daily office work, not a slick consumer app.
• Back up two things: the PostgreSQL database (the postgresql-backup profile helps) and the app volume at /var/lib/mayan, which holds the files themselves. One without the other is useless.
• Keep it private. Like any archive of sensitive paperwork, run it behind a VPN or an authenticated reverse proxy. The traefik profile handles HTTPS, but HTTPS alone doesn't make it safe to expose to the internet.
• The docs are thorough, and the project also publishes books and a knowledge base if you're deploying it seriously.

Mayan EDMS or Paperless-ngx?

I covered Paperless-ngx in a separate transmission today, and they're the two names that come up every time. They solve different problems:

                    PAPERLESS-NGX            MAYAN EDMS
Built for           homes, small offices     teams, organizations
Organizing          tags, auto-classifier    types, metadata, indexes
Workflows           automation rules         approval state machines
Versions            yes                      yes, with check-out/in
Signatures          no                       verify and capture
Permissions         per user and document    roles and ACLs
Setup effort        an evening               a weekend of planning
Hardware            Raspberry Pi is fine     a real server
License             GPL-3.0                  GPL-2.0

If your goal is "make the paper pile searchable and stop thinking about it", choose Paperless-ngx. If you're running a small business, a nonprofit or a club, where documents have owners, approvals, versions and retention rules, Mayan is the one built for that, and it's hard to beat for free software.

Verdict

Mayan EDMS is what you reach for when documents are part of a process rather than just a pile. It asks more of you up front, in planning and in hardware, and gives you something few open-source tools offer in return: a document system with real structure, audit trails and access control, running entirely on your own server.

Start with the documentation and the GitLab repository. Links are also in the downloads directory and the resource index.

End of transmission.

Glance collapses all of that into one page. It's a self-hosted dashboard that pulls your feeds, news, videos, weather, markets and server status into a single, fast, good-looking start page. You describe the page in one YAML file and Glance does the rest. It runs as a single small binary or a Docker container, and it's quietly become one of the most popular self-hosted projects on GitHub, at over 35,000 stars.

What it is (and isn't)

Glance is a reading dashboard. Its job is to put the things you check every day in one place, laid out in columns, so one glance (hence the name) tells you what changed. It's written in Go, licensed AGPL-3.0, and the whole thing ships as a single binary under 20 MB with few dependencies.

It is not a live monitoring system. This is the single most important thing to understand before you set it up:

• Glance fetches data when you load the page, then caches it. Nothing runs in the background.
• The page doesn't update itself. A refresh pulls fresh data, once the cache for that widget has expired.
• Clocks and relative timestamps ("3h ago") do tick on their own, but feeds and stats don't.

That design is why it's so light. There's no database, no worker process, no polling loop eating CPU at 3 a.m. If you want alerts at 3 a.m., pair it with something like Uptime Kuma. If you want a start page that loads in about a second, this is it.

The widgets

Everything on a Glance page is a widget. The built-in set covers most of what a self-hoster checks in a day:

FEEDS & NEWS
  rss              RSS and Atom feeds, several display styles
  hacker-news      Hacker News front page
  lobsters         Lobsters front page
  reddit           any subreddit, with optional thumbnails
  videos           latest uploads from YouTube channels
  twitch-channels  who's live
  releases         new releases from GitHub, GitLab, Docker Hub

HOMELAB
  monitor          is each service up, and how fast did it answer
  docker-containers  status of your containers
  server-stats     CPU, memory and disk usage
  dns-stats        AdGuard Home, Pi-hole or Technitium stats
  repository       stars, issues and PRs for a GitHub repo

EVERYDAY
  weather, calendar, clock, markets, bookmarks, search, to-do

BUILD YOUR OWN
  custom-api       fetch any JSON API and render it with a template
  extension        pull HTML from a URL you control
  html, iframe     drop in your own markup or embed a page

LAYOUT
  group            stack widgets as tabs
  split-column     put widgets side by side

Every widget accepts a title to rename it, and most accept a cache duration such as 30m, 12h or 1d. The exceptions are weather and calendar, which update hourly on a fixed schedule.

Install it with Docker

The fastest route is the official compose template, which sets up a sensible folder layout in one command:

mkdir glance && cd glance && curl -sL \
  https://github.com/glanceapp/docker-compose-template/archive/refs/heads/main.tar.gz \
  | tar -xzf - --strip-components 2

That gives you docker-compose.yml, config/glance.yml and config/home.yml. Edit them, then:

docker compose up -d

If you'd rather build it by hand, the compose file is tiny:

services:
  glance:
    container_name: glance
    image: glanceapp/glance
    restart: unless-stopped
    volumes:
      - ./config:/app/config
    ports:
      - 8080:8080

Grab the example config to start from, and bring it up:

mkdir config && wget -O config/glance.yml \
  https://raw.githubusercontent.com/glanceapp/glance/refs/heads/main/docs/glance.yml
docker compose up -d
# open http://localhost:8080

No Docker? There are precompiled binaries for Linux, Windows and macOS on x86, x86_64, ARM and ARM64. Drop the binary next to a glance.yml and run it. On Linux it's easy to wrap in a systemd service under /opt/glance/. It also builds from source with Go 1.23 or newer: go build -o build/glance .

How the config works

The whole dashboard is one YAML file, and the structure is three levels deep: pages contain columns, and columns contain widgets.

pages:
  - name: Home
    columns:
      - size: small
        widgets:
          - type: calendar
      - size: full
        widgets:
          - type: hacker-news
      - size: small
        widgets:
          - type: weather
            location: London, United Kingdom

Each page becomes a tab across the top, and you can have as many as you like: a Home page, a Homelab page, a Videos page. Columns follow a few strict rules worth knowing up front, because breaking them is the most common first-run error:

• A page has at most three columns.
• It must have one or two full columns.
• small columns are a fixed 300px wide, and full columns share whatever's left.
• Valid shapes: 1 full, 2 full, 1 full + 2 small, or 2 full + 1 small.

The classic layout is small / full / small: quick-glance stuff on the sides, the main reading feed in the middle.

Hot reload

Save the file and Glance picks up the change immediately, with no restart. If you save a broken config, it keeps running the last good one and logs the error. One catch: a reload clears the widget caches, so if you save twenty times in five minutes you can trip rate limits on sites like Reddit. Batch your edits.

Splitting the file, and keeping secrets out of it

Once the config grows, split it up with $include. That's what the compose template does with home.yml:

pages:
  - $include: home.yml
  - $include: homelab.yml

Anything sensitive, such as API keys and tokens, can come from environment variables instead of sitting in the file. Glance can also read Docker secrets:

token: ${GITHUB_TOKEN}
password: ${secret:dashboard_password}

A homelab page that earns its tab

Here's where Glance stops being a news reader and becomes genuinely useful for anyone running services at home. A second page, three widgets:

- name: Homelab
  columns:
    - size: full
      widgets:
        - type: monitor
          cache: 1m
          title: Services
          sites:
            - title: Jellyfin
              url: https://jellyfin.yourdomain.com
            - title: AdGuard Home
              url: https://adguard.yourdomain.com

        - type: docker-containers
          hide-by-default: false

    - size: small
      widgets:
        - type: server-stats
          servers:
            - type: local
              name: Services

monitor sends a GET request to each URL and shows whether it answered with a 200, plus how many milliseconds it took. server-stats shows CPU, memory and disk for the machine Glance runs on.

docker-containers needs access to the Docker socket, so add it to the Glance service's volumes:

    volumes:
      - ./config:/app/config
      - /var/run/docker.sock:/var/run/docker.sock

Then dress up each container with labels in its own compose file, so it shows a proper name, icon and link:

  jellyfin:
    image: jellyfin/jellyfin:latest
    labels:
      glance.name: Jellyfin
      glance.icon: si:jellyfin
      glance.url: https://jellyfin.yourdomain.com
      glance.description: Movies & shows

A word on that socket: mounting docker.sock gives the container control over Docker on the host, which is effectively root. Glance only reads from it, but if you'd rather not hand it the keys, point sock-path at a read-only proxy such as docker-socket-proxy instead.

Build your own widget in five lines

The custom-api widget is the secret weapon. Point it at any JSON endpoint and render the result with a Go template:

- type: custom-api
  title: Random Fact
  cache: 6h
  url: https://uselessfacts.jsph.pl/api/v2/facts/random
  template: |
    <p class="size-h4">{{ .JSON.String "text" }}</p>

Anything with a JSON API becomes a widget: your router, your Home Assistant, a game server, a package tracker. Before writing your own, check the community-widgets repo. There's a good chance someone already built it.

Theming

Glance themes are a handful of HSL values (hue, saturation, lightness, space-separated, no percent signs). Change three numbers and the whole dashboard follows. Naturally, here's one in this site's colors:

theme:
  background-color: 140 30 4
  primary-color: 135 100 60
  contrast-multiplier: 1.2
  presets:
    amber-crt:
      background-color: 30 30 4
      primary-color: 41 100 50
      contrast-multiplier: 1.2

Presets show up in a theme picker on the page, so you can switch between phosphor green and amber without touching the file. For deeper changes, custom-css-file loads your own stylesheet, and there's a light: true option if you're that kind of person. The repo's docs/themes.md has a gallery of ready-made themes to copy.

Locking it down

A dashboard that shows your containers and server stats shouldn't be open to the internet. Glance has built-in username and password auth. Generate a secret key and a password hash:

docker run --rm glanceapp/glance secret:make
docker run --rm glanceapp/glance password:hash mysecretpassword

Then add them to the top of glance.yml:

auth:
  secret-key: ${GLANCE_SECRET_KEY}
  users:
    admin:
      password-hash: ${GLANCE_ADMIN_HASH}

Even with auth on, the safest setup is to keep Glance on your LAN or behind a VPN like WireGuard or Tailscale. If you do expose it, put it behind a reverse proxy with HTTPS.

Tips from setting it up

• Make it your browser's start page. That's where it pays off. Every new tab is the dashboard.
• Set sensible caches. 1m for monitors, 1h or more for feeds, 1d for releases. Long caches keep page loads fast and keep you clear of rate limits.
• Use group to save space. Hacker News and Lobsters in one tabbed widget, or three subreddits in another.
• Feed it the small web. The rss widget is the heart of Glance. Personal blogs and project feeds are where it shines. This site has a feed too, if you want to give it a test.
• Use the releases widget for update-watching. List the projects you self-host and you'll see new versions the morning they ship.

Verdict

Glance does one thing and does it well: it turns a morning of tab-hopping into a single page that loads in about a second. Setup is a compose file and a YAML file, the resource footprint is close to nothing, and the custom-api widget means it grows with whatever else you run. If you keep a homelab, or just read a lot of feeds, it's one of the easiest self-hosted wins there is.

Start with the GitHub repo and the configuration docs, which cover every widget option in depth. The image is in the downloads directory, and Glance is in the resource index.

End of transmission.

How it works

It's not Windows running natively in a container. Under the hood the container runs QEMU with KVM acceleration, so Windows gets a real virtual machine with near-native speed. Docker is the packaging: one image, one config file, and a volume that holds the virtual disk. That makes Windows as easy to spin up, back up and throw away as any other container.

What it can do

• Automatic download and unattended install.
• A web viewer on port 8006, plus RDP on 3389 for a proper client.
• Adjustable CPU cores, RAM and disk size.
• A shared folder between host and guest, extra disks, and USB passthrough.
• Custom ISOs, if you'd rather bring your own installer.
• Several networking modes, including giving Windows its own IP on your LAN.

Every Windows you can think of

The VERSION variable picks the release. A few of the options:

11      Windows 11 Pro          7.9 GB
11l     Windows 11 LTSC         4.7 GB
10      Windows 10 Pro          5.7 GB
10l     Windows 10 LTSC         4.6 GB
7u      Windows 7 Ultimate      3.1 GB
xp      Windows XP Professional 0.6 GB
98      Windows 98              0.7 GB
95      Windows 95              0.6 GB
2025    Windows Server 2025     7.6 GB
2022    Windows Server 2022     6.0 GB
tiny11  Tiny11                  5.3 GB
reactos ReactOS                 0.1 GB

The full list is in the project README, and there's a separate dockur/windows-arm for ARM64 hosts. Yes, you can boot Windows 95 in a container. Fitting for a site that looks like this one.

Quick start

Save this as compose.yml:

services:
  windows:
    image: dockurr/windows
    container_name: windows
    environment:
      VERSION: "11"
    devices:
      - /dev/kvm
      - /dev/net/tun
    cap_add:
      - NET_ADMIN
    ports:
      - 8006:8006
      - 3389:3389/tcp
      - 3389:3389/udp
    volumes:
      - ./windows:/storage
    restart: always
    stop_grace_period: 2m

Then:

docker compose up -d
# open http://localhost:8006 and watch it install

Or as a single command:

docker run -it --rm --name windows -e "VERSION=11" -p 8006:8006 \
  --device=/dev/kvm --device=/dev/net/tun --cap-add NET_ADMIN \
  -v "${PWD:-.}/windows:/storage" --stop-timeout 120 \
  docker.io/dockurr/windows

The install takes a while. When the desktop appears, you're in. The default login is Docker / admin. Change it with the USERNAME and PASSWORD variables before the first boot.

Tuning it

Defaults are 2 cores, 4 GB of RAM and a 64 GB disk. Raise them in the environment block:

    environment:
      VERSION: "11"
      RAM_SIZE: "8G"
      CPU_CORES: "4"
      DISK_SIZE: "128G"

To share files, mount a folder at /shared and it shows up as a Shared folder on the Windows desktop:

    volumes:
      - ./windows:/storage
      - ./example:/shared

Before you try it

• You need KVM. A Linux host with hardware virtualization enabled works. So does Windows 11 with nested virtualization turned on. Docker Desktop on macOS, on Linux and on Windows 10 doesn't expose KVM, so it won't run there.
• Budget at least 2 GB of free RAM and 32 GB of free disk, and more for a modern Windows that you'll actually use.
• Port 8006 is a full remote desktop. Don't expose it to the internet without something in front of it.
• The project is MIT-licensed and contains only open-source code. It doesn't distribute Windows itself. You're still responsible for having a valid Windows license and following Microsoft's terms.

Why it's worth a look

Needing Windows for one app, testing something on an old release, or keeping a throwaway Windows box in the homelab used to mean setting up a VM by hand. Here it's a config file and one command. With over 50,000 stars on GitHub, plenty of people agree.

The links are in the downloads directory and the resource index. Start with the project README, which covers the FAQ in depth.

End of transmission.

Ideas for the theme itself

Ground rule first: the site is fast because it's plain HTML and CSS. Anything below that needs JavaScript should be an extra layer, so the page still works, and still looks right, with scripts turned off.

Phosphor switcher

Real terminals came in green, amber and white phosphor. Because every color is a CSS variable, a [GREEN] [AMBER] [WHITE] toggle in the footer is a few lines: swap a class on <html> and remember the choice in localStorage.

html.amber {
  --fg: #ffb000;
  --fg-dim: #805800;
  --fg-bright: #ffe0a0;
}

A real command line

The prompts are decoration today. A small script could make one of them live: type ls to list posts, cat sniffnet to open one, help for commands. The normal nav links stay as the dependable route, and the prompt is the fun one.

Boot sequence

A one-time startup screen on the first visit, with a memory check, a modem handshake and CONNECT 2400, before the page draws in. It needs a skip key and must respect prefers-reduced-motion, and after the first visit it shouldn't play again.

Keyboard navigation

Number keys for menu items, j/k to move through the post list, q to go back. It suits the aesthetic and makes the site genuinely quicker to use for people who live in a terminal.

Smaller touches

• A faint screen flicker or phosphor glow, offered as an option rather than forced on everyone.
• Self-hosting the IBM Plex Mono font, so the site makes no third-party requests at all.
• ANSI-colored art for post headers, rendered with spans rather than images.
• A printable stylesheet that turns any post into a clean, plain printout.

What to use the site for

The look sets expectations: technical, personal, a little nostalgic, built by hand. Content that fits that tends to feel at home here.

A homelab and project log

Write-ups of builds, server setups and things that broke, posted as dated transmissions. The ls -lt post list already reads like a changelog, which is exactly what a project log is.

Tool spotlights

Short posts like the Sniffnet one: what a tool does, why it's worth trying, and a link in the downloads directory. Over time that adds up to a curated software shelf.

A microblog

Not everything deserves a full post. A /notes feed of one-to-three-line dated entries ("rebuilt the NAS, 40 minutes, no data lost") would keep the site alive between longer pieces. Add an RSS feed alongside it so people can follow without checking in.

Guides and tutorials

The theme tutorial showed the format works: step-by-step, copyable code, nothing hidden. Networking, Linux, self-hosting and security basics all read naturally in monospace.

A link directory and webring

The resource index could grow into a hand-picked directory of the small web: personal sites, useful tools, good reading. Joining or starting a webring of similar retro and personal sites fits the BBS spirit of linking to your neighbors.

A status board

The System Status section on the home page could report real things: uptime of self-hosted services, the latest post date, the last deploy. A static site can still show it if a small scheduled job rewrites the numbers.

Community

The info@ mailbox is open now. A guestbook page, or later a forum, would close the loop and turn a site you read into a place you visit.

What to keep

Whatever gets built, a few things stay non-negotiable: pages load instantly, everything works without JavaScript, text stays readable (contrast before atmosphere), and the effects never get in the way of the words.

Got an idea or a request? Send it to info@spiralnet.io.

End of transmission.

1. One font, a few colors

The look comes from restraint: a single monospace face and a short palette defined once as CSS variables. Everything else references the variables, so re-theming means changing a handful of lines.

:root {
  --bg: #000000;
  --fg: #33ff66;        /* body text */
  --fg-dim: #1a8033;    /* borders, metadata, prompts */
  --fg-bright: #aaffaa; /* headings, links */
  --accent: #ff6633;    /* hover and focus only */
  --warn: #ffcc33;      /* tags */
  --mono: 'IBM Plex Mono', 'Courier New', monospace;
}

html, body {
  margin: 0;
  background: var(--bg);
  color: var(--fg);
  font-family: var(--mono);
  font-size: 15px;
  line-height: 1.5;
}

Load the font in your <head>:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=IBM+Plex+Mono:wght@400;600&display=swap" rel="stylesheet">

Want amber instead of green? Try --fg: #ffb000, --fg-dim: #805800, --fg-bright: #ffe0a0. Keep the accent a contrasting hue so hover states stand out.

2. Scanlines and vignette

The CRT feel is two fixed overlays drawn with gradients on body's pseudo-elements. A repeating linear gradient makes faint horizontal lines; a radial gradient darkens the corners like a curved tube.

body::before { /* scanlines */
  content: '';
  position: fixed;
  inset: 0;
  pointer-events: none;
  background: repeating-linear-gradient(
    0deg,
    rgba(0,0,0,0) 0px,
    rgba(0,0,0,0) 3px,
    rgba(0,0,0,0.08) 4px,
    rgba(0,0,0,0) 5px
  );
  z-index: 100;
}

body::after { /* vignette */
  content: '';
  position: fixed;
  inset: 0;
  pointer-events: none;
  background: radial-gradient(ellipse at center, transparent 50%, rgba(0,0,0,0.4) 100%);
  z-index: 99;
}

Don't skip pointer-events: none. Without it the overlays sit on top of the page and swallow every click.

3. Shell prompts and a blinking cursor

Prompts are added with ::before, so the HTML stays clean and screen readers aren't fed decoration. The cursor is a block that blinks with a two-step animation, which gives a hard on/off rather than a fade.

.prompt::before {
  content: 'you@host:~$ ';
  color: var(--fg-dim);
}

.cursor {
  display: inline-block;
  width: 0.6em;
  background: var(--fg);
  color: var(--fg);
  animation: blink 1.1s steps(2) infinite;
}
@keyframes blink { 50% { opacity: 0; } }

<p class="prompt">uptime</p>
<p>> system online <span class="cursor" aria-hidden="true">_</span></p>

4. Bracketed nav and comment-style headings

The same pseudo-element trick dresses up navigation and section titles without extra markup:

nav a::before { content: '['; color: var(--fg-dim); }
nav a::after  { content: ']'; color: var(--fg-dim); }

.section-title {
  color: var(--fg-bright);
  text-transform: uppercase;
  letter-spacing: 2px;
}
.section-title::before { content: '// '; color: var(--fg-dim); }

a {
  color: var(--fg-bright);
  text-decoration: none;
  border-bottom: 1px dashed var(--fg-dim);
}
a:hover { color: var(--accent); border-bottom-color: var(--accent); }

Dotted and dashed borders (1px dotted var(--fg-dim)) between list rows finish the printout look.

5. The rotating sigil

The faint spinning shape behind the page is one div with stacked gradients: three thin rings from radial gradients and six spokes from a conic gradient, turning once every four minutes.

.sigil {
  position: fixed;
  right: -160px;
  top: 50%;
  width: 520px;
  height: 520px;
  transform: translateY(-50%);
  pointer-events: none;
  opacity: 0.06;
  z-index: 0;
  border-radius: 50%;
  background:
    radial-gradient(circle, transparent 38%, var(--fg) 39%, var(--fg) 40%, transparent 41%),
    radial-gradient(circle, transparent 28%, var(--fg) 29%, var(--fg) 30%, transparent 31%),
    radial-gradient(circle, transparent 18%, var(--fg) 19%, var(--fg) 20%, transparent 21%),
    conic-gradient(var(--fg) 0deg, transparent 2deg 60deg,
                   var(--fg) 62deg, transparent 64deg 120deg,
                   var(--fg) 122deg, transparent 124deg 180deg,
                   var(--fg) 182deg, transparent 184deg 240deg,
                   var(--fg) 242deg, transparent 244deg 300deg,
                   var(--fg) 302deg, transparent 304deg);
  animation: rotate 240s linear infinite;
}
@keyframes rotate { to { transform: translateY(-50%) rotate(360deg); } }

Put <div class="sigil" aria-hidden="true"></div> just inside <body>, and give your content wrapper position: relative; z-index: 1 so it sits above the sigil and below the scanlines.

6. ASCII art headers

The banner on the home page is generated text, not an image. Install figlet (or pip install pyfiglet) and render your name in the smslant font:

figlet -f smslant YOURNAME

Paste the output into a <pre> and escape any <, > or &. On small screens, shrink it rather than letting it wrap:

header.hero pre { font-size: 12px; line-height: 1.1; white-space: pre; overflow-x: auto; }

@media (max-width: 640px) {
  header.hero pre { font-size: 9px; }
  .sigil { display: none; }
}

7. Keep it usable

• Give keyboard users a visible focus ring: :focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; }
• Mark decoration (sigil, cursors) aria-hidden="true".
• Check contrast on your dim color. Dark green on black is the first thing to become unreadable. Use it for borders and metadata, never for body text.
• If motion bothers you or your readers, wrap the blink and rotate animations in @media (prefers-reduced-motion: no-preference).

That's the whole trick. The full stylesheet, including post and download-table styles, is crt.css. Take it, change the colors, make it yours.

End of transmission.

What it does

• Live charts and statistics for your traffic.
• Domain name, ASN and geographic location of the hosts you're talking to.
• Which programs on your machine are using bandwidth.
• Recognition of 6000+ upper-layer services and protocols.
• Filters, custom notifications and imported IP blacklists.
• Import and export of captures as PCAP files.

Why it's worth a look

Most packet analyzers assume you already know what you're looking at. Sniffnet is built to be approachable instead, and it's translated into 26 languages. It's written in Rust, it's free and open source (MIT or Apache-2.0), and it runs on Windows, macOS and Linux.

Installers are in the downloads directory. The Sniffnet wiki covers setup and the more advanced features.

End of transmission.

What this is

A small, static corner of the web: plain HTML and one stylesheet, no build step and no JavaScript.

What's next

• Transmissions land in the log.
• Useful links collect in the resource index.
• Files go in the downloads directory.

End of transmission.