Realm pairs a Rust agent with a Go server and a Starlark DSL

Two binaries and a language split

The quick start makes the shape obvious, because the two halves are started differently and live in different directories.

You clone the repository, check out the most recent tag into a branch, start the server by running its directory with the Go toolchain, and then in a second terminal start the agent from the implant directory with the Rust toolchain. There is no configuration step between them and no packaging step.

git clone https://github.com/spellshift/realm.git && cd realm
git checkout -b latest $(git tag | tail -1) # Checkout the latest stable releases
go run ./tavern
cd realm/implants/imix && cargo run

That split is confirmed by the repository itself. The module definition at the top level is a Go module, the server has its own directory, and the agent lives under implants. So the project's primary language shows as Rust because the agent is the part that ships to machines you are attacking, while the control plane is Go.

The division of labour follows from that. The agent is described as supporting long-running tasks by reading output in real time, interval callback times, simple file-based configuration, embedded files and a built-in interpreter. The server provides the web interface, group actions across agents, a GraphQL backend for API access, OAuth login support, and a cloud-native deployment path with pre-made Terraform.

A production deployment is documented separately from this local start, which is the usual sign that the two paths are genuinely different rather than the same thing with extra steps.

Eldritch compiles Starlark to Rust

The scripting layer is the part of Realm with a design opinion in it, and the opinion is that operational scripting should read like thought rather than like glue.

Eldritch is described as a Pythonic domain-specific language for offensive security work, and it is based on Google's Starlark. Starlark is a deliberately small dialect: it has no arbitrary imports, no compile-time evaluation of the host language, and a syntax designed to be analysable, which is why build systems adopted it. Those properties are also why it suits an agent that has to run the same script on thousands of machines without surprises.

The performance claim is specific rather than aspirational: Eldritch is natively compiled to Rust, and the compiled result is what gives a performant abstraction over low-level system interaction. So the DSL is not interpreted, and it is not a wrapper that calls back into a runtime.

The built-in interpreter ships with capabilities that would otherwise be boilerplate in every task, including a reflective DLL loader, port scanning, and remote execution over SSH. The README's phrasing on that last point is notable: it points at the documentation for the full list rather than enumerating it, which is what you would expect from a surface that grows with the upstream language.

Many thousands of beacons is the stated design target

The scalability claim is given a number, which is unusual and useful: Realm is designed for engagements of any size, up to many thousands of beacons.

Multi-host management is listed as a first-class feature rather than a consequence, and the server's group actions are the mechanism. Grouping is what makes a fleet operable, because an operator working across thousands of machines is not running tasks one at a time, they are addressing a subset and watching what comes back.

The feature list frames this as effortlessness, but the underlying work is in the design rather than the interface. A stateless server is what makes horizontal scaling plausible; the agent being self-contained with file-based configuration is what makes a large fleet survivable, since an agent that depends on a central configuration service is an agent that fails when that service is unavailable.

Two other choices in the list belong to the same category. Reliability is argued from testing and code review rather than from features, and the interface is described as designed to keep the learning curve minimal, which is a claim about time-to-first-task rather than about throughput.

The server is stateless, and the cloud is a supported choice

Realm officially supports Google Cloud, and it can be deployed elsewhere.

The official path is described as native integration with Google Cloud services, with the stated benefit of not having to reinvent the wheel, plus pre-made Terraform for production deployments. So the platform is not cloud-agnostic in its supported story; it has one supported environment.

The escape hatch is the server. It is described as a stateless Docker container, published under the tavern image name, that you may deploy to any environment you prefer. Stateless is the load-bearing word: a server that holds no state between requests can be replaced, scaled behind a load balancer, or restarted without losing anything but the connections it was serving.

That distinction matters more for this class of tool than for a web application. A control plane that accumulates state is a control plane you cannot move, and a control plane you cannot move is one you cannot run outside the provider that supports it.

The dependency list shows how much of the cloud shape survives that choice, which is the subject of the next section.

The dependency list is the honest product description

Reading the server's dependency list tells you more about what Realm does than the feature list does, because every entry is a capability someone chose to build.

The interface and access layer is a GraphQL server generated from a schema, a command-line framework, JSON Web Tokens, OAuth 2.0 support, and a QR code library. That combination is a server designed to be both a web application and a programmable API surface.

The transport and security layer is more distinctive: automatic certificate management, a cryptography library, QUIC support, an SSH file transfer library, a PAM module for Linux authentication, and cron scheduling. Automatic certificates and QUIC in the same server are a deliberate choice to avoid depending on a reverse proxy for either.

The cloud coupling is visible too. Libraries for three specific managed services appear as direct dependencies, along with the Google API client and gRPC. So the stateless container is genuinely deployable elsewhere, but the officially supported path leans on managed pub/sub, managed scheduling and a managed secret store.

The data layer is deliberately unhurried: an ORM, SQLite and MySQL drivers, a Prometheus client, an OpenCensus exporter and a multierror helper. Two small entries are worth noting for what they imply: a database toolkit for interacting with agent plugins from the server, and a Model Context Protocol library.

Versioning only becomes predictable at 1.0

The project's versioning promise is explicit about when it starts, and that is the first thing to check before depending on it.

Realm states that after reaching a stable 1.0 release it will follow Semantic Versioning, which is the guarantee that older deployments stay stable across upgrades. Until then, no such promise exists, and the tag history is consistent with that: two releases on the same day in March 2026, then a minor bump in April.

The current line is 0.4.0, and the last push to the main branch is dated September 18, 2026, so the project is being worked on between releases rather than abandoned.

Two other facts frame the project. It is GPL-3.0, which matters if you intend to read it and reuse any part, since that licence obliges you to publish derived work. And it is written in Rust and Go with substantial tooling around them: a dev container definition, a release script, an editor configuration, agent and contributor instruction files, a directory of tests, and a separate directory of documentation sources.

That last one is notable. The docs have their own directory in the repository rather than living in a wiki, which means the documentation is versioned with the code it describes.

Support is carried by issue templates and a Discord

The README spends more space on how to report a problem than on any single feature, which tells you something about where the project's support burden sits.

For bugs, the guidance is specific: a clear description of the problem, any relevant error messages or logs, steps to reproduce if possible, and the impacted Realm version and operating system. That last item is the one contributors most often omit and the one that determines whether a report is actionable.

Feature requests have their own template and their own prompt structure, asking for the problem you are facing, the solution you envision and how it would benefit other users. Feedback has a separate template again, explicitly accepting both praise and criticism.

The framing of that section is worth noting for what it implies about the audience. It speaks about missions and engagements rather than about development convenience, which is consistent with a tool built for operators who run under time pressure.

Community support runs through a Discord, and there is a code of conduct that the feedback guidance explicitly asks people to read before replying. Developer documentation sits alongside the user and admin guides, and the bug report path points at a template in the repository rather than an external form, so improvements to the reporting flow happen in the same review as code.

Editorial conclusion

Realm fits a red team that wants one control plane for a large fleet of agents, scripting in something readable rather than in shell glue, and the option to keep the server off the cloud provider it officially supports. It does not fit a team that needs a stable version contract today, because the project ties its semantic versioning promise to a 1.0 release it has not reached. Before you evaluate it, run the two-command local start to see the agent and server handshake on your own machine, and read the dependency list rather than the marketing copy, since it is a more accurate description of what the server actually does.

Frequently asked questions

Official sources

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