Questions, answered

Holm is a self-hosted platform for websites and apps. One Go binary serves static files, answers requests with server-side JavaScript, signs people in, stores documents, files and keys, and pushes realtime updates. One SQLite database holds the node's state.

Build with Holm App Spec v1 and deploy a folder with --spec-v1.

A holm is a small island. Holm is meant to be a small digital island for almost everything you need online: a place to build and publish almost any digital experience or product, on a substrate you control completely.

Three out of four. Holm hosts and runs apps like a PaaS, keeps everything in SQLite, and serves HTTP and HTTPS itself.

It is not a framework. A v1 app has public files in web/, optional holm.json and an optional api/main.js when it needs server code. A plain static site can also deploy a folder with no web/ or api/.

That the whole stack is yours to hold. The binary runs on hardware you choose, the database is a file you can copy, and nothing needs an account with us: no license key, no license server, no expiry date.

Your data stays on your node unless you connect it to something outside, such as an AI or email provider. Then it goes where you sent it.

Holm suits individuals and small teams: personal infrastructure, internal tools, small products and websites.

Look elsewhere if you need automatic multi-region failover, a horizontally scaled cluster, or more durable writes than one SQLite writer can take. Holm is one node on purpose, and we would rather tell you here than in your incident report.

One node can host many apps, and each app has its own scope for storage, secrets and policies. Exact host routes decide which hostname reaches which app, so notes.example.com and shop.example.com can sit side by side without sharing their app storage.

The license doesn't count instances, apps or users either.

More or less. The database is the node: apps, routes, members, policies and stored data all live in one SQLite file. Stop the node, check that holm db objects status reports canonical_complete: true, copy the file, and start a compatible Holm binary anywhere else with --db pointing at it.

Treat the stick like the server it now is. It holds your users and your encrypted secrets, so move it through a channel you trust.

It keeps running. Holm has no license server, license key or expiry date, and a build's license governs that build permanently, so nothing switches off and you never have to upgrade.

What you would lose is new releases. Keep a copy of the exact binary you run: nobody promises to keep old builds downloadable forever.

The shell installer supports Linux on amd64 and arm64, and macOS on Intel and Apple Silicon. A Raspberry Pi running a 64-bit Linux OS is an arm64 machine.

Capacity depends on the app. Benchmark it on the hardware you plan to use, and mind the ventilation.

The trade-off is explicit: one SQLite instance has one durable writer. Static and read-heavy apps are a natural fit; write-heavy workloads need measurement rather than a promise about throughput.

Keep queries bounded, back off on overload and benchmark your actual app. There is no separate database server to run.

It was built expecting one to. Holm is managed entirely from the command line, commands offer --format json or --json for machine-readable output, and the node describes itself: holm api routes --format json, holm settings schema --json, holm policy schema --json.

Point your agent at llms-full.txt, the complete reference in plain text. Then give it a scoped API key rather than your owner token. An agent deserves exactly the authority its task needs.

This website has a dark mode: it's behind the round button at the top right.

Holm itself is run from the command line, and nothing in it needs a graphical interface, which is also why it works so well over SSH and in scripts. For the numbers, holm system stats --format json prints them. Pipe the output into whatever draws your favorite graphs.

Not for licensing, ever. There is no license server, license key or usage reporting, and your license acknowledgement stays in your own database.

Apps can make policy-controlled HTTP, email and AI calls to configured services. Upgrade commands use the release channel. Do not treat a node connected to outside services as network-free.

Visit analytics for your apps are recorded by your node, in your database.

Yes. holmhq.com is a Holm app on a Holm node. This page is plain HTML generated from one Markdown file, and the search box is a small script that runs in your browser. No framework, no search server.

A folder containing just index.html works in plain mode; holm.json is optional. Validate it locally, then deploy to an explicit peer and host:

holm app validate ./my-site --spec-v1
holm @local app deploy ./my-site --spec-v1 --host hello.holm.localhost

When it needs a server, put public files in web/ and add api/main.js:

export default {
  fetch(request, env) {
    if (new URL(request.url).pathname === "/api/hello") {
      return Response.json({ hello: "world" });
    }
    return env.holm.web.fetch(request);
  },
};

The ten-minute local start walks through instance setup and a complete v1 app.

No, but you may. Holm follows BFBB, "build free, but buildable": an app should run as plain browser files with no build step, and a tool like Vite can still add convenience and optimization on top.

If you build, put the public output in web/ and bundle server dependencies into api/main.js, then deploy that folder with --spec-v1. The node runs no build.

No. V1 server code uses the standard Web Request and Response objects with export default { fetch(request, env) }. Modern JavaScript includes ES modules, top-level await, private class fields and async generators. Each request gets a fresh engine; keep durable state in env.holm storage.

Package imports do not resolve on the node. Bundle dependencies locally into api/main.js, and use only the globals and APIs listed in the runtime guide.

V1 apps can use:

• Sign-in: node-provided login/logout pages and read-only identity/roles.
• Storage: a JSON document store, key-value with TTLs and counters, and blob storage, shared by the app or private to the signed-in member.
• Realtime: browser WebSockets and fetch-handler broadcasts; private and presence channels require sign-in and app policy.
• The outside world: policy-controlled outbound HTTP, email sending and AI calls through configured providers.

No separate Node.js runtime or auth service is required.

No model inference is provided by the v1 app runtime. env.holm.ai.chat calls a configured provider, synchronously, subject to app/member limits and the budget guard. Your prompts go to that provider.

Configure credentials outside the app's files. Keep calls within the request budget; without a provider, the call throws ai.not_configured.

Native agents, background workers, jobs, schedules and durable queues/events are not available in v1 yet.

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

It runs on Linux and macOS and asks how you want Holm: as a production server with a system service, your domain and HTTPS; as a local development service on your own machine; or as just the CLI. It downloads a release pinned to a checksum, shows you the license, and asks before it changes anything.

You can read install.sh first. You should. It currently pins v0.227.0; initialize and accept the selected instance, then upgrade before using the v1 examples. The reference describes 0.243.2.

Point admin.example.com and *.example.com at the node, then install the service with --https. Holm gets and renews certificates over ACME by itself.

Each app still needs an exact host route, so wildcard DNS never turns a random subdomain into a live app. Unknown hosts get a small 404.

It depends on the app's read/write load, file sizes and external calls. Static and read-heavy traffic is an easier fit than frequent durable writes. Benchmark the actual app rather than treating one server size as a guarantee.

holm system stats --format json shows the node's resource use.

Use holm upgrade --check for preflight and holm upgrade to install from the official release channel. For a peer, use holm @prod upgrade with an owner/admin member credential; a scoped API key cannot replace its binary.

Holm is pre-1.0, so releases can still break things. Read the changelog, review changed licence terms, and make a verified complete backup first. Do not assume a downgrade will accept newer data.

Check that the selected database is complete, then stop the node and create a verified backup artifact. This example stops a service; stop a manual foreground server with Ctrl-C.

holm db objects status --db ./data.db --json
holm stop --force
holm db artifact create --source ./data.db --out ./backup-artifacts
holm db artifact verify ./backup-artifacts/<artifact-id>

A one-file backup needs canonical_complete: true. Materialize detached Object bytes into a fresh standalone database first if needed. To test a backup, use holm db artifact restore-verify --out ./restored-db --proof ./restore-proof.json ./backup-artifacts/<artifact-id>; it restores into an alternate directory and opens the copy read-only, without activating it.

No. There is no automatic clustering, replication or failover, and a node lives in one place. You can run as many separate nodes as you like and drive them all from one CLI as peers, but each is its own instance.

If you need multi-region high availability today, Holm is the wrong tool.

Yes. Register the server as a peer once, then prefix commands with its name:

holm peer add prod --url https://admin.example.com --token '<token>'
holm @prod status
holm @prod app deploy ./site --spec-v1 --host site.example.com
holm @prod logs

Use an explicit @peer for anything that changes state, so a command never lands on the wrong machine.

The default local database is ~/.holm/data.db. A managed service selects its own database; inspect the actual service configuration instead of assuming it uses the operator's home directory.

Object bytes can be detached to a sibling objects/ directory or a configured provider. Check holm db objects status --json before treating one file as a complete node. A mirror alone does not change authority or replace a backup.

Holm's secret stores encrypt credentials. Do not treat that as whole-database encryption, and use disk encryption if the machine could walk off. Enable HTTPS for the public network path.

Someone who owns the whole host owns the node, encrypted secrets included.

V1 storage is scoped to the app, member storage requires sign-in, and outbound HTTP goes through node policy. Admin and node APIs retain caller and app-grant checks; fresh v1 apps cannot request new capabilities yet.

Do not treat an app as a container or separate Linux process. Deploy code you trust, validate request data, and keep credentials out of public files.

Email security@holmhq.com privately, rather than opening a public issue.

Your own nodes can publish a disclosure policy too: holm security-txt set serves one at /.well-known/security.txt.

Every Holm release before 1.0 is free for everyone, for personal, internal and commercial use, with no payment, revenue threshold, signup or license key.

The catch is the fine print, which every license has. Holm is not open source, you may not modify or rebrand the binary, and offering Holm itself as a managed service is reserved. It is all in the license.

For future builds, see what happens when 1.0 arrives.

The terms for a future 1.0 build will be the licence that build identifies. The proposed model: organisations with more than $1M in annual revenue would need a commercial license, and everyone else stays free. It is a proposal, not a promise, until a 1.0 licence is published.

Nothing changes for the builds you already have. Every build before 1.0 stays free for everyone, as section 8 of the license promises: later terms never reach back to an earlier build, and you are never required to upgrade.

No. You get the official signed binary under the Holm Usage License Agreement, which grants no source-code rights and makes no promise that Holm will become open source.

You may redistribute exact, unmodified official binaries, inside a container image for instance, as long as the notices stay intact and you don't charge for Holm itself.

Yes. Apps you build are yours: the license claims no rights in them, their code or their data, and people who use them need no Holm license.

You can also install, host and run Holm for clients and charge for that work. Each client is the licensee of its own instance, and you must tell them Holm is licensed separately.

Not as a product. A managed Holm service, offered to the public or to customers generally, under the Holm name or any other, is reserved to the licensor.

Selling your apps is fine, and so is running Holm instances for clients as professional services. Selling Holm itself as a hosted platform is not.

Bet carefully. Holm is pre-1.0 and beta; releases can still break things. The licence warns that pre-1.0 software may fail or lose data.

This website runs on it. Still: pin your version, test upgrades, and keep backups you have restored at least once.