Realm: an adversary emulation framework built around a Starlark-derived DSL

The problem Realm targets: scripting that survives contact with many hosts

Most red team tooling splits into two unsatisfying halves. There is the interactive console, where every action is typed per host and nothing is reproducible, and there is the shell script, which reproduces well but has no idea what a host is. Realm's stated focus is scalability, reliability and automation, and the README frames the target audience plainly: engagements of any size, up to many thousands of beacons. That number is a design claim, not a measured result, but it explains why the project exists in the shape it does.

The concrete problem is that offensive logic has to run on MacOS, Linux and Windows hosts, has to be reusable across an engagement, and has to be controllable from one place. Realm answers with three components that map onto those needs. imix is the Rust agent that lands on the target. tavern is the Go server that operators talk to. Eldritch is the language the operator writes in, and the README describes it as a Pythonic DSL based on Google Starlark, natively compiled to Rust. So the same script text is authored once and executed through a compiled interpreter rather than being interpreted line by line on the host.

Who this is for is narrower than the feature list suggests. If your work is a single host, a single check, or a one-off manual walkthrough, the setup cost of a teamserver plus an agent build is not repaid. Realm pays off when the same procedure has to run against a fleet and be repeated next quarter.

How the pieces fit: imix, tavern, Eldritch and the GraphQL seam

The repository layout follows the component split. The implants live under implants/imix, and the README's quick start runs the agent with cargo run from that directory. The server is a Go program invoked as go run ./tavern from the repository root. The README lists the server's capabilities as a web interface, group actions, a GraphQL backend, OAuth login support, and cloud native deployment with pre-made terraform. That GraphQL backend is the seam that matters architecturally: the web UI is one client, and anything else you build is another client of the same API.

The agent side is described as supporting long running tasks by reading output from tasks in real time. That is a meaningful distinction from agents that only report at completion. It means the operator sees partial output while a task is still executing, which changes how you work with slow operations such as a port scan or a remote execution over SSH. The README also lists interval callback times, simple file-based configuration, embedded files, and a built-in interpreter as imix features.

Eldritch is where the offensive logic actually lives. The README names a reflective DLL loader, port scanning and remote execution over SSH as examples, and points to the documentation for the full set. The DSL is compiled to Rust, so the abstraction is not free in the sense of being slow; the cost is that the available function surface is whatever the interpreter exposes, not whatever the host can do.

One design choice deserves scrutiny. The README describes tavern as a stateless server architecture, with GCP officially supported but the stateless Docker container deployable to any environment. Statelessness is what makes the container portable, and it also means the server itself is not where engagement state accumulates. Where that state lives is not specified in the material available here, and that is the first thing to confirm in the admin guide before trusting a deployment.

Getting a local instance up: the exact commands in the README

The README's quick start is short and worth quoting in structure rather than prose. Clone the repository, then check out the latest tag rather than the default branch:

git clone https://github.com/spellshift/realm.git && cd realm git checkout -b latest $(git tag | tail -1)

Then start the server with go run ./tavern, and in a second terminal start the agent:

cd realm/implants/imix && cargo run

Two things about this sequence are easy to miss. The tag checkout is deliberate, and the README labels it as the latest stable release, which implies main is not where you want to be. The agent is built from source with cargo rather than downloaded, so a Rust toolchain is a prerequisite even for a local smoke test. The README explicitly separates this from production: it says that to deploy a production-ready instance you should see the setup guide at docs.realm.pub/admin-guide/tavern. The quick start produces something you can poke at, not something you should point at a real target.

Configuration keys are not enumerated in the README beyond the phrase simple file-based configuration for the agent. The material here does not give the file name, the schema, or the server-side configuration surface. Anyone evaluating Realm should open the admin guide before planning a deployment, because the gap between go run ./tavern and a hardened teamserver is where the actual work sits. The README does note pre-made terraform for production deployments and a Docker image published as spellshift/tavern, so there are two supported paths once you leave the quick start.

Where Realm is the wrong tool, and what the documentation does not settle

The most concrete limitation is stated by the project itself. The README says that after reaching a stable 1.0.0 release, Realm will follow Semantic Versioning, ensuring the stability of older deployments. The implication is direct: before 1.0.0, that guarantee does not apply. The recent release history shows v0.4.0 followed by 0.3.4 and v0.3.3, with the tag naming inconsistent between a v prefix and no prefix. If you are building internal tooling against the GraphQL backend or writing Eldritch scripts you expect to reuse, you are building on an interface the project has not yet promised to keep stable.

The second limitation is the function surface. Eldritch is an abstraction over low-level system interaction, and abstractions have edges. If your engagement needs a system call the interpreter does not expose, the DSL does not help you; you are back to shipping something else alongside the agent. The README lists a reflective DLL loader, port scanning and SSH execution as examples and defers the rest to the documentation, which is the honest way to present it, but it means the evaluation question is coverage, not capability in the abstract.

The third is the reliability claim itself. The README says Realm always prioritizes quality over quantity and cites extensive testing and rigorous code review. Those are assertions about process, not results, and the material here contains no benchmarks, no test counts and no failure data. Treat the reliability language as a statement of intent and validate it against your own environment. The README also does not describe what happens when the server restarts mid-engagement, which is the question a stateless architecture raises most loudly.

The real alternative: Metasploit and Cobalt Strike occupy different points on the same axis

The honest comparison is not against another modern C2 but against the two things operators actually reach for. Metasploit is the closest in licensing posture: it is also open source, and its module system is Ruby rather than a compiled DSL. The difference in approach is where the logic executes. A Metasploit module runs in the framework process and drives a payload; Realm's Eldritch runs through a compiled interpreter on the agent, and the agent is the same binary across MacOS, Linux and Windows. That shifts the extension model from writing framework plugins to writing scripts the agent can execute.

Cobalt Strike is the commercial reference point, and the difference is licensing and control rather than features. It is closed source and commercially licensed, which means no GPL obligations and no source-level audit, but also no ability to patch the agent or the teamserver yourself. Realm is GPL-3.0, which is the constraint that matters most for anyone embedding it in a product. If you distribute a modified tavern or link against its code in a way the licence treats as derivative, the copyleft terms apply. Whether your specific use counts as distribution is a legal question, not one this article can answer, and the material here does not include any licensing guidance beyond the identifier.

A third option worth naming is Sliver, which like Realm is open source and multi-platform, but the material here does not describe Sliver's internals, so the only defensible statement is that it exists as a comparable open source option. Do not treat that as a feature comparison.

Maintenance cost, upgrade risk and the version pinning question

Realm is not archived and the last push date is recent, so the project is active. The release cadence visible here shows v0.4.0 in April 2026 and 0.3.4 and v0.3.3 within a minute of each other in March 2026, which suggests the tagging process has had at least one rough patch. For an operator, the practical consequence is that any automated checkout of the latest tag should be tested rather than trusted, because the tag naming is not uniform.

The upgrade cost has two parts. The server is a Go binary or a Docker image, so upgrading tavern is a redeploy, and the README's stateless description suggests that is intended to be routine. The agent is where the friction lives, because it is built from source and because the scripts it executes are written against the Eldritch function set. An Eldritch change that alters or removes a function is an upgrade that breaks your engagement scripts, and pre-1.0 that is a live possibility rather than a theoretical one. The README's promise of Semantic Versioning applies only after 1.0.0.

The licence implication is the other ongoing cost. GPL-3.0 means that if you modify and distribute the code, the source obligations follow. For an internal red team running its own teamserver, that is usually unremarkable. For a vendor embedding an agent in a commercial product, it is a design constraint that should be settled before any engineering starts, with a lawyer rather than a README.

Who should run Realm, and what to check before you commit

Realm fits teams that run repeatable, scripted emulation across a mixed MacOS, Linux and Windows estate and want the procedure expressed in one language. The combination of a compiled DSL, a GraphQL backend and group actions is aimed at exactly that workflow, and the stateless server plus published container keeps the deployment story simple.

It does not fit teams that need a stable API today, teams whose engagements depend on system interactions the Eldritch interpreter does not expose, or anyone who cannot accept GPL-3.0 in the way they ship tooling. It also does not fit a one-off assessment, where the teamserver setup costs more than the engagement returns.

The verification list is short and specific. Read the admin guide at docs.realm.pub/admin-guide/tavern before planning anything, because the README's quick start is explicitly not the production path. Confirm where engagement state lives given the stateless server design. Check the Eldritch documentation against your required function set. And pin your checkout to a specific tag, since the tag naming has not been consistent across the releases listed here.

Editorial conclusion

Adopt Realm if you are running scripted, multi-host adversary emulation and want the agent logic expressed in a versioned DSL rather than ad hoc shell. Do not adopt it if you need a stable 1.0 API, if GPL-3.0 obligations conflict with how you ship tooling, or if your environment cannot host the tavern container or the supplied terraform. Verify first that the Eldritch function set covers the system interactions your engagement depends on, and pin to a tag rather than tracking main.

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. spellshift/realm on GitHub