Holm blog

Every Holm app now speaks MCP

2026-10-22T00:00:00Z

Since v0.255.0, apps on a Holm node can be used from inside ChatGPT and Claude. Holm speaks the Model Context Protocol (MCP), the open standard both use for plugins and connectors, and builds the tools from what your app already does. Nothing extra to write or set up.

If you run Holm through Claude or another agent, it looks like this. You ask for an app, say a feedback form or a waitlist. The agent builds it and deploys it to your node. That app now also has an address ChatGPT or Claude can connect to, and anyone who adds it can use the app in plain words: "what's on the waitlist?", "send this feedback".

Why it matters: OpenAI reported 800 million weekly ChatGPT users in October 2025, and both ChatGPT and Claude let people add tools to their chats. Nobody knows yet how much a small plugin gets used, and you can't sell digital goods inside ChatGPT, so think of it as a new front door to your app rather than a store. With Holm, that door comes with every app.

What an assistant can do

Only what your app already offers the public. Anything that needs a signed-in user stays out, and every request from an assistant goes through the same checks as one from a browser. Holm tells the assistant which actions only look things up and which change something. Actions that change things can be made safe to retry: if a connection drops and the assistant sends the same request again, Holm returns the first result instead of doing it twice.

Our own feedback app works this way. In a chat it can look up a widget's public settings and send feedback; the owner's inbox stays private.

Apps built before v0.255.0 have this switched off. Ask your agent to switch it on, or to keep any app out of AI chats.

What's tested, and what's next

Before building this in, we connected a hand-written version of the feedback app to Claude. Claude picked the right actions from plain questions, read and wrote data, and showed an interactive card. The built-in version passes our tests for the current versions of the protocol, but we haven't yet run it through real ChatGPT and Claude conversations end to end. That's next.

Still to come:

Sign-in, so an assistant can reach a person's own data in your app, with their consent. It is designed and under review.
Cards in the chat, which the prototype showed and the built-in version doesn't yet.
Help getting listed in the ChatGPT and Claude directories.

Try it

Ask your agent for your app's MCP address, then add it as a custom connector: in Claude, or in ChatGPT's developer mode (paid plans). The guide has the details. If something behaves oddly, the Feedback link at the bottom of this page reaches us.

Holm on Windows: a small compile gap, an untested runtime

2026-10-16T00:00:00Z

Holm ships for Linux and macOS, on amd64 and arm64. There has never been a Windows build, and the installer stops with "Unsupported OS" anywhere else. This post covers why, what we found when we tried to build Holm for Windows, and what has to happen before we call it supported.

Nothing described here has shipped. Windows support is planned work.

Why there was no Windows build

Holm started as a way to deploy static sites to your own VPS with no extra dependencies. The design target is still a small server: a cheap VPS with one virtual CPU and 1 GB of memory. A production node is a Linux machine where Holm installs itself as a systemd service, gets HTTPS certificates for your domains and upgrades itself in place.

Release builds have targeted Linux and macOS since the first release pipeline, and that list has not changed. Linux is where Holm runs in production. macOS lets you run the same binary on your own machine. Even there Holm trails Linux: it has no native service setup on macOS yet. Linux has always come first.

Windows also raised a product question we had not answered. Should Holm on Windows be a command-line tool that manages Holm servers elsewhere, or a complete local server? Those lead to different work. A server needs integration with the Windows service manager, a safe upgrade path and a clean way to stop and start. We chose to wait for that answer before building either, and to make no claim about Windows in the meantime. The public reference says it plainly: Windows is not an official target.

The last reason is evidence. A cross-compile proves that code builds. It tells you nothing about how the program behaves on that system. We want platform claims backed by tests that ran on the platform, and our continuous integration has only ever run on Linux. Without a Windows machine in the loop, a Windows build would have been a guess.

That open question has since narrowed. Whatever role Windows ends up with, the first step is the same: the Holm core has to build and run there. So we started with the build.

What a Windows compile turns up

A C toolchain is usually the hardest part of porting a program to Windows. Holm needs none. The binary is built without cgo, and its SQLite driver is written in pure Go. Go can cross-compile a program like that for Windows from a Linux machine with no extra tools.

When we cross-compiled the server for 64-bit Windows, the build failed in exactly four places. All four are Unix-only code:

Free disk space, checked in three places. Holm refuses app storage writes when the disk is nearly full, checks for room before it snapshots the database ahead of a migration, and reports free space in its database stats. All three ask the operating system through the Unix statfs call.
The single-instance lock. At startup Holm takes an exclusive lock on a file beside the database, so a second server can't open the same database. That lock uses the Unix flock call.
The hardened network listener. On Linux, Holm asks the kernel to hold a new connection until the client sends data (TCP_DEFER_ACCEPT). That blunts slow-connection attacks at the kernel level. It also turns on TCP Fast Open. The library that sets these options is Linux-only and doesn't compile for Windows. Holm already falls back to a plain listener on other systems at runtime, so only the build breaks.

We replaced those four with stand-ins in a throwaway copy, and the whole server compiled into a 64-bit Windows executable of about 65 MB. The compile gap is small.

The real fixes are small too. Windows has direct equivalents for free-space queries and file locks. The listener code will split by build target, so the Linux hardening stays on Linux and every other system gets the plain listener at compile time, as it already does at runtime. We expect the whole change to come to roughly 150 to 250 lines.

What we don't know yet

None of this has run on Windows. A program that compiles for a platform can still misbehave there, and server software touches the operating system in many places. These are the areas we expect to need work:

Self-upgrade. holm upgrade replaces the running binary with a new release. Linux allows that. Windows won't let a running .exe be replaced in place, so upgrades need a different approach there.
Running as a service. Holm installs a systemd service on Linux. Windows has its own service manager, and Holm has no code for it yet.
Shutdown. On Unix, the service manager stops Holm with a signal and Holm shuts down cleanly. Windows delivers stop requests through other channels.
File permissions and paths. Holm sets Unix file modes on its data and assumes Unix-style paths in places. Windows handles both differently.
The installer. The installer is a shell script for Linux and macOS. Windows will need its own way to install.

Each of these could be a small fix or could need real design work. We will know once the server runs on an actual Windows machine.

The plan

The work comes in four steps:

Proper Windows versions of the four spots. Native free-space and lock calls, and a listener split by build target.
A Windows cross-compile check in CI. Every change gets built for Windows, so new Unix-only code can't break that build silently.
The test suite on a Windows CI runner. The tests that guard the Linux build will run on Windows too.
A smoke test on a disposable Windows VM. Start the server, deploy a static app, restart it, upgrade it and run it as a service. The VM is thrown away afterwards, so each run starts from a clean machine.

The first two steps are mechanical. The last two will show which of the runtime questions above are real problems.

Where that leaves you today

The release archives and the installer still cover Linux and macOS only, and the public reference still says Windows is not an official target. That stays true until the tests above pass. A successful compile is not enough for us to call a platform supported. When a Windows build ships, the changelog will say so.

Holm is open to try

2026-10-04T00:00:00Z

Holm is a self-hosted platform for apps and agents. One Go binary provides hosting, auth, storage, realtime, workers and operations. One SQLite database carries the whole node: apps, routes, identity, policy and durable state.

That split is the idea we keep coming back to. The binary is replaceable: you upgrade it, and nothing you built moves. The database is the node: copy the file, and the instance goes with it.

Free before 1.0, and it stays that way

Every Holm release before 1.0 is free for everyone under the Holm Usage License Agreement. A build's license is part of the build and governs it permanently: later terms never apply to an earlier build, and you never have to upgrade. There is no license key, license server or expiry date.

That is not just a promise in a blog post. It is written into section 8 of the license, and it holds for as long as you follow the license.

Install it

curl -fsSL https://holmhq.com/install.sh | bash

The installer runs on Linux and macOS, on amd64 and arm64. It asks how you want to run Holm:

Production server for a VPS, with a system service, your domain and HTTPS.
Local development for your own machine, with a user service on your local IP.
CLI only if you just want the binary.

Before service setup, it shows the license and asks you to accept it. The public starting point is v0.223.0, pinned to a checksum with HULA v1. CLI-only users follow the local start guide to initialize an instance and record acceptance. Later updates use holm upgrade through a signed release channel. You can read install.sh before you run it.

What to expect

Holm is in beta and still changing quickly. The public changelog starts at v0.223.0; later releases add short entries there. Future legal-text changes get a new licence version, ID and versioned address.

To find your way around, start with the field guide. If you work with a coding agent, point it at llms-full.txt, the complete plain-text reference. When something breaks or is missing, tell us in the issue tracker.