Manticore — installation and connection

Starting with 0.1.33, Search engine offers MySQL — built in and Manticore + MySQL. Updating preserves the selected engine. Version 0.1.34 adds an explicit installation button; opening the page or updating the module does not start installation.

Manticore selects candidates. The module uses MySQL to verify field matching, ranking and permissions. The primary index remains required. Leading zeros, synonyms, partial matching and keyboard-layout correction retain their existing behavior. This integration does not enable Manticore morphology or typo correction.

These instructions apply to 1.0.1. Use the 1.x update instructions; Zorka’s Updates tab is no longer present. Installing Manticore remains a separate button action.

Requirements

Install zorka.search 0.1.33 or later and build its index; administration-driven Manticore installation requires 0.1.34. See module installation. For installation from administration, PHP needs Linux x86_64, cURL/zlib/POSIX, proc_open, access to /proc, and a writable executable directory. PHP must run as a non-root user. Installing a system service requires server administration access.

The integration was tested with Manticore 29.9.0 on Ubuntu 24.04, and administration-driven installation was tested on BitrixVM 9.0.9 / AlmaLinux 9.7. Test other combinations in your environment. PHP must reach its HTTP API. Use a separate table for every Bitrix installation; the module suggests a name beginning with zs_.

Allow additional disk space and RAM for Manticore. Requirements depend on the amount and length of searchable values. Earlier experimental benchmarks used a different index schema and are not capacity estimates for this integration.

Bitrix multisite mode

Multiple sites (SITE_ID) in one Bitrix installation share a single Manticore table. Full search and suggestions retain current-site, information-block binding and permission filters. Shared catalogs appear on their assigned sites with the appropriate URLs. Products added from matching sections pass the same checks.

Engine, field and synonym settings are shared by the installation. Version 1.0.1 does not provide independent settings per SITE_ID. CRM follows the provider's selected catalog and user permissions, rather than implicitly filtering by a storefront site.

Separate Bitrix installations need different tables, even when using one Manticore server. Independent databases can reuse internal document IDs. The UI label “table for this site” means the installation, not an individual SITE_ID.

Tested with two sites sharing one database, separate/shared/private catalogs, full search, suggestions, site URLs and section-product expansion, on Bitrix search modules 24.0.0 and 25.200.0.

Install from Bitrix administration without root — 0.1.34

In Search engine → Manticore on this server, select Install and enable. The module checks the environment and storage directory, downloads pinned Manticore 29.9.0 over HTTPS, verifies SHA-256 for both the package and extracted binary, starts it as the PHP user, saves the connection and prepares the index. It does not run sudo, Docker, package managers or package installation scripts. Outbound HTTPS to repo.manticoresearch.com and compatible system libraries are required. Buddy is not started.

Package selection covers x86_64 Debian 11–13, Ubuntu 22.04/24.04 and AlmaLinux/Rocky/RHEL/CentOS 8–9. This is not a guarantee for every host: noexec, open_basedir, disabled functions, missing libraries or restrictions on background processes may prevent installation. The binary is tested before enabling search.

Downloads use 1 MiB steps. If the tab closes or a request fails, select the same button to continue. An already prepared index is not rebuilt unnecessarily. Installation requires at least 192 MiB of free space, plus space for the index. Each installation gets its own directory and an available loopback port, retained for subsequent starts. A loopback port does not isolate other users on the server; this mode assumes a trusted server environment.

Verified on BitrixVM

On October 9, 2026, this package passed installation through a real Bitrix administration interface on BitrixVM 9.0.9, AlmaLinux 9.7, PHP 8.2.30. Checks covered storefront and CRM search, stopping/starting Manticore, MySQL fallback, cron recovery after a VM reboot, uninstall and reinstall with preserved data. Manticore storage was outside the public document root; the process ran as bitrix and its HTTP API listened on loopback only.

The tested image had cURL and POSIX installed but disabled in PHP. The module blocked installation until a server administrator enabled them in the PHP environment serving the site and restarted Apache. Manticore installation then ran from administration as bitrix, without root, sudo or Docker. Check the site's PHP environment: CLI extensions may differ. The module does not enable server extensions automatically.

The test used 7 synthetic products and 1 section. It validates functionality in one environment, not load capacity or compatibility with every hosting provider. Interrupted initial downloads and storage inside the document root were not exercised in this run.

Storage and access checks

The module tries the site's parent directory and the PHP user's home first, then upload and the site root. It creates a random private subdirectory with mode 0700. Before the first installation, you may specify another existing parent directory. Storage stays outside the module directory and survives module updates.

For storage inside the document root, the module writes Apache/IIS deny rules and checks actual HTTP access without cookies or authentication. A public control file must return the exact random content; private test files of different types and existing service files must return 403/404. Checks cover the current origin and active site addresses declared in Bitrix, using the current origin's scheme. Redirects, timeouts, generic 404 responses, login pages and ambiguous results are rejected. Probe files are removed afterwards.

Nginx ignores .htaccess. If files are accessible, installation stops. Configure a deny rule for the entire directory or select storage outside the document root. The module cannot change Nginx configuration itself.

These checks measure access through known URLs at a particular time. They cannot cover undeclared aliases, alternate virtual hosts or future configuration changes. Declare all public site addresses; prefer an isolated system service for untrusted shared hosting.

Protection is checked before downloading, extraction and startup, and by the agent/cron watchdog. A failed check stops the owned process, disables automatic restart and falls back to MySQL. For storage inside the site, search also uses MySQL if the last successful check is more than five minutes old. There remains an interval between a server configuration change and the next check.

Controls and recovery

Start, Stop, Check protection, Refresh status and Logs affect only the module-owned instance. Before stopping, the module checks its PID, executable, configuration argument and OS user. It does not change another service or port. Modified binaries or configuration files cannot be started. Stopping preserves data.

If the PHP user can use crontab, the module adds its own zorka.search manticore block with a check every minute, retaining existing jobs. Otherwise the interface reports the limitation and a Bitrix agent performs checks. Visit-driven agents require traffic to restore the process after reboot; independent recovery requires cron. A manual stop disables automatic restart.

Uninstalling the module stops its owned process and removes its cron block, but preserves the binary, configuration, logs and index. A cron removal failure is reported. Logs are stored in the log subdirectory; the interface displays the last 8 KiB per file. Maintain log rotation and free space according to your server policy.

Docker

On a server with Docker installed:

docker run -d --name zorka-manticore --restart unless-stopped \
  -p 127.0.0.1:9308:9308 \
  -v zorka-manticore-data:/var/lib/manticore \
  manticoresearch/manticore:29.9.0
curl http://127.0.0.1:9308/cli -d 'SHOW TABLES'

The named volume keeps data across container restarts. The published port is accessible only from the host, following the Manticore Docker guidance.

If PHP itself runs in a container, its 127.0.0.1 points to that container. Connect the services through a private Docker network and use the Manticore service name, for example http://manticore:9308.

OS packages and BitrixVM

These commands are for a new dedicated service. Do not replace the configuration of an existing Manticore service used by other projects. Check /etc/os-release and select packages for the actual OS, including on BitrixVM. Confirm distribution support in the official installation guide.

For a supported RPM-based system:

sudo dnf install https://repo.manticoresearch.com/manticore-repo.noarch.rpm
sudo systemctl mask manticore.service
sudo dnf install manticore

For Debian or Ubuntu:

wget https://repo.manticoresearch.com/manticore-repo.noarch.deb
sudo apt install ./manticore-repo.noarch.deb
sudo apt update
sudo systemctl mask manticore.service
sudo apt install manticore

The temporary mask prevents automatic startup before binding the service to a private address. Package commands install the current stable release; verify versions before upgrading an existing service.

For this new service, use /etc/manticoresearch/manticore.conf:

searchd {
    listen = 127.0.0.1:9308:http
    log = /var/log/manticore/searchd.log
    pid_file = /run/manticore/searchd.pid
    data_dir = /var/lib/manticore
}

Start and verify:

sudo systemctl unmask manticore.service
sudo systemctl enable --now manticore
sudo systemctl status manticore --no-pager
curl http://127.0.0.1:9308/cli -d 'SHOW TABLES'

If startup fails, inspect journalctl -u manticore -n 100 --no-pager and the service user's access to its data and log directories. Service installation needs administrative privileges; BitrixVM module jobs run as bitrix.

Connect in the module

1. Open zorka.search → Search engine.
2. Select Manticore + MySQL, enter http://127.0.0.1:9308 and a table name unique to this Bitrix installation.
3. Click Save engine, then Check connection. The check uses saved settings. The general save button for other tabs does not change the engine connection.
4. Click Prepare Manticore index. The module creates its RT table and copies the existing module index. Searches use MySQL until preparation finishes.
5. Wait for the ready status, then verify known products and sections in full search and suggestions.

Use Continue synchronization after an interrupted browser session. Changing the endpoint or table requires preparation again. After enabling new fields, rebuild the primary module index first: preparing Manticore cannot recover values absent from that index.

Never expose port 9308 to the internet. For a remote service, use a private network and a firewall allowing only the website server. This version does not support HTTP proxy credentials in the connection form. A successful root curl does not prove PHP connectivity; use the module's connection check.

Synchronization and cron

Products and sections enter the normal module queue and then the Manticore delivery queue. A Bitrix agent delivers changes; verify execution if agents run through cron. Pending changes are included through MySQL, and delivery failures retain the queue.

To prepare a large existing index from CLI:

sudo -u bitrix /usr/bin/php /home/bitrix/www/bitrix/modules/zorka.search/tools/manticore.php \
  /home/bitrix/www --prepare --max-time=0

Adjust the site root and PHP executable. Save and select Manticore in the admin panel first. --prepare queues the existing primary index; --max-time=0 removes the time budget between batches. Run without --prepare to resume delivery.

Optional delivery every minute, in the bitrix user's crontab (sudo -u bitrix crontab -e):

* * * * * /usr/bin/php /home/bitrix/www/bitrix/modules/zorka.search/tools/manticore.php /home/bitrix/www --max-time=45 >> /home/bitrix/zorka-manticore.log 2>&1

Configure log rotation. This only delivers to Manticore; it does not replace catalog indexing or the normal module cron job. A lock prevents overlapping synchronization batches.

Failure, rollback and removal

Unavailable or unprepared Manticore automatically falls back to MySQL. Following a connection failure, search skips retries for 15 seconds. Queries exceeding 5000 candidates also use the full MySQL path; the threshold never truncates search results. Performance therefore depends on the query and the remaining Bitrix page work.

The engine tab shows pending deliveries and the latest error. If the table is lost, restore the service and select Prepare Manticore index. Do not edit its data manually.

To switch back, select MySQL — built in and Save engine. No reindex is needed. Uninstalling the module preserves the external service and table; remove them separately only after confirming they are unused. After uninstalling the module itself, rebuild the standard Bitrix search index as described under removal.

Experimental index measurements

On October 7, 2026, module 0.1.32 SQL was compared with a separate experimental Manticore index using identical synthetic titles and SKUs. The server had 2 vCPU and 4 GiB RAM, with MySQL 8.0.46, PHP 8.3 and Manticore 29.9.0. Each case used 3 warmups and 30 measured queries returning the first 20 IDs; p50 is the median.

Query, 70,000 documents	MySQL p50, ms	Manticore p50, ms
SKU, title in word mode	58.165	1.047
Two words, narrow result	87.005	1.238
Frequent word	95.133	5.680
SKU, title in partial mode	149.335	1.085
Title fragment	165.164	5.690
Two title fragments	205.602	1.425
Fragment with no results	148.623	1.079

All matching IDs and their order agreed in 14 cases across 10,000 and 70,000 documents. At 10,000 documents, medians were 7–31 ms and 0.5–1.1 ms respectively. Measurements were sequential with warm data, excluding permissions, CRM, synonyms, Bitrix bootstrap and concurrent visitors.

These are not performance measurements of Manticore + MySQL in 0.1.33–0.1.34. The integrated engine uses a different candidate schema and mandatory SQL verification; queries exceeding 5,000 candidates use MySQL. Prototype speedup ratios are not promises for the integrated version or the whole page.