Thorium: a file analysis platform that runs tools in containers at scale
A scalable file analysis and data generation platform that allows users to easily orchestrate arbitrary docker/vm/shell tools at scale.
At a glance
- What is it?
- Thorium is a Rust platform from CISA that orchestrates arbitrary Docker, virtual machine, and shell tools over uploaded files and repositories, with a GUI and CLI, a RESTful API, a multi-tenant permission system, full-text search over results, and tags for labelling data. It runs on Kubernetes, and the toolbox can import more than forty tool images and twenty pipelines.
- Who is it for?
- Thorium fits a government or enterprise malware analysis team that runs the same tool over many samples, that needs results to be searchable, tagged, and shared, and that has Kubernetes and object storage to work with. It is the wrong choice for a single analyst with a handful of samples, and the wrong choice if you cannot run a cluster, since the single node deployment is explicitly not intended for production.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem is running the same tool ten thousand times
Thorium is a scalable file analysis and data generation platform that allows users to easily orchestrate arbitrary docker, virtual machine, and shell tools at scale. The repository description names the domain implicitly through the topics, which include malware-analysis, and the project's home is cisagov.github.io/thorium.
The thing it automates is not analysis, it is the running of analysis. A malware analysis team has a dozen tools, each of which takes a file and produces a result, and the interesting part is applying them to a large collection of samples. Doing that with a shell script and a queue means writing the queue, the sandboxing, the result storage, the retries, and the user interface yourself.
Thorium takes the tool as given. The FAQ says that Thorium allows developers or analysts to easily scale up and orchestrate docker or baremetal based tools, to easily search and use results from tools, and to comment and share files, tags, and results between users and analysts. That last item matters as much as the orchestration, because an analysis result that only one person can see is a result that will be recomputed by the next person.
The feature list spells out the shape. Highly scalable analysis of arbitrary files and repositories. Near zero-cost analysis tool integration. Easy tool import capability. Static and dynamic analysis sandboxes. User friendly interfaces with a GUI plus a CLI. A RESTful API for automated access to data. A multi-tenant friendly permission system. Full-text search of analysis results. And key/value tags for labelling data.
The primary language is Rust, the licence is a custom one GitHub cannot classify with the terms in the LICENSE file, and the contact address given for the project is a sandia.gov address, which tells you the funding and the institutional home.
The toolbox is the integration surface
The question that decides whether a platform like this is usable is what happens when you want to add the tool that is not in it, and Thorium has a specific answer.
You can use the `thorctl` toolbox to import over 40 images and 20 pipelines into your Thorium instance. The named examples of images you can import are binwalk, capa, clamav, cwe-checker, email-parser, floss, foremost, ssdeep, quantumstrand, xortool, and zeek-dump.
That list is worth reading as a statement about the intended workflow. binwalk and foremost are for carving and file recovery, capa is for capability detection, clamav is an antivirus, floss pulls strings out of binaries, ssdeep does fuzzy hashing, cwe-checker and email-parser are structured analysis, and zeek-dump is network traffic analysis. These are all the tools an analyst already has, which is the point. The platform is not asking you to change your tools.
The near zero-cost integration claim is the interesting one. A tool becomes a Thorium tool by being packaged as a container image that reads the file and writes the result, and the platform handles the queueing, the sandbox, the storage, and the indexing around it. So the marginal cost of adding the hundredth tool is a container image and a pipeline definition, not a new integration surface.
And the static and dynamic analysis sandboxes are separate features, which means a tool can request a throwaway container with no network, or one that is allowed to execute, and the platform handles the isolation either way.
The toolbox is also a command, `thorctl`, and the same name is the CLI for the platform, so the tool import flow and the day to day interface are the same binary.
Kubernetes is the deployment, and a laptop is the dev loop
The deployment question is answered directly in the FAQ, and the answer has a specific shape.
Thorium was built and intended to run in a K8s cluster, but it can also run on a laptop using minikube. The important caveat follows immediately: the single node deployment was not intended for production and reliability and stability may be less than stellar. To deploy a single node instance you follow the Minithor docs, and the repository has a `minithor/` directory for it.
So there are two supported shapes, and the project is clear that they are not equivalent. A laptop with minikube is a way to evaluate the system and develop against it, and a real cluster is the production target. The documentation separates them into a deploy page and a single node install page.
For a full production deployment on a cluster you need two things, and they are named exactly. A block store provider, and S3 storage. For on prem deployments the recommendation is CEPH.
The choice of CEPH for the on prem case is a meaningful signal. A block store provider and S3 storage means the system assumes the Kubernetes cluster is ephemeral, which is the normal assumption for a workload that schedules thousands of short lived analysis containers, and it means the sample data and the results live in object storage rather than in a volume attached to a node. That is the right architecture for this workload, and it also means the deployment is not a single package you install.
The workspace members and the Dockerfile both show the services. The workspace has `api`, `scaler`, `agent`, `thorctl`, `reactor`, `event-handler`, `thoradm`, `search-streamer`, `operator`, `thorium-derive`, `cart-rs`, and a Python package with its stubs, and the Dockerfile copies release binaries for the api, the operator, thoradm, the scaler, the search streamer, and the event handler, along with the user and developer documentation and the UI bundle.
The presence of a search streamer as a named service, and of the Kubernetes client pulled from a git revision of kube-rs, tells you how the search over results is built and how the platform talks to the cluster.
Scale, limits, and the no-telemetry answer
The FAQ answers the questions an evaluator actually asks, and the answers are specific.
On scalability: Thorium is almost infinitely scalable if you have the compute and storage, it has been tested to support billions of samples and utilization of large amounts of compute, and it partitions data temporally and allows admins to configure how scalable they want the system to be. Temporal partitioning is the key word, because it is what makes the retention of a multi-year collection tractable, and the fact that the partitioning is configurable rather than fixed is what lets an organisation trade history against cost.
On telemetry: no, Thorium does not send any telemetry out. For a government analysis platform, that is the first question and the answer is the shortest possible one.
On file size, the answer is the one to check before you plan. Thorium supports up to about 50 GiB per file or repository, and that is after compression, so it is a fuzzy limit, and it should never be significantly smaller than 50 GiB. There are plans to increase the limit and you can create an issue if you would find that useful.
That limit is high enough to cover the large archives, disk images, and repository dumps that file analysis deals with, and the phrasing about it never being significantly smaller is a slightly odd but honest way of saying the limit is a soft one that depends on the compression ratio. A 50 GiB uncompressed file that compresses to 5 GiB counts against a different budget than one that does not compress.
The other FAQ entries are practical. Tools are included through the toolbox, and the documentation and examples are stated as an area the project plans to expand, which is a fair description of a system with a large surface and a small documentation budget.
The user interface, the API, and the multi-tenant model
The feature list groups the ways in, and the pairing is worth understanding.
There is a GUI and a CLI, and a RESTful API for automated access to data. The GUI is what an analyst sits in front of, the CLI is what you script, and the API is what another system integrates against. The `ui/` directory in the repository is the front end, and the `api/` directory holds the service and its documentation, with the user and developer docs both copied into the image.
Underneath the API there is a multi-tenant friendly permission system, and the multi-tenant part is the design decision with the most consequence. A platform that lets analysts comment and share files, tags, and results between users is a platform where a result is not private to the person who produced it, and where the permission model determines who can see which submission. Building that in from the start is a different project from adding sharing later.
The two data features work together. Full-text search of analysis results is what makes a large collection navigable, because with a million analysed samples the only way to find one is to search for it. Key/value tags for labelling data is the curated path, the way an analyst marks the interesting ones, and the combination is the usual one for this kind of platform, search for the needle and tags for the shelf you have already built.
The Python package in the workspace, `python/thorpy` with `python/thorpy-stubs`, and the `pyo3` dependency, mean there is a Python client with type stubs, so a script that drives the platform does not have to speak raw REST.
And the `search-streamer` service name is a clue about how the search is wired, since a separate streaming service suggests the index is fed incrementally as results arrive rather than rebuilt on demand.
Editorial conclusion
Thorium fits a government or enterprise malware analysis team that runs the same tool over many samples, that needs results to be searchable, tagged, and shared, and that has Kubernetes and object storage to work with. It is the wrong choice for a single analyst with a handful of samples, and the wrong choice if you cannot run a cluster, since the single node deployment is explicitly not intended for production. Check three things before you commit: that you have a block store provider and S3 storage, which the production deployment requires, that the tools you want are in the toolbox or can be packaged as an image with the right interface, and that you have read the size limit, which is around 50 GiB per file or repository after compression.
Frequently asked questions
What is Thorium and what does it actually do?
It is a scalable file analysis and data generation platform, written in Rust, that lets developers or analysts scale up and orchestrate docker, virtual machine, or baremetal based tools, search and use results from those tools, and comment and share files, tags, and results between users and analysts.
Which analysis tools ship with Thorium, and how do I add my own?
You can use the thorctl toolbox to import over 40 images and 20 pipelines into an instance, with examples including binwalk, capa, clamav, cwe-checker, email-parser, floss, foremost, ssdeep, quantumstrand, xortool, and zeek-dump. Integration is near zero-cost because a tool becomes a container image that reads the file and writes the result, with static and dynamic analysis sandboxes provided.
What do I need to deploy Thorium in production?
A Kubernetes cluster, a block store provider, and S3 storage, with CEPH recommended for on prem deployments. A single node install on a laptop using minikube is supported through the Minithor docs, but the project states it was not intended for production and that reliability and stability may be less than stellar.
How large a file can Thorium analyse, and does it send telemetry?
Thorium supports up to about 50 GiB per file or repository, measured after compression, so it is a fuzzy limit that should never be significantly smaller, and there are plans to raise it. It does not send any telemetry out.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/cisagov-thorium)Was this useful?