In this article, you going to see a discussion regarding Magento 2.4 system requirements. You going to see all the requirements in Magento in detail step by step.
It is the beta release information of Magento 2.4.
The content may be going to change regarding code base and functionality base till Magento 2.4 is get officially released.
In Magento 2.4, system requirements include many point or many software to run base Magento application which supported web browser and also latest requirements to securely connect repository and PayPal.
Let’s start with Magento 2.4 system requirements
We going to check below points in more detail
- Magento technology stack requirements
- Supported browsers
- TLS requirement for repo.magento.com
- TLS 1.2 requirement for PayPal
Magento technology stack requirements
Linux disseminations, for example, RedHat Enterprise Linux (RHEL), CentOS, Ubuntu, Debian, and comparative. Magento isn’t upheld on:
- Windows Operating System
- Mac Operating System.
Redesigning or Upgrade the Magento applications and augmentations you get from Magento Marketplaces and different sources can require up to 2GB of RAM.
In the event that you are utilizing a framework with under 2GB of RAM, we suggest you make a trade document; in any case, your redesign may fall flat.
In case of Composer the main important thing is required for engineers/developer who wish to add to the Magento 2 codebase or any individual who wishes to create Magento expansions.
- Apache 2.4
- nginx 1.x
What’s more, you should empower the Apache mod_rewrite and mod_version modules.
The mod_rewrite module empowers the server to perform URL revamping.
The mod_version module gives adaptable variant checking to various httpd renditions.
For more data, you can check Apache documentation.
- MySQL 8.0 for on-premise installations
- MariaDB 10.4 for Magento Commerce Cloud projects
Magento 2.4.0 can be introduced with 7.3, yet it isn’t tried or suggested.
It is expected for overhauling from Magento 2.3.x to Magento 2.4.0.
Require PHP extensions
We unequivocally suggest you confirm that PHP OPcache is empowered for execution reasons.
The OPcache is empowered in numerous PHP dispersions.
To check on the off chance that it is introduced, you can check PHP documentation.
We suggest specific PHP arrangement settings, for example, memory_limit, that can stay away from regular issues when utilizing Magento.
As of Magento 2.4.0, MySQL is not, at this point utilized for search.
You should utilize Elasticsearch. Magento bolsters Elasticsearch 7.6.x.
- A valid security certificate is required for HTTPS.
- Self-signed SSL certificates are not supported.
Required system dependencies
- Mail Transfer Agent (MTA) or an SMTP server
Technologies Magento can use
- Redis ver 5.0 is suggested and utilized in testing for page cache and meeting stockpiling
- Varnish ver 6.x (tried with 6.3.1)
- RabbitMQ 3.8.x
RabbitMQ can be utilized to distribute messages to line and to characterize the purchasers that get the messages non-concurrently.
Next Step for Magento 2.4 system requirements
For more detail Magento system requirement you can check with link
- Microsoft Edge, latest–1
- Firefox latest, latest–1 (any os)
- Chrome latest, latest–1 (any os)
- latest Safari, latest–1 (Mac OS only)
- Mobile Safari for iPad 2, iPad Mini, iPad with Retina Display (iOS 12 or later), for desktop storefront
- Next Safari Mobile for iPhone 6 or later; iOS 12 or later, for mobile storefront
- Chrome for mobile latest–1 (Android 4 or later) for mobile storefront
TLS requirement for repo.magento.com
The Magento software and segment archive, repo.magento.com, as of late began requiring Transport Layer Security (TLS) 1.1 or later.
On the off chance that you have a previous variant of TLS, you’ll see the mistakes talked about in this area.
Downloading a Magento metapackage
The accompanying mistake shows on the off chance that you endeavor to run writer make undertaking to get a Magento meta-package:
The "https://repo.magento.com/packages.json" file could not be downloaded: Failed to enable crypto
failed to open stream: operation failed
The answer for this issue relies upon how your working framework bundles TLS.
See one of the accompanying segments for more data:
- Mac OS
Ensure you’re utilizing libcurl. libcurl adaptations 7.34 or later; these renditions use TLS 1.2 as a matter of course.
To decide your libcurl adaptation, enter the accompanying order:
$ curl --version
The wellspring of the issue is that the libcurl library bundled with CentOS 6.6 and prior use TLS 1.1 or prior as a matter of course.
To decide the form of CentOS your server runs, enter the accompanying order:
$ cat /etc/release
In case you’re as of now running CentOS 6.8 or later, no activity is vital.
As indicated by the CentOS 6.8 changelog, “different applications presently bolster TLS 1.2, for example OpenLDAP, yum, stunnel, vsftpd, git, postfix and others.
Additionally TLS 1.2 has been empowered of course in different bundles”.
(CentOS 7 has a more current variant of libcurl that additionally defaults to TLS 1.2.)
Ongoing updates to the OS X liip bundle should resolve the issue.
TLS 1.2 requirement for PayPal
PayPal as of late reported they will require Transport Layer Security (TLS) ver 1.2 to process installments in a live situation. (PayPal as of now requires TLS 1.2 in the sandbox.)
For more information you can check with.
- Details (PayPal security bulletin)
- PayPal live payments switching in June 2016 (PayPal technical blog)
As per PayPal, indications of the issue remember the accompanying messages for your blunder log:
Unknown SSL protocol error in connection to api-3t.sandbox.paypal.com:-9824
140062736746144:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337: … (more messages) … New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported* Compression: NONE Expansion: NONE SSL-Session: Protocol: SSLv3* … (more messages) …
The main source of the issue is your ver of libcurl. libcurl forms sooner than 7.34 use TLS 1.1 or prior of course.
To decide the ver of libcurl you’re running, enter the accompanying order on the server that forms PayPal exchanges:
$ curl --version
The wellspring of the issue is that the libcurl library bundled with CentOS 6.6 and prior use TLS 1.1 or prior of course.
To decide the rendition of CentOS your server runs, enter the accompanying order:
$ curl --version
In case you’re as of now running CentOS 6.8 or later, no activity is fundamental. As per the CentOS 6.8 changelog, “different applications currently bolster TLS 1.2, for example OpenLDAP, yum, stunnel, vsftpd, git, postfix and others. Additionally TLS 1.2 has been empowered as a matter of course in different bundles”.
(CentOS 7 has a more up to date form of libcurl that likewise defaults to TLS 1.2.)