Relaticle: a self-hosted CRM with an MCP server for AI agents

What Relaticle solves for developer-led sales teams

Most CRM products assume a human is the only client. Records are entered by hand, integrations are bolted on through partner marketplaces, and an AI assistant is a feature inside the vendor's product rather than something you can point your own agent at. Relaticle takes the opposite position: the CRM is the system of record, and an agent is a first-class caller. The README describes it as a self-hosted CRM with a production-grade MCP server, and lists 37 tools for CRM operations and analysis, alongside a REST API with full CRUD, schema access, activity history, and pipeline analysis.

The audience is stated plainly in the README: developer-led teams, AI-forward startups, and SMBs who want agent integration without vendor lock-in. That is a narrower group than a general CRM buyer. If nobody on your team is comfortable running a PHP application and a PostgreSQL database, the value proposition does not reach you. If someone is, the trade is straightforward: you operate the server, and in exchange your data stays on your infrastructure and any MCP-capable client can act on it.

The MCP server and REST API as the integration surface

The mechanism is two parallel interfaces over the same data. The MCP server exposes 37 tools, which is how an agent such as Claude or a GPT-based client discovers what it can do: list companies, read contacts, inspect a pipeline, and so on. The REST API exposes the same domain with full CRUD plus schema access, activity history, and pipeline analysis. Anything an agent can reach through MCP is also reachable by ordinary HTTP code, which matters because it means you are not locked into one agent vendor to get programmatic access.

The data model is the other half. Relaticle advertises 22 field types, including entity relationships, conditional visibility, and per-field encryption, and the README claims no migrations are needed to use them. That is the interesting design decision. In a conventional Laravel application, a new field on a CRM entity means a migration, a deploy, and a schema change. Relaticle treats custom fields as data, so a team can reshape the CRM from the interface or through the API without a release cycle. The cost is that the schema an agent sees is partly runtime data, and per-field encryption means some values are not readable in the database without the application's key.

Authorization is layered. The README describes multi-team isolation as five-layer authorization with team-scoped data and workspaces. The practical consequence is that an MCP tool call is not a superuser backdoor: it runs inside the same team scoping as the web interface, so an agent connected to one workspace should not see another's records.

Installing Relaticle with composer app-install

The README gives a two-command install for a local checkout. You need PHP 8.5 or newer, PostgreSQL 17 or newer, Composer 2, and Node.js 22 or newer. Redis is listed as optional for development, which matches the compose file, where Redis backs the cache, session, and queue stores in production.

git clone https://github.com/Relaticle/relaticle.git
cd relaticle && composer app-install

The clone brings the repository down and composer app-install performs the application setup. The README does not spell out what that script does step by step, so read composer.json before running it if you care about which migrations and seeders execute. For day-to-day work there are three composer scripts: composer dev starts the server, queue worker, and Vite together; composer test runs the suite; composer lint formats code.

composer dev

After composer dev, the README's screenshot shows the CRM panel with an AI assistant, chat history, and open tasks on the home view. By default the panel is served at the /app path, and the .env.example notes that setting APP_PANEL_DOMAIN switches it to subdomain routing.

For a server rather than a laptop, the repository ships a compose.yml that runs the published image. It requires APP_KEY and DB_PASSWORD to be set, and will refuse to start without them.

services:
  app:
    image: ghcr.io/relaticle/relaticle:latest
    ports:
      - "${APP_PORT:-80}:8080"
    environment:
      APP_KEY: ${APP_KEY:?APP_KEY is required}
      DB_PASSWORD: ${DB_PASSWORD:?DB_PASSWORD is required}
      DB_CONNECTION: pgsql
      DB_HOST: postgres
      DB_PORT: 5432

The file also enables AUTORUN_LARAVEL_MIGRATION, so migrations run on container start, and defines a healthcheck against http://localhost:8080/up. The README points to a self-hosting guide for Docker and manual deployment rather than repeating the steps.

Where Relaticle gets awkward

The install path assumes a modern toolchain and does not negotiate. PHP 8.5 and PostgreSQL 17 are both recent, and a team running PostgreSQL 15 or PHP 8.3 will be upgrading infrastructure before they see a single contact record. There is no documented fallback for older versions, and the README does not describe a supported matrix beyond the minimums.

The English-only default is a real constraint, not a footnote. The README says the main repository ships English-only and that self-host forks can drop a lang/<locale>/ directory in place to translate the app, with docs/i18n.md covering the override workflow and CI guardrails. So translation is possible but it is your fork's job. A team with non-English-speaking sales staff should budget for that work before rollout.

The compose file's environment list is long and mostly unset by default: MAIL_MAILER defaults to log, which means email is written to logs rather than delivered until you configure a mailer. REQUIRE_EMAIL_VERIFICATION defaults to true, so new accounts must verify before they are useful. Neither is wrong, but both are things you discover during setup rather than from the README.

Finally, the documentation for the MCP endpoint is off-repository. The README links to relaticle.com/docs/mcp rather than describing the transport, authentication, or tool naming in the repository itself. If that site is unreachable to you, you are reading source code to learn the interface.

Relaticle compared with Krayin CRM

Krayin CRM is the closest comparison in the same ecosystem: a Laravel-based open-source CRM. The difference is not the framework, it is what the project treats as the primary client. Krayin is a conventional web CRM with an admin panel and extension packages; the interface is the product, and programmatic access is a secondary concern.

Relaticle inverts that. The MCP server with 37 tools and the REST API with full CRUD are described in the README as core strengths, not add-ons, and the field system is built so that records can be reshaped at runtime through 22 field types without migrations. That makes Relaticle a better fit when the thing consuming the CRM is an agent or a script, and Krayin a better fit when the thing consuming it is a salesperson in a browser and you want an established extension ecosystem.

The licence distinction is worth checking on both sides before you commit. Relaticle is AGPL-3.0, which reaches network users of modified versions.

Maintenance, upgrades and the AGPL-3.0 licence

The project is not archived and the last push was on 2026-09-10, with releases v3.5.5, v3.5.6 and v3.5.7 landing between 2026-08-31 and 2026-09-06. That is a fast release cadence on the 3.5 line, which cuts both ways: fixes arrive quickly, and so does the upgrade surface. The README advertises 2,000+ automated tests and the repository carries phpunit.xml, phpunit.ci.xml, phpstan.neon, pint.json and rector.php, so the tooling for a disciplined upgrade exists in-tree. Running composer test before and after an upgrade is the obvious check, and composer lint plus the Rector and PHPStan configs give you static analysis to catch breakage the tests miss.

On the container path, upgrades are pulls of ghcr.io/relaticle/relaticle:latest. Because AUTORUN_LARAVEL_MIGRATION is enabled, migrations run when the container starts, which means a rollback story is not documented in the README or the compose file. The README does not document rollback. Take a database backup before pulling a new image, since that is the only recovery path the material describes.

Licensing: Relaticle is AGPL-3.0. For internal self-hosting, the obligation is mostly about preserving notices and offering source to users who interact with the software over a network. If you modify Relaticle and let customers use it as a service, the AGPL's network clause is the part to read carefully. This is a description of the licence, not legal advice; get counsel for your distribution model.

Editorial conclusion

Adopt Relaticle if your team already runs PHP or Docker infrastructure and wants agents to work against CRM data through MCP rather than a closed integration. Skip it if you need a hosted product with no server to run, or if AGPL-3.0 does not fit how you distribute software. Before committing, verify that your PostgreSQL is version 17 or newer, that PHP is 8.5 or newer, and that your MCP client can reach the endpoint you configure through MCP_ALLOWED_ORIGINS.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. relaticle/relaticle on GitHub
5. Releases