Skip over navigation
You are currently viewing documentation for a previously released version of OroCRM. See the latest long-term support version.

System Requirements

OroCRM is a web application which runs on a server. Users interact with the application via a web browser on any computer or mobile device that have access to the internet or the network where the server is hosted.

Server-side Requirements


Resources configuration depends on the data size and number of active users and integrations. Typical setup could be done on a single server with minimum 2 CPU cores, 2GB RAM and a fast hard drive (SSD is recommended). The application could scale to multiple servers and a separate database server based on the expected load.

Operating Systems

Linux distributions (RedHat, Ubuntu, Debian, CentOS) are recommended for the production setup. Windows 7 and above and Mac OS X can be used for the development environment.


Oro applications are compatible with most web servers with PHP support, but we recommend the following configuration:

Web Server
  • Apache 2.2.x or 2.4.x
  • Nginx (latest mainline or stable version)

Web server configuration recommendations are well described in Symfony documentation

  • PHP 5.6 and above
  • PHP CLI, the same version as for the web server
PHP Settings

Few updates to default PHP configuration settings should be done in php.ini for the web server and CLI:

  • date.timezone must be set
  • detect_unicode must be disabled
  • memory_limit should be 512M or above

If you have xdebug installed:

  • xdebug.scream must be disabled
  • xdebug.show_exception_trace must be disabled
PHP Extensions
  • ctype
  • curl
  • fileinfo
  • gd
  • intl
  • json
  • mbstring
  • mcrypt
  • mysql
  • tokenizer
  • xml
  • zip


Latest version of mariaDB may be used at one’s own risk. Oro applications are not tested with mariaDB and thus the correct operation cannot be guaranteed.

Process Control

MySQL Optimization

If you are using an HDD instead of an SSD, please pay attention to the following configuration settings:

innodb_file_per_table = 0
wait_timeout = 28800

More optimization recommendations could be found in MySQL official documentation. See [Optimizing InnoDB Disk I/O][2] for more information.

MySQL Collate and Charset

The default MySQL character set utf8 uses a maximum of three bytes per character and contains only BMP characters. The utf8mb4 character set uses a maximum of four bytes per character and supports supplemental characters (e.g. emojis). It is recommended to use utf8mb4 character set.

Using utf8mb4 might have side effects. MySQL indexes have the default limit of 767 bytes, so any indexed fields with varchar(255) will fail when inserted, because utf8mb4 can have 4 bytes per character (255 * 4 = 1020 bytes), thus the longest data can be 191 (191 * 4 = 764 < 767). To be able to use any 4 byte charset, all indexed varchars should be at most varchar(191). To overcome index size issue, the server can be configured to have a large index size by enabling sysvar_innodb_large_prefix. However, innodb_large_prefix requires some additional settings to work:

  • innodb_default_row_format=DYNAMIC (you may also enable it per connection as in the config above)
  • innodb_file_format=Barracuda
  • innodb_file_per_table=1 (see above performance issues with this setting)

More details about switching to utf8mb4 are available online.

Enterprise Edition Software

Enterprise edition is built to support better scale and performance. It is compatible with additional software configuration that allows to achieve these goals.

PHP Extensions
  • pgsql
Search Index
Job Queue
  • RabbitMQ 3.5.8 and above, with Erlang/OTP version 18.0 and higher. RabbitMQ 3.6.x is recommended

PostgreSQL Configuration

PostgreSQL uuid-ossp extension should be loaded for proper doctrine’s guid type handling. In order to enable it, connect to the database server and run sql query:


Optional recommendations

  • Git is the recommended version control system and could be used for application source code management
  • Node.js could be used for more efficient JS assets minification
  • Xdebug could be used as the debugger tool but it is recommended only in the development environment
    • xdebug.max_nesting_level above 100 should be used
  • Tidy PHP extension should be installed to make sure that HTML is correctly converted into a text representation
  • Redis – could be used for more efficient application caching. Supported versions of Redis from 2.0 to 3.2

Client-side Requirements

On the client side, Oro applications could be used with most of the graphical browsers on any operating system. Recommended and supported browsers:


Any browser you use needs to have cookies and JavaScript turned on.

Browse maintained versions:
Back to top