Search Results - nginx

Nginx as a load balancer for Magento

Introduction

During seasonal peaks or as traffic grows, there will be a need to add multiple app servers to your Magento store. A load balancer for Magento becomes essential. We have found that using nginx as a load balancer gives acceptable performance. We have not found many instances where we would recommend a hardware load balancer. Recent tests by nginx confirms this.

We would recommend a different load balancer only for additional features such as autoscaling.

Nginx as a load balancer offers many advantages including

  • uneven upsream servers as nginx can assign weights to each load balancer
  • self healing – takes a upstream server out of a cluster if it stops responding
  • path based load balancing
  • combination of path based and weight based load balancing
  • php upstream servers
  • SSL/TLS termination

This article assumes the process of adding a new app server to a Magento cluster is well understood. Here the focus is on the nginx configuration.

Load Balancer for Magento : Basic architecture

(more…)

Nginx or Apache : Best server for Magento

Introduction

Apache server has been for years been the default http server linux hosts use. However, recently there have been many newer “lighter” http servers. This blog article focuses on Magento hosting. Magento is a php based web eCommerce framework. Nginx requires php-fpm to process php requests. So, this comparison is really apache vs nginx + php-fpm. Apache offers MPM (Multi-Processing Module) configurations pre-fork, worker and event. In this discussion we will use the “event” MPM.
This discussion is very popular. Examples include this. We focus on Magento here.

Key Differences between apache and nginx

There are some differences architecturally that make nginx look slightly better for Magento hosting.
(more…)

How we hosted a big sale on Magento without a hitch

During an online sale that includes promotion to a list, brands worry about downtime due to “unexpected high load”. We believe that while every system has a rated limit, there can be flexibility added to your infrastructure. With some planning, including autoscale and tuning, a successful sale event can be a very likely outcome. See how we handled one such sale without a hitch.

In our experience promotions via SMS generates very high peaks. In this article we will show our recent experience with a sale day that generated a peak of 30 hits per second to Magento.

The sale

On Saturday 21st March, 2020 one of our customers had a sale event. The merchant – a fashion retail brand – is an omni channel retailer in India with about 145 stores across 45 cities. There have been previous sale events, but this one was different as most stores were closed due to the corona virus measures in place. This meant that more customers were likely to shop online than visit the store.

The sale was promoted via sms and email. The SMS list was about 1 million. Promotional messages were sent in batches of 200k every half hour. Marketing was to start at 10 AM local time.

Monitoring the website

We monitor the nginx log file, analyze and display information on our dashboard. A key component of our dashboard is the plot of number of hits / minute (we count only php hits, static hits like css, js and images are excluded). We also calculate avg response time per minute as well as standard deviation per minute. Both of these have a unit of seconds. We also have alerts setup for many parameters including slowdown and a 5xx error response.

The graph below is for a 24 hour period, including the sale time, which lasted about 5 hours with the effect keeping the site more busy than usual afterwards. Note these are server logs graphs – they look quite different from google analytics!

The traffic & response

The graph gives as an idea of the traffic to the website. The turquoise line is hits per minute served by php.

  • Traffic peaked a about 2000 hits per minute – about 30 hits per second.
  • 3476 items were added to cart during the sale.
  • Average server response was mostly below 1 second.
  • There were 3 errors – all of them related to checkout function (“This payment method is not available”)

Mysql query cache and response time

The store is a Magento 1 website. Just as the traffic / hits to the website started peaking, we got a slow alert – represented by the large black line close to the first traffic peak around 10.45 am in the previous figure. Our prior experience with the website showed that the mysql query cache plays a role in the site performance. Before the sale started, mysql query cache was turned off. On seeing the slowdown alert, we turned on the mysql query cache and saw an immediate improvement in performance. Both avg response per minute and standard deviation per minute improved – for some time.

However, standard deviation – higher number indicates some visitors faced slower response to the website than others – deteriorated with time. After the sale (10pm local time), mysql query cache was turned off – resulting in improved standard deviation, but slightly worse avg response time.

AWS autoscale

The following graph plots AWS autoscale instances over the same 24 hour period. A time based minimum 5 instances was planned during the sale from 9.15 AM to 7.30PM. At the peak 7 instances were required – our autoscale policy adds 2 instances and removes 1 at a time.

luroConnect Architecture for AWS and controls

Our standard scalable architecture uses nginx as a load balancer. The communication between the load balancer to php servers is using fcgi – individual php servers do not have nginx. A NFS server is used to share folders that need sharing – media and var folders in Magento 1. Magento cache and sessions are served from redis. Code is also shared using nfs.

A custom lambda function communicates between autoscale lifecycle hooks and the nginx load balancer adding and remove instances as the AWS autoscale policy decides.

Our cache controls including the ability to turn on and off mysql cache, resize memory allocated to redis cache, resize memory allocated to php-fpm opcache.

Interested in knowing about the advanced architecture of luroConnect?

Fill the form below and we will contact you.


My company owns the Magento site
Yes, I am a developer
I represent a Magento Agency

Reduce your cloud bill by upto 30%

Cloud costs more than anticipated

While cloud gives flexibility and scaling, cloud costs continue to put pressure on RoI (Return on Investment) calculations for eCommerce stores. Merchants migrating from physical hardware find the cloud costs especially high.

luroConnect recognizes that and offers to reduce cloud hosting bills by upto 30%, offering various strategies to do so.

luroConnect is cloud agnostic

luroConnect deploys on any cloud or physical hardware – as long as the platform is open, allowing RHEL compatible linux to be installed. This allows leveraging the best cost deal you can get from a cloud provider.

This allows our customers to select the best hosting or cloud service they prefer due to reasons like geography, discounts or commitment to a cloud provider.

Here are typical server size and cost for 3 major cloud services.

Provider –> Alibaba AWS GCP
Suggested use Server type Cost ($/month) Server type Cost ($/month) Server type Cost ($/month)
DB server ecs.g6.large (2×8) 47 m5.large (2×8) 74 n1-standard-2 (2×7.5) 60
App server ecs.c6.large (2×4) 39 c5.large (2×4) 62 2×4 custom 45

(Sample pricing as per respective portals)

luroConnect uses open source rather than cloud supported equivalents

All components required to host Magento open source and commerce, are open source. That includes nginx, apache, php, mysql, Redis, rabbit-mq and varnish. While cloud providers offer managed service around a open source or a open source compatible proprietary implementation, there is no need to use them.

luroConnect provides services on open source. Moreover, luroConnect is a “done-for-you” service – updates, configuration changes, etc are done by luroConnect keeping in mind performance and security of the website.

Example AWS pricing difference between RDS and luroConnect managed Percona mysql

Instance Disk size Provisioned IOPS Cost
($/month)
db.m5.large (2×8) 100GB 1500 347
m5.large (2×8) 100GB 1500 189

(Mumbai Region as per AWS simple monthly calculator)

luroConnect keeps up with technology to help reduce costs

luroConnect has the capability of building from open source – not just use what is available. This gives us the ability to keep up with technology, especially when it comes to more performant and / or cost saving to our customers.

A prime example of cost saving is use of AWS ARM (a1.large) processors for our nginx & varnish instances – the luroConnect/Edge. a1.large is 40% cheaper than c5.large with the same number of cores and memory.

AWS pricing for different instance types

Instance Processor Cost
($/month)
a1.large (2×4) AWS Graviton 38
c5.large (2×4) Intel 62
m5a.large (2×8) AMD 41

(Mumbai Region as per AWS simple monthly calculator)

As AWS releases Graviton2 ARM processors which are benchmarked by AWS to be upto 25% faster and yet 25% cheaper, luroConnect will release “luroConnect/Edge” and other components on the new AWS M6G, C6G and R6G instances.

luroConnect manages the infrastructure at the application level

Managing infrastructure is not your headache anymore – with luroConnect, your application is fully managed with proactive monitoring and 24×7 service. Features like our cloud control panel that allows you to run Magento indexing, deploy code and perform other activities that required to login to the production server, reduce your cost of running operations.

Conclusion

luroConnect’s investment in software and technology works for its merchant customers, improving RoI of their online business.

If you are interested in reducing your cloud costs like the one below, signup for a free consultation.

Many times, when your hosting service reports that you are running out of CPU or memory, they suggest you take a higher hosting plan. This results in designing for peak requirement. A large AWS instance 5x and above can almost always be tuned down with a scalable architecture. luroConnect’s inherent scalable architecture allows such cost reductions even without autoscale. For larger instances it makes sense to use autoscale.

luroConnect also believes in tuning caches – a key component to help reduce hosting costs. With our advanced tracking and healing, we continuously tune caches for optimal performance and hosting costs.

Free as in freedom, not free beer!

Introduction

The open source community has had this saying for long, though there are many, including myself, who do not understand what this difference means.

With recent changes to open source license agreements, this difference has come to the fore. For example, changes in the open source licensing of redis and mongodb has restricted how AWS and other cloud providers can conduct their business. Directly relevant to eCommerce merchants is the effect to open source Magento since Adobe’s acquisition of Magento and the path that has been followed

Magento Open Source vs Enterprise

Adobe’s business reason to have Magento is (in my opinion) to complete their offering. Adobe has seen a huge, public and successful transition from their traditional business of one-time purchase of packaged software to a subscription and even a SaaS model. With the acquisition of Magento and the Commerce Cloud licensing model, Adobe clearly thinks Magento should be packaged with hosting – hence the word Cloud in their offering and their pricing of the Enterprise license that includes cloud hosting. This transition is seen in SAP’s hybris commerce offering that includes hosting to make SAP Commerce Cloud. Unlike SAP hybris though, Magento is open source.

If you accept the Adobe Magento Commerce Cloud offering, you submit to the fixed set of features that are offered by their cloud or subscribe to a SaaS service for integration – though sometimes even that requires qualification or may not be possible.

For example, if you want PWA, you are limited and have to wait for the PWA Studio. If you want an improved search interface, you are limited to their choice. Similarly, for CDN, image optimization and Web Application Firewall, you are limited to Fastly, Adobe’s choice in the matter.

Or, perhaps, you use a plugin that is connected to a SaaS service.

When a Magento website is self-hosted though, the choice was to install a plugin or enhance the code that may require a service which has to be hosted. In the examples above, you may want to use vue-storefront or use one of many systems for search or use ImageMagick as an image optimization solution.

From Free Beer to Freedom!

The earlier licensing model of Magento pushed the decision to a “board level” – companies like ours always take the supported version. Mostly the open source version of Magento was attractive to those who were attracted by the “free beer”.

However, now the decision is that of freedom – since the paid version comes with restrictions.

If you feel guilty of being a taker of open source, you can sponsor community commits back to the open source Magento. The community participation is not negligible. Matt Asay of Adobe suggests it may be as high as 50% in this article.

(Indeed there are community participants who think Adobe is gaining from open source contributions, but that is a different blog article).

Shameless plug!

Full stack managed hosting support from luroConnect, gives you the benefit of supported opensource and the flexibility to build your own solution around it. The entire stack is based open source – from linux to Magento – including nginx, ModSecurity, redis, elasticsearch, sphinx and ofcourse mysql. (We relunctantly also allow ioncube encrypted plugins as well). Coupled with a release process from your git. Hosted on any cloud or open hosting providers – in the age of Uber you don’t need to own your data centers. Our multi-layered security approach and proactive monitoring comes standard. With additional features like a disaster recovery plan, image optimization, peep-hole maintenance and a dashboard to monitor and control key tasks such as code deployment or indexing, we bring peace-of-mind to Magento hosting. Check out our pricing and you can connect with us.

Magento Open Source vs Commerce Cloud

Magento Commerce Cloud does offer additional features. See alongside (zoom for a larger view) for a comparison taken from magento.com. Some key features like WYSIWYG editor will never be released in open source.

However, not everyone needs all of the features and some of these features are available from other plugin vendors or custom development from the many certified and non-certified agencies.

Infact, even if you are a Commerce Cloud customer, you will need customizations and potentially more plugins and even 3rdparty SaaS services to have a fully working store.

Conclusion

Magento Open Source is now a very viable option for all stores – brands and high volume stores included. With many options to customize and integrate, you have the freedom to make your own best of breed solution and not be restricted by the Adobe environment. With Managed hosting service you can get optimized and scalable websites.

Website Security (Magento & WordPress)

luroConnect’s approach to security is to take a holistic view. This leads us to a multi-layered security principle. Components of which are

  • Web Application Firewall – built into our nginx, WAF filters out traffic after examining its content. SQL and other injection can be best blocked here. However, WAF needs tuning on a per site basis – to reduce false positives. luroConnect includes custom rulesets tuned for each website by our WAF experts.
  • Rate limit and IP address blacklisting.
  • BOT blocker – filtered using the HTTP User Agent field.
  • Periodic admin user role and password change reminder
  • Blocking IP based on failed admin login attempts
  • Protecting admin login with HTTP password
  • File system security
  • Ensuring uploaded malware is never executed
  • Code deployment security

luroConnect understands a backup is useless until tested for restore. Our disaster recovery plan gives access to the disaster recovery server at all times. With a max of 20 minutes behind the live data and ability to scale up servers in 15 minutes should a need be, it is a must-have for all production servers. Read more about our DR Plan here.

We routinely blog about security in Magento and WordPress.

We can analyze your site for free

Schedule a call

Not happy with your website performance and want an expert to look at it?

  • We will analyze your site using public information.
  • We will ask you to give us a 1 day web server log file.
  • We will try to identify what steps if any you should take to improve your sites performance goals.

Website Scale (Magento & WordPress)

As campaigns and returning customers drive up website traffic, scale becomes important. Difference between understanding performance and scale is important and an analogy will help. While better performance is like a faster car, scale is like a better highway. On the cloud, it is easier to add lanes and remove them.

While AWS and other cloud auto scaling is huge win and almost a necessity for some websites, cold start issues – time it takes for new resources to be ready and available – make it one of many strategies.

luroConnect offers many strategies to scale, depending on the exact situation. To start with, the architecture allows many strategies to be applied. At the heart there is a path based load balancer – our nginx load balancer that can direct traffic to app servers based on URL.

Strategies include

Warm servers – useful if a campaign is known to drive traffic. A smaller warm server is kept standby to take additional traffic. These are with knowledge of campaigns to ensure expenses are kept in control.

Time based servers – for websites with high daytime admin usage, additional server is turned on to take admin traffic during working hours. Off hours admin traffic is served from the main app servers. This strategy can be applied to other time based known traffic patterns.

Checkout servers if campaigns drive huge browsing traffic, one or more checkout servers will take traffic from customers who have started the checkout flow.

Other things that help improve scale

We like to ensure caches are warm. Periodically and especially during cache clear events, our Smart Cache Warmer ensures most likely pages are in cache reducing the chances of a real user getting a cache miss.

Our 0-downtime code deploy ensures code release while the website is live. (0-downtime can only be achieved if there are no database changes in Magento). Scheduled deploy can also be used to deploy code automatically on low traffic times.

Interested in talking to us about how your website can scale better? Schedule a time below and we can analyze your website for free.

We can analyze your site for free

Schedule a call

Not happy with your website performance and want an expert to look at it?

  • We will analyze your site using public information.
  • We will ask you to give us a 1 day web server log file.
  • We will try to identify what steps if any you should take to improve your sites performance goals.

404 when moving to Magento 2

When migrating platforms for example from WooCommerce to Magento or from Magento 1 to Magento 2, it is imperative that we move all URLs  to ensure proper SEO authority is retained after the move as well as real users get a smooth Customer Experience (CX).

If it is not possible to maintain the same URLs, ensure redirects are made. This is especially true of a move from WooCommerce and also true when as part of the move the store is reorganized. When migrating data, an automated custom URL redirect process is recommended.

In spite of the best planning and intentions it is likely some URLs may be missed and redirects may not be setup.

Failing to do so has 2 negative effects

  • BOTS, especially Google may visit the new site with the older URL and receive a 404. This can reduce your site rating on Google.
  • Users that may have bookmarked or use browser history may get a 404 and get a bad CX resulting in visitors bouncing and reducing brand value.

Google Analytics does not show 404s. Google search console may show if the count is high. Neither of these is a reliable source to know what was missed.

Only the server knows for sure it severed a 404 and would have logged it in the apache or nginx access and/or error log files. On a new migration we recommend automating a 404 report from the log file, atleast once a day.

If using our luroConnect / Edge product, the dashboard can be used to setup a real-time alert for any 404 returned. This can then be actioned by developers or the agency to include a redirect.

Watch our webinar on performance and scaling in Magento

Its free!

Using analogy to vehicular traffic we explain performance and scaling in Magento.
Key takeaways

  • Know how to compare hosting options
  • Importance of good code
  • How to scale
  • Tuning Magento

We can analyze your site for free

Schedule a call

Not happy with your website performance and want an expert to look at it?

  • We will analyze your site using public information.
  • We will ask you to give us a 1 day web server log file.
  • We will try to identify what steps if any you should take to improve your sites performance goals.

Analysis of recent website security breaches

Introduction

Recent high profile website security breaches are nice to study to ensure you have defense mechanisms in place.
We strongly believe in “defense in depth” or “multi layered security”. This includes

  • Defense in Multiple Places. Meaning that an organization need to deploy security mechanisms in different places.
  • Layered Defenses. This means to have many layers of defense.

Let us analyze these hacks and lessons we can learn.

Analysis of 4 hacks to known websites

britishairways.com does not even store credit cards!

British Airways eCommerce site britishairways.com reported leak of 380,000 credit cards.

Let us first look at their privacy policy

Under “How we secure your payment information when you book online” it mentions

  • All of your personal information is encrypted as it travels over the Internet, to and from www.ba.com. When information is encrypted, it is scrambled between your computer and our server. The information is only unscrambled when it safely reaches us. It’s fast and safe, and it ensures that your personal information cannot be read by anyone else.
  • When you send your personal details to us, none of the information is stored on the website, it is passed straight back to our secure servers at our Heathrow headquarters, where it only exists as part of the record of your transaction.

Factually, what does “none of the information is stored on the website” mean?

Also based on the clarification given by BA we can assume they do not store credit card information along with the customer data.

The breach :

  • Magecart created a secure fake site baways.com which was used to store the siphoned credit card information
  • As is typical of magecart they broke into the britishairways.com servers, possibly through an admin interface to change a javascript file (modernizr.js), an open source library used on the website. Magecart inserted a short javascript that would monitor keystrokes and report back to baways.com that they owned.

That clearly indicates there was a breach. However, if one assumes the main servers of britishairways.com are well protected, there can be 2 possible options of breakin

  • It is possible in the website to use a administrative interface to change or upload a javascript file that gets used in the build
  • Or, they were able to gain access to the build process of britishairways website and ensure a modified version of the required javascript file was inserted.

What lessons can we learn?

  1. Admin interface to either update HTML or javascript code directly is a bad idea. If your environment has that convenience, it is important to protect it. Protection can be IP based so only certain IPs can access or be hidden in general and unlocked if needed.
    It is also important to periodically check if HTML or JavaScript stored in the database is clean. For example do not allow any JavaScript tag in the product description.

Live site should be hosted to ensure directories from where any code is executed is not allowed to be written to.

The breach :

Due to a vulnerability in “Apache Struts” that was exploited, access to execute any shell script was given and the hacker was able to download the entire credit history data stored.

Exact vulnerability in Apache struts – “incorrect exception handling and error-message generation during file-upload attempts, which allows remote attackers to execute arbitrary commands via a crafted Content-Type, Content-Disposition, or Content-Length HTTP header”

Patch was available but was not implemented on the server

What lessons can we learn?

  • While the obvious lesson is to update when patches are available, we think that it is not always possible or there will atleast be a lag between the patch being released and the website being patched.
  • A web user – the user that the web application is running as – should have a need to know access permissions.
  • Web root should be clean – do not have temporary folders or files that are not required – or limit permissions of the web user.
  • Monitor network activity for any unusual pattern – download of 143m records should not go unnoticed.
  • Use reverse proxy as we web server (like nginx) and do not expose the actual application servers to the internet. Infact, ensure the web server is a separate container or instance that only serves static content and passes upstream requests to the application server.

The breach :

As per facebook …

The vulnerability was the result of a complex interaction of three distinct software bugs and it impacted “View As,” a feature that lets people see what their own profile looks like to someone else. It allowed attackers to steal Facebook access tokens, which they could then use to take over people’s accounts. Access tokens are the equivalent of digital keys that keep people logged in to Facebook so they don’t need to re-enter their password every time they use the app.

First, the attackers already controlled a set of accounts, which were connected to Facebook friends. They used an automated technique to move from account to account so they could steal the access tokens of those friends, and for friends of those friends, and so on, totaling about 400,000 people. In the process, however, this technique automatically loaded those accounts’ Facebook profiles, mirroring what these 400,000 people would have seen when looking at their own profiles. That includes posts on their timelines, their lists of friends, Groups they are members of, and the names of recent Messenger conversations. Message content was not available to the attackers, with one exception…

The attackers used a portion of these 400,000 people’s lists of friends to steal access tokens for about 30 million people

What lessons can we learn?

  • Do not generic and hidden tokens that give cross access to APIs. Instead, each token should have a ACL (Access Control List) and select the minimum ACL required.
  • While this is particularly true for web services, in eCommerce websites payment gateway tokens should not be sent to frontend until required, even in hidden fields.

The breach :

  • On the evening of Saturday, June 23rd (2018), we received notice from our customers at Ticketmaster that the personal data of their users had been compromised. Upon further investigation by both parties, it was confirmed that the source of the data breach was a single piece of JavaScript code, customized by Inbenta to serve Ticketmaster’s particular requests. The attacker(s) located, modified, and used this customized script to extract the payment information of Ticketmaster customers processed between February and June 2018.
  • After a careful analysis of all clues and snapshots from our systems, the technical team at Inbenta discovered that the script had been implemented on the payment page. We were unaware of this, and would have advised against doing so had we known, as it presents a point of vulnerability.
  • Inbenta has conducted a detailed analysis of all the file systems used for development and production systems, thoroughly analysing any difference between the original source code and the version in the production environment. We can confirm that just 3 files were altered that affected 3 specific websites for Ticketmaster.
  • One of the advantages of hosting scripts at Inbenta’s servers that are embedded in our customer’s website is the flexibility that Inbenta can offer to our customers to have new functionalities or updates up and running quickly. The downside is that we cannot monitor which web pages our customers are embedding those scripts on and therefore we cannot prevent customers putting them in pages that collect sensitive information.

What lessons can we learn?

  • Avoid including 3rd party libraries from 3rd party servers. Implementing this is a matter of size sometimes – if the vendor is bigger and changes the content often, this cannot be done. However, there are many instances that can be avoided.
  • Ensure version in original source code and that in the production environment are the same, else there has been a breach.
  • Production site should be hosted to ensure directories from where any code is executed is not allowed to be written to.
  • Secure the CI/CD process so files in version control are not modified on the way. Some need to be compiled / compressed, etc but the possibility of inserting code has to be prevented. Securing CI/CD process is important.

Conclusion : Do not take Security for granted

Just having a SSL or a WAF is not enough security. Even having PCI certification is not enough security.

Instead, building security in mulitple layers, following first principles of security such as “need to access” and monitoring are needed. Since we cannot assume there is full proof security, we have to actively both prevent and know early if there is a breach.

To secure your Magento website, refer our article “Enterprise Grade Security For Your Magento Website

We can analyze your site for free

Schedule a call

Not happy with your website performance and want an expert to look at it?

  • We will analyze your site using public information.
  • We will ask you to give us a 1 day web server log file.
  • We will try to identify what steps if any you should take to improve your sites performance goals.

Agencies, come partner with us!

Development, SEO, Marketing, Site Speed – you do it all!

As a web agency, you have to wear multiple hats for your customers. Customers are looking for a one stop shop for their eCommerce needs for example. Development, SEO, marketing, optimized hosting, etc.

You are also sucked into all activities a customer wants, mostly because you want your customers to succeed, or maybe out of fear of losing. Some of these areas are core to you, some not so core. You build your skills, your people and it offers growth to you.

The evolving customer need – not just 24/7

Customer needs keep evolving. One prime example is in the choice of platform. With popularity of SaaS platforms like shopify, agencies are stretched to help a customer decide the platform and deliver on it. Sure there are clear cases where shopify is all the customer may need, but the border areas abound. Will the platform be the best choice now and in the future? In the future what type of integration and customization will the customer need?

SaaS offers lower complexity, an easier onboarding and a lower initial TCO (Total Cost of Ownership). Instead, Magento offers flexibility, but adds complexity to run the store – specifically related to hosting and maintenance. For example, customers never have to worry about site speed with SaaS while that is a specialty in itself for Magento.

Uptime is not all that a customer needs – indeed uptime is expected. Your customers want you to go beyond and deliver the best user experience to their visitors – so their brand value is enhanced.

Presenting, luroConnect for Magento & WordPress

A multi-cloud hosting stack for Magento & WordPress, accompanied by a 24×7 service, backed by realtime analytics and alerting to ensure a SaaS-like smooth experience to the merchant.

We go beyond

With features for agency like

  • Devops – we act like your extended team. Containerize development environment, manage staging & code deployment process.
  • Magento, WordPress, Headless & PWA
  • lurocomnect / Insights dashboard to help you monitor each customer’s website in a single interface

Features for your customers to help you deliver the high quality digital experience you have developed

  • Multi-cloud support – let the customer decide or give a variety of options for hosting and CDN.
  • Highly secure hosting stack : Web Application Firewall (WAF), a IP and BOT blocker, a load balancer all integrated into the nginx web server.
  • An asynchronous Image Optimization that can be used to generate retina and high pixel ratio mobile displays,
  • zero-downtime deploy
  • Disaster Recovery Plan – data replicated every 10 minutes to another cloud platform, giving a 15 minute time to switch with a max of 20 minute loss of data.

Come partner with us!

If you are a agency developing Magento or WordPress websites, we offer you a partnership that allows you to offer your customers the flexibility of owning a platform at the convenience of SaaS. Our rich stack continues to evolve – with a set of features already built and more on the way. Layered so you can charge your customers per service. For example,

  • Disaster recover plan of a max of 20 minute loss of data and max of 1/2 hour time to bring up the secondary setup on another cloud provider, in case of disaster.
  • Image optimization service that can optimize images automatically on the server
  • Custom branded luroConnect / Insight that gives response time analytics, alarms or view status of disk, etc.
  • Custom branded control panel that allows a set of action your customer or your engineers can take to actions such as deploying code to clearing CDN.

You also get our devops services for helping your developers go from “works for me” to “deployed to live” in an orderly fashion, allowing them to do best at what they do – develop.

Who are we?

Our CEO, Mr Pradip Shah is a 30+ years experienced techy and a frequent speaker.

Using open source technologies such a nginx, php-fpm, we have defined a multi cloud platform scalable architecture.

Our devops teams work on improving developer and operations productivity –  using bitbucket pipelines to build M2 code, ready to deploy or a self healing cache configurator, a smart cache warmer, etc.

Our cloud engineering team develops site monitoring and cloud control technology to give a dashboard with controls like one click deploy.

Interested?

Email us at partner@luroconnect.com and we will get back to you. Or, if you prefer, send us a chat message using the box on your right. Please remember to give us your email / phone to contact you.