From download to your first answer.

This is the whole path, in plain language, for someone who has never seen Semurg before. You download it, check it is the real file, and run one command. It comes up serving on your own machine. Then you bring in some data, see it, ask it a question, and time it on your own CPU. It takes about five minutes, and there is nothing to configure. The node reads your hardware and tunes itself.

A single node is free, with no time limit and no sign-up. It runs entirely on your box.

First time on a machine? → What you need

What you need.

One machine running Ubuntu 24.04 (the 64-bit x86 build), with at least 4 CPU cores, 8 GB of RAM, and 20 GB of free disk. That is a small cloud server or any recent desktop. You run the commands as an administrator with sudo. Nothing leaves the machine at any point.

A normal Ubuntu server already has the two tools you need, curl and sudo. If a bare image is missing them, install them first:

Ready? → Step 1, download and check the file

Download it, and check it is the real file.

Two lines. The first pulls the installer down. The second checks it against a published fingerprint, so you know it arrived whole and untampered before you run anything.

These are Linux/bash commands. On Windows run them inside WSL2 (the Ubuntu app), not PowerShell. On ARM / Apple Silicon they will not work — use a cloud x86_64 Linux VM.

You should see: semurg-r11-installer.tar.gz: OK

If it does not say OK, stop. Do not run the installer. Delete the file and download it again. Never run a downloaded script with sudo until the checksum says OK.

Got OK? → Step 2, install it

Run one command. It tunes itself.

Unpack the tarball and run the installer. There is nothing to configure. It reads your CPU and disks, maps its work to your cores, stripes across the disks it finds, picks the engine build that matches your processor, installs a background service, and starts serving. On a fresh box it is up in under a minute.

You should see, at the end: a SUCCESS line and the address it is serving on, http://localhost:4000.

You do not need a compiler, a language toolchain, or a separate database. The download brings its own runtime. If the installer stops, it prints one plain reason (for example, too few cores or not enough disk) rather than a wall of errors. Each of those is covered on the Troubleshooting page.

Confirm it is alive:

{"ok":true}

The part that matters: "ok":true. That means the node is up, serving, and reading straight from disk. The rest of that line is internal telemetry you can ignore.

Alive? → Bring some data in

Your node has a control plane, and it has memory.

Two things a first-time user usually does not find on their own, so they are said here rather than left to be discovered:

1. There is an admin console. Your node runs a private, loopback-only operator console — live cluster graph, node monitor, mechanism liveness, settings. It is fail-closed and never exposed on the public network. Your node printed the console URL and a one-time credential on first start, under CLUSTER ADMIN CONSOLE (first-run bootstrap). See how to reach it.

2. The memory API is on. Agent memory is a first-class capability here, so /v1/memory works out of the box — remember, recall, relate, forget, durable under your data directory. Recall is entity-seeded (you name a thing, it walks the graph from there) and extraction runs in the background — the docs state both limits plainly. Check it is live:

You should see: {"enabled":true,…}. Turn it off with SEMURG_MEMORY=0 if you do not want it.

Put data into the store.

Nothing to load: your node already has a real graph in it

A fresh install comes up holding a real public graph, so you can ask it a question immediately. Start here — it is the fastest proof that your node works:

You should see: {"ok":true,"op":"traverse","result":{"nodes_visited":…}} — a real 3-hop walk over a real graph, on your hardware, in one command.

Now write your own: three records in and back out

Paste this one block. It writes three records into your node. It looks technical because it packs the raw 64-byte records for you — you only have to paste it.

You should see: {"ok":true,"containers":3, ...}

Read them back:

You should see: {"ok":true,"containers":3, ...}. The three records come straight back off the disk. That is the whole write and read path, proven on your node.

A real dataset: a graph bigger than memory

Your fresh node starts empty, ready for your own data; the large public graphs are not bundled in the download. When you want something large and real to see and traverse, load a public graph yourself. To go past what RAM can hold, point Semurg at a Wikidata dump (roughly 100 million entities and over a billion statements, genuinely larger than memory) or an OpenStreetMap extract, or a redacted slice of your own data, and watch the out-of-core traversal survive where an in-memory engine would stop.

There is no one-line sync switch for this today. The reproducible loading kit lives on data.semurg.io and the universal ingestor, and it walks the load step by step.

Budget the disk before you start a large graph. A full Wikidata graph is hundreds of gigabytes raw and more once ingested. Smaller public SNAP graphs and your own slices are covered in the docs.

Data in? → See it

Open the console and watch it live.

Point a browser at the address the installer printed:

That is the operator console. It has a living graph that draws your data as it lands, a health cockpit that shows the node armed and serving, a prove it panel that runs the benchmarks in front of you, and Simargl, a place to explore. The graph fills in as data arrives, so if you loaded a large graph, you will watch it grow.

Seen it? → Ask it a question

Query the store.

In the console, the graph is clickable: pick a node and follow its links to answer a question by walking the data. From the command line, the same store answers a handful of query shapes:

Every one of these reads the one copy of your data on disk. There is no export step and no second system to move data into first. Full detail is on the docs Query section.

Got an answer? → Prove the speed

Time it on your own hardware.

You do not have to take a number off a slide. The benchmark harness ships inside the release and runs against your node. Start with the compute kernel, which needs no dataset:

{"result":{"saops_human":"<your figure>", ...},"provenance":{"native_engaged":true, ...}}

The part that matters: "native_engaged":true, and your own figure in saops_human. The placeholder above stands in for the live figure. Yours fills in when you run it, measured on your own CPU, which is the whole point.

If you loaded a graph, time a deep traversal over it. The identical call runs on the public box and on yours, so you can put the two numbers side by side:

The full set of live figures, with methodology, is on the Benchmarks page.

Timed it? → Keep going

Explore, and go further.

You have installed it, brought data in, seen it, asked it, and timed it. From here:

• Models and data streams the world into your node as a peer: Gemma 4 E4B, the 2.8-trillion-parameter Kimi K3 on CPU, and large public graphs such as Wikidata or OpenStreetMap, loaded once and pulled straight in.
• One store, ten reads shows the same data answered as a graph, a table, a search, and more, all from one copy.
• Docs covers operating the node, durability, backups, and every query shape in full.
• Paradigms explains how each way of reading maps onto the one store.
• Verify lets the node attest to itself, for the security-minded.