itflow-org/itflow: the documentation, ticketing and accounting system aimed at a small MSP

The problem statement names a specific company

The About section of the README is the most useful thing in the repository, because it states who the software is for in the first person.

The reader is a small but busy managed service provider with 101 things to do, whose information about clients is unorganised, unstructured and outdated. The complaint about documentation is specific rather than general, that for some work you spend longer looking for the relevant documentation than actually working on the issue or project. The commercial argument is that MSP tools can be expensive, with recurring licensing costs adding up quickly. And the business argument is that on top of the technical day to day you also have to take care of the financial side, with consistent pricing, quotes, invoicing and accounting.

That is four distinct pain points, and the solution is stated in one line: ITFlow consolidates common MSP needs, documentation, ticketing and billing, into one unified, free platform that you control.

The scope of the project follows from that framing. The topic list covers contact management, CRM and lead management, asset and asset lifecycle management, licence management, domain management, SSL certificate management, password management, documentation and file management, network and location management, estimates, invoicing, expenses, project management and ticket management. That is a professional services automation surface, not a help desk, and the intended customer is the person who does the technical work and also has to raise the invoice.

A PHP application organised by who is logged in

The repository layout is a plain PHP application, and the directory names are the architecture.

There are role directories: `admin/` for the administrative back office, `agent/` for the technician or helpdesk view, `client/` for the client portal, and `guest/` for the unauthenticated parts. There are `api/`, `cron/` for scheduled jobs, `modals/`, `post/` for form handling, `scripts/` and `functions/` for shared logic, with `functions.php` and `login.php` at the top level, `index.php` as the entry point, and `setup/` for the installer. Static assets sit in `css/`, `js/` and `libs/`, and user content goes to `uploads/`.

The schema is a single `db.sql` file at the root rather than a migrations directory, which is a strong signal about the project's conventions and about the deployment model it expects.

That model is a shared hosting style application. There is a `.htaccess` at the root, so Apache configuration is part of the deployment, a `robots.txt` for the crawler rules, and a `keepalive.php` that is the sort of file a traditional LAMP stack includes to keep a session alive during long operations.

It is a deliberately unfashionable architecture, and for the target customer that is a feature. A small MSP's web host is likely to be a shared PHP plan with a phpMyAdmin button, and a framework free application with one SQL file and a directory of uploads installs into that without a build step.

Installation is one script on Ubuntu and Debian

The recommended installation method is a script, and the commands are short:

wget -O itflow_install.sh https://github.com/itflow-org/itflow-install-script/raw/main/itflow_install.sh
bash itflow_install.sh

The script lives in a separate repository, the itflow-install-script project, which is a sensible arrangement, since the installer has its own release cycle and its own contents, and pulling it over the network with wget means you can read it before you run it. The documentation says to see the installation script page, and there is a video walkthrough linked as well.

Other manual installation methods are documented separately in the docs, which is the right arrangement for anyone who cannot run a script, whether because the host is not Ubuntu or Debian, or because the hosting provider restricts what a script may do.

The managed hosting option is listed as coming soon, and that word matters. The project currently asks you to host it yourself, so the cost of the product is your server and your time, and a reader evaluating it should price that in rather than assume a hosted tier exists. The hosting page is under the services domain, the same one the sponsors and the paid support offer sit on.

Four feature groups, and the ones that matter daily

The key features section lists four things, and the grouping tells you what the product thinks a MSP actually does all day.

Client documentation is first, covering assets, contacts, domains, documentation and files, passwords, tickets and more. That is the unorganised, unstructured and outdated complaint answered, and the fact that passwords sit in this list is a fact you should come back to, because the security note in the README says to use your best judgement before storing highly confidential information in ITFlow.

Billing comes second, with quotes, invoices and expenses, and Stripe integration for online payments. For a service business the invoice is the part of the admin that must not fail, and having it next to the ticket that triggered the work is the integration argument.

Alerting third, for domain and SSL expiry and renewals. This is the feature that is hard to build well yourself and expensive to buy, and for an MSP holding client domains and certificates it is close to the reason to adopt the product at all. The topic list also includes licence management and asset lifecycle management, which sit in the same family of recurring obligations.

The client portal is fourth, giving clients self service quote, invoice and ticket management. That is the piece that removes the phone calls, and the reason the repository has a separate `client/` directory and a `guest/` one is that the portal is a different application surface sharing the same database.

Community pull requests are temporarily paused

The contributing section is short and the first line is the one to notice: the project has temporarily paused PRs from the community.

Everything else follows the usual pattern. The community forum is the place for help, bugs, feature suggestions and general discussion, and the README points bug reports and feature suggestions at two specific forum topics. The roadmap is tracked with TaskFlow, an external task tracker at tasks.dev.itflow.org, which is where confirmed features and bugs live, and the forum is where new ideas are proposed before they become tracked work.

The pause on pull requests is a governance signal rather than a technical one, and it cuts both ways. For a user, it means the shape of the product is currently decided by the maintainers and the sponsor funded support, which for a tool you self host is arguably a clearer model than an open contribution flow. For someone who wants to contribute code, it means the door is closed for now, and the reason is not stated.

The commercial side is visible in the supporters list, where CompuMatter, F1 for HELP and digiBandit are thanked for sponsoring the project through the services domain. A self hosted project with sponsors and a paid support offering is a project with a business model, and for a buyer that is a factor, since it means there is someone to pay when you need help.

The security note deserves a careful reading

The README has a short security section, and it is honest in a way that a lot of security sections are not.

The project states that it has had a stable release since January 2025, that while the maintainers are confident in the safety of the code, no system is risk free, that nearly all software has bugs, and that you should use your best judgement before storing highly confidential information in ITFlow. Security concerns are to be reported privately through the GitHub security policy rather than in the forum.

That last instruction is the important one operationally. A reported vulnerability in a product that stores client passwords, certificates and billing records is a genuine incident, and the difference between a private report and a public issue is the difference between a patched vulnerability and an exploited one.

The licence is GPL, distributed as is without warranty of any kind, which is the standard formulation and worth pairing with the earlier point. A self hosted system that holds credentials and financial data is one you are responsible for, and the project is telling you so in writing before you install it rather than after.

One practical consequence is that the client portal, the API and the scheduled jobs are all attack surface that only you can see, because you run them. The demo instance at demo.itflow.org, with the credentials [email protected] and demo, is useful for evaluating the interface, but it is also a reminder that a public instance of this application is a public instance.

Where ITFlow is the wrong tool

The first wrong case is a company that is not a small MSP. The scope is stated plainly in the repository description as an all in one PSA for MSPs, and the feature list is the work an MSP does. A larger services organisation with a formal sales process, a services catalogue and a multi entity finance setup will find a tool built for one operator's workflow, and the commercial tools the project complains about exist precisely because they cover more ground.

The second wrong case is a team that will not run a server. The product is self hosted software with a database, a cron directory and an uploads directory, and while a managed hosting tier is listed as coming soon, the supported path today is a VPS or a shared host that runs PHP. A team that wants someone else to answer the pager is looking at the services offering rather than the repository.

The third is a regulated environment with a hard answer on where credentials live. The project says so itself, use your best judgement before storing highly confidential information, and that is advice to take seriously rather than to route around.

The fourth is a company that already runs a well integrated stack. An ITFlow instance is its own system of record for documentation, tickets, invoices and the client portal, and migrating that in is a project, not an install.

On the release cadence, the project ships on a monthly cycle, with v26.08 on 2026-08-04, v26.09 on 2026-09-01 and v26.10 on 2026-10-01, and the last push to the repository on 2026-10-19. A `CHANGELOG.md`, a `CONTRIBUTING.md`, a `CODE_OF_CONDUCT.md` and a `SECURITY.md` are in the tree, and the default branch is `master`.

Editorial conclusion

Adopt ITFlow if you run a small managed service provider and want documentation, ticketing and invoicing in one self hosted application you control, since the recurring licence cost of a commercial PSA is the problem the project names directly, and the monthly release tags suggest the product is actively maintained. Do not adopt it if your team is larger than a small MSP, since the whole design is scoped to that case, and do not store your most sensitive credentials in it without reading the project's own security note, which says to use your best judgement before storing highly confidential information. Verify first that the install script suits your platform, that you can maintain a self hosted PHP application with its own database and uploads directory, and that the current release, v26.10 from 2026-10-01, is the one you want to run.

Frequently asked questions

Official sources

1. itflow-org/itflow on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases