# tirreno: Self-hosted fraud detection with PHP and PostgreSQL

> tirreno adds application-level security analytics, risk rules, review queues, and audit trails to self-hosted products. It suits PHP teams that need a self-hosted control plane, but its PHP, PostgreSQL, Apache, and cron requirements narrow deployment options.

**tirrenotechnologies/tirreno** — tirreno is an open-source framework for building sovereign security, compliance and fraud prevention applications. Detect account takeovers, cyberfraud and business logic abuse inside your product.

- Repository: https://github.com/tirrenotechnologies/tirreno
- Website: https://www.tirreno.com
- Stars: 1,552 · Forks: 183
- Language: PHP
- License: AGPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/tirrenotechnologies-tirreno

## tirreno's application-layer security boundary

tirreno is designed for attacks that occur after traffic has crossed conventional infrastructure defenses. Its README distinguishes application compromise from network-perimeter threats, with particular attention to compromised accounts and business logic abuse. Instead of relying only on a WAF, SIEM, or firewall, the framework receives security-relevant events from the product and makes those events available through a dashboard, user-oriented investigation views, rules, and a review queue.

The intended users are teams operating SaaS platforms, internal applications, legacy systems, ecommerce services, marketplaces, APIs, command systems, and other sensitive software. The documentation also names non-human identities such as service accounts, API keys, and bots as subjects that can be monitored. This positioning makes tirreno closer to an application security analytics layer than to a conventional infrastructure scanner.

That scope is broad. Account takeover, credential stuffing, promotional abuse, multi-accounting, insider threats, high-risk regions, and API abuse are all preset rule categories. Whether those categories produce useful decisions depends on the context attached to each event and on how an operator adapts the thresholds to a particular product. The README does not describe model training or a universal scoring method. Its stated mechanism is rule-based risk calculation with preset rules and custom rules.

## Event ingestion, rules, and the tirreno control plane

The architecture is a hand-written PHP application backed by PostgreSQL. Product code sends events through tirreno's API or one of the listed SDKs, including PHP, Python, NodeJS, and WordPress trackers. The README does not publish a complete event payload or authentication example, so an integrator must consult the separate developer documentation rather than infer required fields from the high-level description.

Once events are ingested, the rule engine assigns risk according to built-in or custom rules. Operators can suspend entities automatically when risk crosses a threshold or place them into a review queue for manual inspection. A single-user view then brings together behavior patterns, risk scores, connected identities, and an activity timeline. This is the clearest path from a raw signal to an operational decision: an event enters through an integration, a rule evaluates it, an entity is scored, and an operator investigates or acts on the result.

The built-in `tirreno('…')` API exposes the same components used by the console, including request and page context, ingested data, the rule engine, a `tirreno('queries')` builder, logging, and utilities. Repository examples for LLM bots and risk users show that product-specific sections can be built into the interface. The project also tracks changes to important fields through a field audit trail, recording what changed and when. That combination of scoring, investigation, action, and field history is more relevant to compliance and fraud review than simple log search alone.

## Docker, Composer, and the first administrator session

The quickest documented deployment starts from the project's compose file. The following command downloads that file and starts tirreno in the background. The README then directs Docker users to step 4 of the Quickstart.

```bash
curl -sL tirreno.com/t.yml | docker compose -f - up -d
```

For a conventional web-server installation, the README requires PHP 8.0 through 8.3, PostgreSQL 12 or later, `PDO_PGSQL`, and `cURL`. It also specifies Apache with `mod_rewrite` and `mod_headers`. Download the latest ZIP, extract `tirreno-master.zip`, and open the installer at this address:

```text
http://localhost:8585/install/index.php
```

After installation, delete the `install/` directory and its contents. Then open the signup page to create the first administrator account. The project documents this address:

```text
http://localhost:8585/signup/
```

A first useful operational step is scheduling the cron entry. Run it every ten minutes with `crontab -e`, or add it to the server's cron file:

```bash
*/10 * * * * /usr/bin/php /absolute/path/to/tirreno/index.php /cron
```

The README does not provide a concrete event-ingestion request or complete SDK snippet, so the documented first use ends at initialization, administrator creation, scheduled processing, and dashboard access. Integrators should use the linked developer documentation and the SDK repositories for payload and authentication details.

## Composer deployment and infrastructure boundaries

For PHP teams, tirreno is also published through Packagist. It can be installed as a standalone Composer project:

```bash
composer create-project tirreno/tirreno
```

An existing PHP project can require the package instead:

```bash
composer require tirreno/tirreno
```

Composer support does not remove the service dependencies. PostgreSQL remains mandatory, and the stated HTTP requirements name Apache with `mod_rewrite` and `mod_headers`. A Unix-like operating system is recommended rather than required. Teams standardized on Nginx, serverless PHP, or managed PHP platforms may therefore need an additional compatibility layer or a different hosting arrangement. The README does not document such a layer, so it should not be assumed to work.

Capacity planning is unusually explicit. The project states a minimum of 512 MB RAM for PostgreSQL, with 4 GB recommended, and 128 MB for the application, with 1 GB recommended. Storage is estimated at approximately 3 GB of PostgreSQL data per one million events. That figure makes event volume a design constraint rather than an afterthought. High-volume ingestion requires retention decisions, but the README excerpt does not define retention controls, partitioning guidance, archival procedures, or backup procedures.

The repository layout includes `sensor/`, `app/`, `ui/`, `install/`, `libs/`, `tests/`, configuration files, and cron-related files. Based on that layout, installation, application logic, sensor components, interface code, and tests are separated into recognizable areas. The available documentation does not explain the internal boundaries in enough detail to make extension compatibility claims.

## Operational limits, licensing, and maintenance evidence

The first operational limitation is that tirreno assumes PostgreSQL and a PHP web environment that meets its documented versions. It also assumes enough event storage for the telemetry an integration sends. Because the application receives rich contextual events, teams can create a large database quickly if they lack event-level retention limits. The documentation's 3 GB per million events estimate is a starting point, not a capacity guarantee.

A second limitation concerns evaluation accuracy. The framework provides preset categories and custom rules, but the README does not explain calibration, false-positive handling, rule versioning, rollback, or how a rule is promoted from testing to enforcement. It also does not document an event-delivery guarantee for the SDKs. Those omissions matter when an automated suspension can affect a paying customer or an operational system.

The repository is licensed under `AGPL-3.0`. That identifier matters to organizations considering modifications, redistribution, or network deployment, but this review does not provide legal interpretation. Operators should examine the repository's `LICENSE` and `LEGALNOTICE` files for the exact terms. The README states that the project began as proprietary software in 2021 and was open-sourced under AGPL in December 2024.

Maintenance evidence includes releases `v0.9.12` on 2026-02-12, `v0.10.0` on 2026-07-02, and `v0.10.1` on 2026-08-15. The last push was on 2026-10-06, and the repository is not archived. These dates show recent project activity. Upgrade planning still requires reading `CHANGELOG.md`, `RELEASE_NOTES.md`, and the linked admin documentation, because this excerpt does not describe migration steps or automatic compatibility with earlier releases.

## How tirreno differs from perimeter security tooling

The clearest alternative described by the project is a conventional perimeter stack built around firewalls, WAFs, and SIEMs. That approach examines network and infrastructure conditions, while tirreno is designed to inspect account behavior, connected identities, application events, and business rules inside a product. The README says such application abuse can bypass perimeter controls, so tirreno's value comes from adding product context rather than replacing every perimeter control.

A traditional WAF or rate limiter is also a reasonable alternative for a narrow need. WAFs can enforce request-level filtering, and rate limiters can constrain repeated requests without operating a PostgreSQL event history or entity timeline. tirreno is a better fit when the operator needs rules such as credential stuffing, multi-accounting, promotional abuse, or account registration, plus a review queue and field-level history. It is the wrong tool for a single low-volume endpoint that needs only static header or path filtering.

The trade-off is operational scope. tirreno adds PostgreSQL storage, a PHP control plane, Apache-oriented configuration, SDK integration, rule tuning, cron processing, and dashboard administration. It is not a transparent library that imposes no infrastructure. Its application-level context is the distinguishing capability, while that infrastructure and calibration burden are the price of maintaining a separate security control plane.

## Conclusion

Adopt tirreno when a self-hosted PHP control plane and PostgreSQL-backed event analysis fit the operating model. Do not adopt it for a stack that cannot meet its runtime or Apache requirements. Verify event-schema compatibility, event growth against the documented storage allowance, and AGPL-3.0 obligations before connecting production data.

## FAQ

### What are tirreno's system requirements?

tirreno requires PHP 8.0 through 8.3, PostgreSQL 12 or later, `PDO_PGSQL`, and `cURL`. Its documented HTTP setup uses Apache with `mod_rewrite` and `mod_headers`, and it recommends a Unix-like operating system.

### How do I install tirreno with Docker?

The README documents a Docker Compose command and then directs the operator to step 4 of the Quickstart. The remaining process includes completing installation, deleting the `install/` directory, and creating an administrator through the signup page.

### Which SDKs are available for tirreno?

The README lists SDK repositories for PHP, Python, NodeJS, and WordPress. Product code can use these trackers or interact with tirreno through its API.

## Sources

- [License: AGPL-3.0](https://github.com/tirrenotechnologies/tirreno/blob/master/LICENSE)
- [Project website](https://www.tirreno.com)
- [README](https://github.com/tirrenotechnologies/tirreno/blob/master/README.md)
- [Releases](https://github.com/tirrenotechnologies/tirreno/releases)
- [tirrenotechnologies/tirreno on GitHub](https://github.com/tirrenotechnologies/tirreno)

---

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