Relaticle: a self-hosted CRM whose MCP server is the product
Open-source CRM with native AI agent support. 37 MCP tools, REST API, self-hosted. Built with Laravel & Filament
At a glance
- What is it?
- Relaticle is an AGPL-3.0 Laravel and Filament CRM that exposes 37 MCP tools so AI agents can read and write CRM records. The install path is short, but PHP 8.5 and PostgreSQL 17 raise the floor on where it can run.
- Who is it for?
- Adopt Relaticle if you run your own infrastructure and want an agent to work the CRM through MCP rather than through a vendor's closed API. Do not adopt it if you need a hosted product with no ops burden, or if your servers are pinned to PHP 8.4 or PostgreSQL 16.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Relaticle is aimed at: agents that cannot touch the CRM
Most CRMs expose an API that a human developer wires into an integration, one endpoint at a time. An AI agent working against that API needs a bespoke tool layer before it can do anything useful, and that layer has to be maintained as the CRM changes. Relaticle's answer is to ship the tool layer as part of the product. The README states the project includes a production-grade MCP server with 37 tools for CRM operations and analysis, and that any AI agent, Claude, GPT, or open-source models, can connect to it. The stated audience is developer-led teams, AI-forward startups, and SMBs who want agent integration without vendor lock-in. That framing matters: this is not a CRM for a sales team that wants to sign up and start typing. It is a CRM for a team that already runs servers and already has an agent in its workflow. The repository topics list attio-alternative alongside self-hosted, which tells you the comparison the maintainers expect you to make.
What the stack actually is, and what that commits you to
Relaticle is a PHP application. The README badges name Laravel 13.x, PHP 8.5, and Filament 5, with the interface described as built with Filament 5 and Livewire 4. Alpine is listed among the repository topics, so the front-end layer is the usual Livewire and Alpine pairing rather than a separate JavaScript application. The data store is PostgreSQL 17 or newer, and Redis is listed for queues but marked optional for development. The README also claims 2,000 or more automated tests and a tests workflow badge pointing at the main branch. That combination is conventional for a modern Laravel product, and it means the operational surface you inherit is a PHP web app, a Postgres database, a queue worker, and a Node build step. None of that is exotic, but none of it is invisible either. A team without PHP deployment experience is signing up for Composer, a queue daemon, and asset compilation.
The data model: 22 field types and no migrations
The README states Relaticle supports 22 field types, including entity relationships, conditional visibility, and per-field encryption, and that this requires no migrations. That last clause is the interesting claim. A CRM that lets an administrator add a field from the UI cannot run a schema migration for every field, so the implementation has to store custom field definitions and values in a shape that does not depend on altering tables. The README does not describe that storage design, and I cannot confirm it from the supplied material. What I can say is that the trade-off is real: schema-less custom fields make the application flexible for users and harder to query efficiently for developers. Per-field encryption adds a second constraint, because encrypted values cannot be indexed or sorted in the database the way plain columns can. If your team plans to report on custom fields at volume, that is the first thing to verify against a real dataset rather than the demo.
Multi-team isolation and the authorization claim
Relaticle describes multi-team isolation as five-layer authorization with team-scoped data and workspaces. The README gives the layer count but not the layers. For a self-hosted CRM holding customer records, that is the part of the documentation I would want expanded most. Five layers could mean anything from middleware plus policy plus query scope plus resource gate plus model observer, and the security properties differ enormously depending on which. The claim that data is team-scoped is testable: create two teams, add a record to one, and attempt to reach it from a session in the other through the UI, the REST API, and an MCP tool call. Those are three separate entry points, and an authorization bug in any one of them exposes records. The README asserts the property without describing the mechanism, so treat the assertion as a starting point for your own checks.
Getting it running: the commands the README gives
The installation path in the README is two commands. Clone the repository, then run the Composer install task:
git clone https://github.com/Relaticle/relaticle.git cd relaticle && composer app-install
For development, the README lists three Composer scripts: composer dev starts the server, queue, and Vite together; composer test runs the test suite; composer lint formats code. Requirements are stated as PHP 8.5 or newer, PostgreSQL 17 or newer, Composer 2 and Node.js 22 or newer, with Redis optional for development. Self-hosting is not covered in the README beyond a pointer to the self-hosting guide at relaticle.com/docs/self-hosting, which the README says covers both Docker and manual deployment. The README does not give the environment variable names, the database setup steps, or the MCP server connection details. Those live in the external documentation, and I have not read it. If your deployment target is a managed PHP host, check the PHP and PostgreSQL version ceilings before you clone anything, because 8.5 and 17 are both recent floors.
Where Relaticle is the wrong tool
The version requirements are the clearest limitation. PHP 8.5 and PostgreSQL 17 are not what most shared hosts or long-lived internal platforms run, and the README sets them as minimums rather than recommendations. A team on PHP 8.3 with PostgreSQL 15 faces an upgrade before the first commit. The second limitation is the AGPL-3.0 licence. Relaticle is offered as open-source software under that licence, and the README's privacy pitch is that your data stays on your server. AGPL-3.0 carries network-copyleft obligations, which is a meaningful consideration for anyone planning to offer Relaticle as a hosted service to third parties. I am not a lawyer and this is not legal advice; the point is that the licence choice interacts with the business model in a way the README does not discuss. The third limitation is scope. Relaticle ships English-only in the main repository. The README says the codebase is i18n-ready and that self-host forks can drop a lang/<locale>/ directory in place, with docs/i18n.md covering the override workflow and CI guardrails. So translation is a fork-level activity, not a configuration toggle, and translated strings will need to be reapplied on upgrade.
How it differs from a hosted CRM with an API
The obvious alternative is a hosted CRM that offers an API and an official MCP endpoint, of which several exist. The difference is not features, it is where the data and the tool definitions live. With a hosted CRM, the vendor operates the database, decides which tools the agent can call, and can change that surface on its own schedule. Relaticle inverts this: the MCP server ships in the repository, the agent connects to your instance, and the tool list is something you can read in the code and modify. That is the vendor lock-in argument the README makes, and it holds up as a description of the architecture. The cost is that you now operate the thing the vendor used to operate. Backups, upgrades, queue health, and Postgres tuning become your problem. The README's release history suggests an active cadence: v3.5.5, v3.5.6, and v3.5.7 all landed within a six-day window in late August and early September 2026. Frequent patch releases are good for fixes and bad for operators who upgrade manually, so a self-hosted deployment needs a repeatable upgrade procedure from day one.
Maintenance cost and the licence you accept on clone
Three things drive ongoing cost here. The first is the release cadence, which the release list shows as patch-level and frequent. The second is the dependency chain: Laravel 13, Filament 5, Livewire 4, PHP 8.5, PostgreSQL 17, Node 22. Each of those moves on its own schedule, and a self-hosted instance inherits every upgrade decision. The third is the i18n arrangement, where translations live in a fork-level lang directory and must be reapplied as upstream strings change. On licensing, the repository is AGPL-3.0, which is a strong copyleft licence with a network clause. If you run a modified Relaticle as a service that other people interact with over a network, the licence's source-availability condition is likely to apply to your modifications. If you run it internally for your own team, the practical effect is different. Consult your own counsel before building a commercial offering on this codebase; the README states the licence identifier and nothing more.
Editorial conclusion
Adopt Relaticle if you run your own infrastructure and want an agent to work the CRM through MCP rather than through a vendor's closed API. Do not adopt it if you need a hosted product with no ops burden, or if your servers are pinned to PHP 8.4 or PostgreSQL 16. Before committing, read the self-hosting guide and the MCP documentation at relaticle.com/docs, and confirm which of the 37 tools are read-only, because the README describes full CRUD over the REST API without listing per-tool permissions.
Community notes