# Turbinia turns forensic tools into a distributed Celery workload

> Turbinia is an Apache-2.0 framework from Google for running forensic processing tools such as Plaso and TSK across a fleet of workers, driven by a client request and a server that splits evidence into tasks. The project is in maintenance mode and points new users to OpenRelik.

**google/turbinia** — Automation and Scaling of Digital Forensics Tools

- Repository: https://github.com/google/turbinia
- Stars: 796 · Forks: 172
- Language: Python
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/google-turbinia

## Forensic tools as scheduled tasks rather than shell scripts

Turbinia exists to remove the manual step of running evidence processing tools one after another. The project describes it as an open source framework for deploying, managing and running distributed forensic workloads, intended to automate the running of common forensic processing tools such as Plaso, TSK and strings. The stated goals are processing evidence in the cloud, scaling the processing of large amounts of evidence, and decreasing response time by parallelising processing where possible.

That framing matters for how you read the rest of the system. Turbinia is not a new forensic tool and it does not add new analysis. It is an orchestrator that sits in front of tools you already use, decides what runs where, and keeps track of the results. The repository is written in Python and the tooling around it, including docker/, k8s/, monitoring/ and a web/ directory, suggests a deployment that assumes a container platform rather than a laptop.

## Client, server and workers, with Kombu between them

The architecture splits into three roles. The client makes requests to process evidence. The server turns those requests into logical jobs and then schedules forensic processing tasks. One or more workers run continuously and pick tasks off the server. Evidence is split by the jobs where the tooling allows it, so many tasks can work on the same input in parallel, and any new evidence created or discovered by a task is fed back into Turbinia for further processing.

The plumbing is Kombu for messaging between client and server, and Celery for task scheduling in the worker implementation. The dependency list in pyproject.toml confirms this and adds the surrounding services: celery, redis, opensearch-py, fastapi, httpx, pandas, pydantic, ratelimit and filelock. Turbinia also depends on libcloudforensics and acstore, which places it in the cloud forensics ecosystem rather than in the local disk imaging world.

## Starting the server, the API server and a worker

The documented startup sequence after installation and configuration has three server side pieces and one client side piece. The server component is started first, the API server is started as well when Celery is in use, and at least one worker must be running for tasks to be picked up:

```bash
turbiniactl server
turbiniactl api_server
turbiniactl celeryworker
pip install turbinia-client
```

The turbiniactl entry point comes from the packaging metadata, where the console script maps to the turbinia package main function. The client is installed separately from the server side, which is a hint about the intended topology: the people running the client are not necessarily the people running the workers. Installation itself is handled by a guide on the project documentation site rather than by a command shown here.

## Submitting evidence and checking status from the client

Once the backend is up, evidence goes in through the client, and the same client reports on what is running:

```bash
turbinia-client submit ${evidencetype}
turbinia-client status
```

The client talks to the API server rather than to the server component directly, and its location is configurable. The help output shows that the API server address is set in ~/.turbinia_api_config.json, with options for a configuration instance name and for the path to that file. The command groups are deliberately narrow: config for the Turbinia configuration, evidence for uploading or retrieving evidence, jobs for the list of enabled jobs, result for request or task results, status for status, and submit for new requests.

For people who would rather not use the command line, the project also exposes a Python API library under turbinia/api/client, with examples in the repository.

## Optional dependencies decide which forensic tools can run

The tool set is not hard coded into the core. The dependency list marks several forensic packages as optional, including plaso, dfimagetools, dfDewey, pyhindsight, lief and pyssdeep, alongside others such as asn1crypto and google-api-core. A deployment that installs only the required dependencies gets the orchestration machinery without the heavier analysis packages.

Two operational extras sit alongside the core. The optional packages behind Docker support, which the documentation lists as a way to execute jobs, and the k8s/, skaffold.yaml and docker/ directories at the top of the repository suggest a Kubernetes path. Prometheus metrics are supported through the prometheus_client dependency, and the monitoring/ directory points at a deployment that expects its own observability stack rather than leaving status on the console.

## Maintenance mode: no new features, and a successor project

The README opens with the most important fact about the project today: Turbinia will not develop new features anymore and is in maintenance mode, and users are pointed at OpenRelik. The status section separately states that Turbinia is currently in Alpha release, which is an unusual pairing and worth holding in mind before building a process around it.

The code is not frozen. The last push was on 2026-10-17, while the most recent tagged release, 20250131, is dated 2025-02-05, with earlier tags 20240930 and 20240820 behind it. The project is licensed under Apache-2.0, which is the permissive licence declared in pyproject.toml and in the LICENSE file. The fine print also says the project is not an official Google product, it is code that happens to be owned by Google, so treat it as community software when you plan around it.

## Where the orchestration layer costs more than it saves

The overhead is real for a single case. The documented deployment wants a server, an API server when Celery is used, and one or more workers, plus Redis, Celery and OpenSearch in the dependency set. One analyst with one disk image and one Plaso run does not need any of that, and the Alpha status does not encourage the risk of standing up a distributed pipeline for a one-off.

The feedback loop also deserves attention. New evidence created or discovered by a task is fed back into Turbinia for further processing, which is the feature that makes recursive carving worthwhile on large inputs and the behaviour that makes it hard to reason about when something goes wrong. There is also no documented rollback for a job, and the project does not describe how to migrate an existing pipeline to OpenRelik, so a migration plan is on you. Anyone starting new work should read the OpenRelik pointer before installing.

## Conclusion

Turbinia fits teams that already have cloud evidence pipelines, a Redis and OpenSearch backend, and analysts who want Plaso and TSK style processing spread over many workers instead of one machine. It does not fit a single analyst with one disk image, and it does not fit a team that needs new features, because the README states no new features will be developed and points to OpenRelik instead. Before installing, read the maintenance note and the Alpha status, then confirm your Redis, Celery and OpenSearch dependencies are already part of your platform, because the deployment shape is a server, an API server and at least one worker rather than a single binary.

## FAQ

### Is Turbinia still being developed?

The README states that Turbinia will not develop new features anymore and is in maintenance mode, and it directs users to OpenRelik. The last push was on 2026-10-17, but the most recent tagged release, 20250131, is dated 2025-02-05.

### What components do I need to run before submitting evidence to Turbinia?

The documented sequence is turbiniactl server for the server component, turbiniactl api_server when using Celery, and turbiniactl celeryworker for one or more workers. The client is installed separately with pip install turbinia-client, and evidence is then submitted with turbinia-client submit.

### Which forensic tools can Turbinia run?

The README names common forensic processing tools such as Plaso, TSK and strings. In the dependency list, plaso, dfimagetools, dfDewey, pyhindsight, lief and pyssdeep are optional packages, so they are only present if the deployment installs them.

### Can I use Turbinia from Python instead of the command line?

Yes. The project provides a Python API library under turbinia/api/client, with examples in the repository, alongside the turbinia-client command line tool that interacts with the API server.

## Sources

- [google/turbinia on GitHub](https://github.com/google/turbinia)
- [Issues](https://github.com/google/turbinia/issues)
- [License: Apache-2.0](https://github.com/google/turbinia/blob/master/LICENSE)
- [README](https://github.com/google/turbinia/blob/master/README.md)
- [Releases](https://github.com/google/turbinia/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/google-turbinia