Rubix ML: Machine Learning Inside a PHP Application, Without Leaving PHP

The gap Rubix ML fills: models that ship with the PHP app

Most teams that want machine learning end up splitting their stack. The application stays in PHP, and a Python service does the modelling. That split costs a second runtime, a second deployment target and a network hop on every prediction. Rubix ML takes the other position: the model is a PHP object, trained and inferred inside the same process that already serves the request. The README frames this directly, describing a library that 'allows you to build programs that learn from your data using the PHP language' and covers 'the entire machine learning life cycle from ETL to training, cross-validation, and production'. The intended audience is therefore not data scientists looking for a new framework. It is PHP developers and small product teams who already have data in MySQL, PostgreSQL or a CSV export, and who want a classifier or a clusterer without standing up a separate service. The library ships 40 or more supervised and unsupervised algorithms, which is enough breadth that a tabular problem usually has a reasonable candidate without leaving the language.

What the library actually contains: learners, ETL and validation

The README lists four capability areas: supervised and unsupervised learning algorithms, ETL, preprocessing, and cross-validation. Those are the four moving parts of a typical Rubix ML project, and the tutorials map onto them. Iris Flower Classifier and Titanic Survival Predictor are classification on small tabular data. Housing Price Predictor is regression. Color Clusterer is unsupervised clustering. Credit Default Risk Predictor and Customer Churn Predictor are the business-facing variants of the same tabular classification shape. DNA Taxonomer and Human Activity Recognizer lean on sequence and sensor data. CIFAR-10 Image Recognizer and MNIST Handwritten Digit Recognizer are the image path, and Text Sentiment Analyzer covers natural language. The topic list on the repository repeats this spread: analytics, anomaly detection, classification, clustering, deep learning, machine learning, natural language processing, PHP and regression. The honest reading is that the library is broad rather than deep in any one area. There is a deep learning component, and there is anomaly detection, but neither is presented as the centre of the project. The centre is tabular learning with the surrounding plumbing (transforms, validators, dataset objects) that makes it usable.

Installation and the extension matrix you have to check first

Installation is one Composer command, quoted from the README: composer require rubix/ml. The hard requirement is PHP 7.4 or above. Everything else is optional, and the README is explicit about which extension buys what. The Tensor extension is listed under Recommended and is described as being 'for fast Matrix/Vector computing', which tells you the pure-PHP path exists but is the slower one. Under Optional: GD for image support, Mbstring for fast multibyte string manipulation, SVM for the Support Vector Machine engine backed by libsvm, PDO for relational database support, and GraphViz for graph visualization. Read that list as a deployment checklist rather than trivia. A container image built from a minimal PHP base will typically lack GD, Mbstring and PDO drivers, and the SVM extension is a PECL install that most base images do not carry. The failure mode is not a clear error at install time, because Composer will happily resolve the package. It is a missing capability discovered later, when you try to load images, read from a database, or instantiate an SVM learner. Decide which of those five you need before you write the Dockerfile.

Where Rubix ML is the wrong tool

The README does not make performance claims, and it should not be read as if it did. The realistic constraint is that this is a PHP library executing in a PHP process, with an optional native Tensor extension as the acceleration path. Training large models in a request cycle is not what it is built for. If your problem needs GPU training, distributed training, or a model with hundreds of millions of parameters, the tooling in this repository is not aimed at you, and the deep learning topic in the repository metadata should not be read as a claim of parity with a dedicated deep learning framework. Two more boundaries are worth stating. First, the pretrained-model story is thin in the material available here: the README points to tutorials and example projects with pre-cleaned datasets, not to a model zoo of downloadable weights. If your plan is to fine-tune an existing large language model, this is the wrong starting point. Second, the example projects are educational. They are listed as tutorials, several with instructions and a pre-cleaned dataset. That is a good way to learn the API and a poor way to estimate production throughput, because the datasets are deliberately small.

The real alternative, and the shape of the difference

The obvious alternative is scikit-learn in Python, usually behind a small HTTP service or a job queue. The difference is not which algorithms exist, because both cover classification, regression and clustering on tabular data. The difference is where the model lives and who maintains it. With scikit-learn you get a much larger ecosystem, a NumPy and pandas data path, and a hiring pool that already knows the API. You pay for it with a second runtime in production, a serialization boundary between the PHP app and the Python service, and a second set of dependencies to patch. Rubix ML collapses that boundary: the estimator is a PHP object, the dataset is a PHP object, and the prediction happens in the same process as the request. For a churn score, a risk flag or a cluster assignment computed from columns you already have, that collapse is the whole argument. For anything that needs a GPU or a pretrained transformer, the collapse is not worth it and the Python route wins on capability. A second, quieter alternative is to skip a library entirely and hand-write a logistic regression or a threshold rule. That is defensible for one or two features. It stops being defensible once you need cross-validation, because you will end up rebuilding the validation plumbing that the README lists as a built-in.

Maintenance, release cadence and licence terms

The release history shows a steady patch cadence: 2.5.11, 2.5.12 and 2.5.13 landed within roughly two weeks of each other in August and September 2026, and the repository was pushed on 2026-09-10. Frequent patch releases on a 2.5.x line suggest active maintenance rather than a frozen project, and it also means you should expect to move patch versions regularly. The practical upgrade cost is low if you stay inside the public API, because the version bumps are patch-level, and higher if you subclass learners or transforms, since internal behaviour is the part most likely to shift between patches. There is no separate runtime to operate and no service to keep warm, which is the main reason the operational cost is lower than a split stack. On licensing: the README states the code is MIT and the documentation is CC BY-NC 4.0. Those are two different licences covering two different things. MIT on the code is permissive and the README itself notes the library is 'free to use commercially'. The documentation licence is non-commercial, which matters if you plan to copy documentation text into your own product or training material. That is a distinction to raise with whoever handles licensing at your organisation; it is not a legal opinion, and the two files (LICENSE and the linked CC BY-NC 4.0 terms) are the authority.

Who should adopt it, and what to prove first

Adopt Rubix ML when the application is PHP, the features are tabular or can be reduced to tabular form, and the model can be trained offline and stored rather than retrained per request. The Iris, Housing, Titanic, Credit and Churn examples are the closest match to that shape, and they are also the fastest way to confirm the API fits your data. Do not adopt it if you need GPU training, a broad catalogue of pretrained models, or a research workflow with the surrounding Python tooling; in those cases the split-stack approach is the honest choice. Before committing, run three checks. Confirm the PHP version on your target hosts is 7.4 or above. Confirm which of the Tensor, GD, Mbstring, SVM and PDO extensions you actually need and whether your base image provides them, since a missing SVM extension only surfaces when you instantiate that learner. And pick the packaged example project closest to your problem, run it end to end, and measure how long training takes on your hardware with your row count, because the tutorials use small pre-cleaned datasets and will not tell you that. If the example trains in a time you can live with, the library will do the job it advertises.

Editorial conclusion

Adopt Rubix ML if your data access layer, your deployment pipeline and your team are already PHP, and the model is small enough to train inside a normal request or a queue worker. Do not adopt it if you need GPU training, a wide catalogue of pretrained transformers, or a research ecosystem, because the library's own documentation points to PHP 7.4 and Composer as the whole installation story. Verify two things before committing: whether the optional Tensor, GD, Mbstring, SVM and PDO extensions are present on your target hosts, and whether the packaged tutorials (Iris, Housing, Titanic) map onto your actual feature types. If your features are images or long text, check the CIFAR-10 and Sentiment example projects first, since those are the ones that exercise the non-tabular path.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. RubixML/ML on GitHub