its-a-feature/Mythic: a Docker-based red teaming framework that installs agents from GitHub

What Mythic is for, and who it is built around

Mythic is a post-exploitation framework, meaning it assumes you already have some form of access and need a place to manage it. The README describes it as "a cross-platform, post-exploit, red teaming framework built with GoLang, docker, docker-compose, and a web browser UI", and says it is designed for operators, managers and reporting throughout a red teaming engagement. That phrasing is the useful part. Most command and control servers are built for the person typing commands. Mythic adds a browser UI and a data model that a manager or a report writer can look at without touching the agent itself.

The audience follows from that. It is a team tool. If you are one person running one implant against one host, the docker-compose stack is a lot of moving parts for the result. If you are coordinating several operators against a shared target set, the split between the core server and the payload types is what makes it work: everyone sees the same callbacks, the same task history and the same file store.

It is also explicitly cross-platform. The repository ships Docker base images with Go and Python variants for Linux, macOS and .NET targets, which is the infrastructure that lets third-party agents compile payloads for different operating systems without the host machine carrying those toolchains.

The core/agent split is the actual architecture

The single most important design decision is stated plainly in the README: "The Mythic repository itself does not host any Payload Types or any C2 Profiles." What lives here is the core. Agents and C2 profiles are separate GitHub repositories, installed into a running instance on demand, and the README explains the reasoning: it lets agents and C2 profiles "be updated at a much more regular pace" and separates the core components from the rest.

That is a real architectural boundary, not just packaging. A fresh Mythic install gives you the server, the database, the message broker, the web UI and the CLI. It does not give you anything to run on a target. Until you install a payload type and a C2 profile, the framework has nothing to deliver and nowhere to deliver it.

The container layout in the repository makes the dependency graph visible. Alongside mythic-docker and mythic-react-docker there are postgres-docker, hasura-docker, rabbitmq-docker, nginx-docker, jupyter-docker, grafana-docker, prometheus-docker and postgres-exporter-docker. So the shape is: Postgres for storage, Hasura as the GraphQL layer over it, RabbitMQ as the message bus between services, nginx in front, and an optional observability side with Prometheus and Grafana. The agent communicates with the C2 profile, the C2 profile talks to the core, and the operator sees the result through the browser UI or the API behind it.

That is heavier than a single Go binary with an embedded database. It is also what makes collaborative use possible, because state lives in Postgres rather than in one operator's process.

Installing Mythic: build the CLI, start the stack, add an agent

The README keeps setup short and points at the documentation site for the rest. The control surface is a binary called mythic-cli, and it is not checked in. You generate it from the main Mythic directory with make, which by default builds the Linux target and moves the binary to the repository root.

sudo make

After that, the README gives a single command to bring up all default Mythic containers:

sudo ./mythic-cli start

The Makefile shows the other build targets if you are not on Linux: make macos, make local, make linux_docker and make macos_docker. The README does not spell out what the browser UI listens on, so take the address from the documentation site rather than guessing a port.

A running core with no payload type is not useful yet, so the next step is installing an agent. The README's example installs apfell:

sudo ./mythic-cli install github https://github.com/MythicAgents/apfell

And the same command installs a C2 profile, here the HTTP profile:

sudo ./mythic-cli install github https://github.com/MythicC2Profiles/http

The install command accepts an optional -b flag for a branch name and -f, per the usage line in the README. Payload types and C2 profiles are listed on the overview page at mythicmeta.github.io/overview, which is where you should look for anything beyond these two examples. Once both are installed, the browser UI is where you build a payload and watch callbacks arrive.

Updating is a check, not an upgrade

The README is unusually direct about this. The update command "will _NOT_ do the update for you, but let you know if an update exists":

sudo ./mythic-cli update

It checks mythic-cli, mythic_server and the mythic_react UI. To check against a specific branch, the README documents ./mythic-cli update -b [branch name].

This matters for anyone planning a production-ish deployment. You get version awareness, not version management. The actual upgrade procedure is not described in the README, and the documentation site is the only place the README points to for it. If your team needs a documented rollback path before you touch a live instance, the README does not provide one and you should treat that as an open question to resolve from the documentation first.

The release history suggests why the check exists at all. Tags include v3.4.0.5, v3.3.0.133 and v3.2.20, and the tag names carry release-candidate suffixes such as "Mythic 3.3.1-rc90" and "v3.2.20-rc11". The pre-release cadence is high. Checking before you pull is a reasonable habit here rather than a formality.

Where Mythic is the wrong choice

The Docker requirement is the first hard boundary. Everything runs in containers, and the repository ships install_docker_debian.sh, install_docker_kali.sh and install_docker_ubuntu.sh precisely because Docker is a prerequisite, not an option. If your environment forbids Docker, or you need to run the C2 server on a host where you cannot install it, Mythic is not a candidate. The README's own framing is that containers remove host requirements, which is true, but it trades host dependencies for a container runtime dependency that is harder to argue away.

The second boundary is the empty core. Someone evaluating Mythic by cloning it and running the start command will find a server with no agents. That is intentional, but it means the evaluation is not one command. You have to pick a payload type and a C2 profile from a separate site, install both, and only then can you judge whether the framework suits you. Budget for that.

The third is operational weight. Postgres, Hasura, RabbitMQ, nginx and the React UI are all part of the default stack. For a single operator on a short engagement, that is more surface area to keep alive than the task requires, and more places for a misconfiguration to hide. The collaborative features are the payoff, and if you do not need collaboration you are paying for them anyway.

Finally, the README does not document rollback or a downgrade path, and it does not restate the licence terms. Both are things you would want settled before relying on it.

How this differs from a single-binary C2 such as Sliver

The clearest contrast is with Sliver, which is distributed as a single Go binary with the server, client and implant generation in one artifact. You download it, run it, and you have an implant. There is no separate agent repository to install and no container runtime in the loop.

Mythic inverts that. The core is deliberately thin and the payload types are external, fetched from GitHub at install time through ./mythic-cli install github. The advantage is update velocity and separation of concerns: an agent author can ship a new version without waiting on a core release, and the core can change without forcing every agent to rebuild. The cost is that a Mythic instance is only as capable as the set of agents you have installed into it, and the supply chain for those agents runs through third-party repositories.

A second difference is the data layer. Sliver's state is local to the server process. Mythic puts Postgres and Hasura underneath, which is what makes the browser UI and multi-operator access coherent. If two operators task the same callback, there is one authoritative record. That is a genuine capability, and it is also why Mythic cannot be a single binary without becoming a different project.

Licence, maintenance and what the repository actually tells you

The repository metadata reports the licence as NOASSERTION, meaning the automated classifier could not map the LICENSE file to a known identifier. The README does not restate the terms. If you are deploying Mythic inside an organisation, read the LICENSE file at the repository root yourself rather than relying on the metadata badge or on this article. Nothing here is legal advice, and a NOASSERTION result is a reason to look, not a conclusion about what the terms allow.

The project is not archived, and the last push to the master branch was on 2026-09-21, which is two days before this article. That is recent enough that the codebase is clearly being worked on. The README also notes sponsorship by SpecterOps and links a BloodHound Slack for chat, which is where day-to-day questions appear to land.

On upgrade cost, the honest answer is that the README supports checking but not performing. You can learn that mythic-cli, mythic_server or the UI has a newer version, and you can check a specific branch, but the upgrade itself and any rollback are outside what the README documents. The pre-release-heavy tag history means you should expect to make a deliberate choice about which tag to sit on rather than tracking the newest one.

Editorial conclusion

Adopt Mythic if you run a team that needs a shared, browser-driven command and control server and you are comfortable with Docker, docker-compose and a Hasura/Postgres/RabbitMQ stack underneath. Do not adopt it if you want a single self-contained binary, if you cannot run Docker on the host, or if you expect the repository to give you a working agent out of the box, because it deliberately does not. Before committing, clone the repository, run sudo make and sudo ./mythic-cli start on a disposable host, then install one payload type and one C2 profile from the overview page and confirm the browser UI shows the operation you created. Check the LICENSE file directly, since the repository metadata reports NOASSERTION and the README does not restate the terms.

Frequently asked questions

Official sources

1. Issues
2. its-a-feature/Mythic on GitHub
3. README
4. Releases