# OpenCATS: an open source applicant tracking system in PHP > OpenCATS is a free and open source candidate tracking system for recruiters, covering the path from job posting through application, selection and submission, with a web interface, a REST-style API surface and a MySQL backend. The repository is in the middle of a modernisation programme, and the README is mostly a set of links to the documentation, the forums and the contributor roadmap. **opencats/OpenCATS** — Open-source applicant tracking system (ATS) and recruitment CRM for staffing agencies and hiring teams. - Repository: https://github.com/opencats/OpenCATS - Website: http://www.opencats.org - Stars: 767 · Forks: 328 - Language: PHP - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/opencats-opencats ## What OpenCATS is and what it covers OpenCATS is a free and open source candidate and applicant tracking system designed for recruiters to manage the recruiting process, from job posting and candidate application through to candidate selection and submission. That description is deliberately narrow, and it is worth reading as a scope statement rather than as marketing. The unit of work is a candidate moving through a pipeline, and the system is aimed at the agency and in-house team that has to move that candidate rather than at the candidate. The topics give the shape of the deployment. It is tagged as an applicant tracking system, candidate management, hr, recruiting, recruitment CRM and staffing, with mysql and php as the stack, and the repository description names the same pairing of applicant tracking and recruitment CRM for staffing agencies and hiring teams. The project has a substantial history behind it, and that shows in the way the documentation is organised. The README is mostly a set of pointers rather than a narrative, and it points at several distinct resources. There is the project site at opencats.org, the end user and installation documentation on a separate documentation subdomain, a YouTube channel, support forums on their own domain, the open issues list on GitHub, and a contributor roadmap in the organisation's project tracker. The licence field on the repository records a custom licence that GitHub cannot classify, with the terms in a LICENSE.md file at the root, and there is a separate Security.MD file, which is worth reading before a system that holds candidate personal data goes anywhere near production. ## The repository layout and what it implies about the architecture The top level directory listing is long, and it is the most informative thing in the repository about how the system is put together. There are directories that map onto the recruitment workflow. careers/ holds the public-facing side of the system, and it comes with its own stylesheet, careersPage.css, which is the indication that the job board is a separate presentation layer rather than a set of admin screens. reports/ covers the reporting output, and attachments/ holds uploaded files such as resumes. There is an rss/ directory, which is what a job board needs so that aggregators can pick up new postings. There are directories that map onto the platform. modules/ is the plugin or feature layer, lib/ holds the shared library code, and src/ appears to be a newer tree alongside the older one. ajax/ and js/ hold the asynchronous endpoints and the client-side code, with ajax.php at the top level as the entry point, and index.php as the front controller, with config.php and a config/ directory for configuration, constants.php for shared constants, and db/ for the database layer. There is an installwizard.php and an installtest.php, which tells you that installation is a web wizard rather than a package install, and a composer.json with a composer.lock, so dependencies are managed with Composer even though the application itself is not a Composer package. There are directories that map onto the integrations. The wsdl/ directory indicates a WSDL, so the system exposes a SOAP-style interface, and the modules/ directory alongside it is where the connectors live. The scripts/ directory holds maintenance scripts, and QueueCLI.php at the top level is a command line entry point for the queue, which tells you the background processing is a first class part of the system rather than an afterthought. And there is the operational layer. A docker/ directory for containerised deployment, a phpunit.xml.dist for the test suite, a test/ directory, a docs/ directory, a CHANGELOG.MD, a CONTRIBUTING.md, an FEATURE_REQUESTS.md, and an ISSUE_TEMPLATE.md, plus the .htaccess file that a PHP application on Apache needs. ## The modernisation roadmap and how to contribute The contributing section is where the README has real content, and it describes an explicit programme rather than a wish list. The README points at the OpenCATS Modernisation and Contributor Roadmap in the organisation's project tracker, and says that if you are looking for something useful to work on, that is where to look. The roadmap is described as spanning a range of work sizes. It starts with small PHP 8.4 and 8.5 work and code quality fixes, moves through database and user interface improvements, and extends to larger recruitment, search, API and integration features. That ordering is the useful part for a new contributor. The small items are version bumps and code quality fixes, which are low-risk and well scoped, and they sit at the bottom of a list that ends with the large features, which tells you where the project thinks its weak points are. A recruitment system that predates the current PHP versions is carrying a maintenance debt that the maintainers are actively paying down, and the explicit mention of the target PHP versions is a sign the project is tracking the language rather than frozen on an old runtime. The README asks contributors to read CONTRIBUTING.md before starting substantial work, and it also points at the support forums and the documentation as the places to go for questions. There is a separate README-testing.md file in the repository root, which suggests the test setup is documented separately from the general contribution guide, which is a common pattern when the test procedure is elaborate enough to need its own page. The contribution guide is also where the code of conduct is referenced, and the project links an issue template and the open issues list, so the expectations on both sides are written down. ## Where OpenCATS is the wrong choice The first limitation is the age of the stack and what it implies. The application is PHP with a MySQL backend, and the fact that the roadmap has to name PHP 8.4 and 8.5 as upgrade targets tells you the code base is catching up with the runtime rather than having been written against it. That is entirely normal for a long-lived open source system, and it is work someone is doing, but a team that wants to build on the code rather than configure it should expect to spend time on that. The second is the installation model. There is an install wizard, a configuration file and a config/ directory, plus a docker/ directory for containerised deployment. A web wizard is a friendly way to install a PHP application, and it is also a thing that has to be secured and kept out of the document root after the first run, which is the kind of operational detail that the documentation site covers and the README does not. The third is the feature breadth against a commercial ATS. The README's own description covers job posting, application, selection and submission, and the roadmap lists recruitment, search, API and integration features as work still to do, which is a fair signal of where the feature set stands. A large corporate hiring team comparing OpenCATS against a commercial product will find gaps in the areas a commercial product has spent years on, such as interview scheduling, offer management, sourcing campaigns and analytics. The fourth is the data. A candidate tracking system holds resumes, contact details, interview notes and salary expectations, which under most jurisdictions is personal data with retention obligations, and the presence of a Security.MD file in the repository is a good sign but not a policy. The fifth is that the support model is a forum and a YouTube channel. That is fine for a self-hosted open source project, and it is not a substitute for a contract. ## OpenCATS compared with a hosted ATS and with a spreadsheet workflow The comparison with a hosted applicant tracking system is the one every buyer starts with, and the difference in approach is ownership. A hosted system gives you a maintained product, a support contract, a compliance posture somebody else maintains, and a monthly cost, and it gives away the ability to change the workflow when your agency does something unusual. OpenCATS gives you the opposite: the workflow is yours to change, the data stays in your database, and the cost is your own time and hosting. For a staffing agency whose process is a differentiator, that trade is often worth making, and it is why an open source ATS in this category still attracts contributors after this many years. The second comparison is with the spreadsheet, which is what a small recruiting shop actually uses. A spreadsheet is free, requires no infrastructure, and is understood by everyone. It fails at the point where you need to track a candidate through several stages, search across thousands of records, and give interviewers access to the history, and at the point where access control matters, since a shared sheet has no notion of who can see which candidate. OpenCATS is the step up from that, and for a team of two it is arguably too much of a step up. The third comparison is with the other open source applicant tracking systems, and here the differentiator is the workflow vocabulary. The careers/, reports/, rss/ and wsdl/ directories describe a system that expects to publish jobs to aggregators, produce reports and expose an interface to other software, which is the profile of a system aimed at agencies running a pipeline rather than a single employer logging candidates by hand. The fourth is with building your own on a framework, and the honest difference is that OpenCATS is a working system with a user base and a history, which is worth more than the flexibility of a blank project unless your workflow is genuinely unique. ## Licence, project state and what to check before you deploy it The licence field on the repository records a custom licence that GitHub cannot classify, and there is a LICENSE.md file at the root, so that file is the authoritative statement of the terms. For a system that will hold candidate records and that you may run as a service for your own clients, reading it is a necessary step rather than a formality. The project is not archived and the last push was on 2026-10-19, so it is being worked on. The release history is steady, with v0.11.1 from 2026-09-03, v0.11.0 from 2026-08-27 and v0.10.0 from 2026-06-23, so the minor version moves with features and fixes, and pinning a version is a reasonable thing to do for a deployment. The repository also has a CHANGELOG.MD, which is the file to read before upgrading, since an applicant tracking system that holds historical candidate data has migrations that matter more than usual. Four things to check before you deploy it. The end user and installation documentation, since the README explicitly defers to it and the installer is a web wizard that needs to be locked down afterwards. The licence, since the terms are custom and the classification could not be automated, and since a deployment that serves candidates on behalf of a client is a commercial use that you should be sure about. The security policy and the reporting route, before you make the site reachable, not after. The Security.MD file in the repository root is where that is written down. And the roadmap, because the state of the database, user interface, API and integration work tells you which parts of the recruitment workflow you will be relying on and which you will be building yourself. ## Conclusion OpenCATS suits a recruitment team that wants to own its candidate data and run the pipeline itself, particularly a staffing agency whose workflows the commercial systems do not fit, and it suits a PHP developer who wants to contribute to a system with a real user base. It is the wrong tool for a company that expects a hosted product with a support contract, and the wrong choice if you need the breadth of features a commercial ATS ships. Before you deploy it, read the end user and installation documentation, because the installer is a web wizard rather than a package, and check the licence file, since the repository records terms that GitHub cannot classify. ## FAQ ### What is OpenCATS? It is a free and open source candidate and applicant tracking system for recruiters, covering the process from job posting and candidate application through to selection and submission. It is written in PHP on MySQL and is aimed at staffing agencies and hiring teams. ### How do I install OpenCATS? The README does not give the steps itself and defers to the end user and installation documentation at documentation.opencats.org. The repository shows that installation is a web wizard, with installwizard.php and installtest.php at the top level, and that a docker/ directory exists for containerised deployment. ### What does the OpenCATS repository contain? A careers/ directory for the public job board, modules/ for features, lib/ and src/ for the application code, reports/ for reporting output, attachments/ for uploaded files, rss/ for job feeds, a wsdl/ directory for the SOAP interface, ajax/ for asynchronous endpoints, db/ for the database layer, a QueueCLI.php command line entry point for background processing, and a docker/ directory for deployment. ### How do I contribute to OpenCATS? The README points at the OpenCATS Modernisation and Contributor Roadmap in the organisation's project tracker, which lists work from small PHP 8.4 and 8.5 and code quality fixes through database and user interface work to larger recruitment, search, API and integration features. It asks you to read CONTRIBUTING.md before starting substantial work. ### Does OpenCATS expose an API? The repository contains a wsdl/ directory, which indicates a SOAP-style web service description, and the modernisation roadmap lists API and integration features among the work in progress. There is also a modules/ directory where the connectors live, and a separate group for people developing the application itself. ### What licence does OpenCATS use? The repository records a custom licence that GitHub cannot classify, with the terms in the LICENSE.md file at the root, and there is a separate Security.MD file describing how to report security issues. ## Sources - [Issues](https://github.com/opencats/OpenCATS/issues) - [opencats/OpenCATS on GitHub](https://github.com/opencats/OpenCATS) - [Project website](http://www.opencats.org) - [README](https://github.com/opencats/OpenCATS/blob/master/README.md) - [Releases](https://github.com/opencats/OpenCATS/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/opencats-opencats