Category: Cloud Education

  • How To Configure LSCache for Laravel (Configuration Guide)

    How To Configure LSCache for Laravel (Configuration Guide)

    A critical part of any software development process is the maintenance and enhancement of web application performance. It’s not something that’s done every now and then or considered at the end – it’s a never-ending process of optimizing and striving to build the most efficient and lean codebase. Throughout this process, the use of optimization technologies such as dynamic content acceleration (DCA) tools is prevalent.

    Web developers commonly employ DCA solutions to significantly improve the performance of web applications. These solutions streamline the workload of web servers by providing a more efficient, reliable, and faster network infrastructure.

    In the case of LiteSpeed servers, a built-in DCA known as LSCache has the features you need to reduce the loading time of your web pages.

    What is LSCache?

    LiteSpeed Cache, or LSCache, is a built-in, high-performance dynamic content acceleration feature available on the LiteSpeed server stack. It works by eliminating extra layers of reverse-proxy in websites, thus, optimizing the speed of accessing web content.

    LSCache Module vs. LSCache Plugin

    When developers mention the word LSCache, they are generally referring to the module, which, as mentioned before, is built-in to the LiteSpeed server stack itself. While you are busy building all your Laravel web app functionalities, the LSCache module works behind the scenes in caching your web resources to improve its speed.

    The automatic caching of the LSCache module may sound pretty convenient, but what if you want to control the module? Say, for instance, you want to instruct it on what resources to cache and how long you intend to cache them? Well, that’s where the LSCache plugin may come into action.

    The LSCache plugin is an add-on interface that allows you to utilize your module. Through this plugin, you’ll be able to directly manage how your web resources are cached.

    Why Should You Use LSCache Plugin for Your Laravel Web Applications?

    Web applications, like Laravel apps, are recreated every time users visit them, resulting in an increased round-trip time (RTT). RTT is a metric that determines how long a request gets submitted from a client to its server and back.

    An increase in RTT means a slower loading time. To prevent this aftermath, developers utilize the LSCache plugin. This highly customizable plugin offers developers an interface to easily configure website caches, thereby optimizing web apps and reducing the RTT.

    What is the Server-level Requirement of LSCache Plugin for Laravel?

    The LSCache plugin is simply an interface that will communicate to the LSCache module of your web server. For this plugin to work, ensure that your Laravel web application is running on a LiteSpeed server.

    How to Install the LSCache Plugin to your Laravel Application?

    To install the LSCache plugin in your Laravel application, follow the steps below.

    Step 1: Obtain a LightSpeed-powered hosting or server for your Laravel application.

    LSCache plugin will not work unless your Laravel app is powered by LiteSpeed. View your options through LightSpeed’s official hosting providers. You can also obtain your own LiteSpeed server via LiteSpeed’s download page.

    Step 2: Configure your server’s cache policy.

    Once you’ve acquired your server, you will need to configure its cache root and cache policy. Cache root refers to the storage path of the object files the module will cache. Cache policy, on the other hand, is a group of settings that manages the cache behavior.

    You will also need to enable the cache engine of your virtual hosts by including the following code in your vhost’s config file:

    <IfModule Litespeed> 
    CacheEngine on
    </IfModule>

    Step 3: Verify if LSCache is Working.

    Now that you’ve configured the cache settings, you’ll need to verify if your Laravel website is being cached. You can accomplish this by using your browser developer tools. To do so, follow the steps below:

    1. Navigate to your website using your browser and access the Network tab from your developer tools. This tab can be viewed by right-clicking and choosing Inspect.
    2. Refresh the web page and you’ll notice that requests get submitted.
    3. From the list of requests, click the first resource and you should see x-litespeed-cache: hit in your response header. This means that LSCache is correctly configured on your web page. An example is shown below for your reference:
    How to configure LScache in laravel apps

    Step 4: Install the LSCache plugin for Laravel using Composer.

    When you’re certain that LSCache is working properly, it’s time to install the LSCache package for Laravel using Composer. You can easily require this package through this script:

    composer require litespeed/lscache-laravel

    In later versions of Laravel, an auto-discovery feature was made available, so you don’t need to make changes when you install the LSCache plugin. For earlier versions, particularly between 5.1 and 5.4, the auto-discovery feature is not yet present, so you’ll need to perform the following additional steps:

    1. Add the code below in the aliases section of the config/app.php file:
    'aliases' => [
       ...
       'LSCache'   => Litespeed\LSCache\LSCache::class,
    ],
    1. You will also need to include the following middlewares under $middleware and $routeMiddleware of the app/Http/Kernel.php:
    protected $middleware = [
       ...
       \Litespeed\LSCache\LSCacheMiddleware::class,
       \Litespeed\LSCache\LSTagsMiddleware::class,
    ];
    
    protected $routeMiddleware = [
       ...
       'lscache' => \Litespeed\LSCache\LSCacheMiddleware::class,
       'lstags' => \Litespeed\LSCache\LSTagsMiddleware::class,
    ];
    1. After including all the scripts above, you’ll need to copy the config/lscache.php file into your config/ directory.

    The last step that you must do is to enable the CacheLookup. In your .htaccess level or vhost, include the following codes:

    <IfModule Litespeed>
       CacheLookup on
    </IfModule>

    You should now be able to configure your LSCache after successfully installing the plugin.

    How to Configure LSCache Plugin for Laravel?

    The LSCache plugin for Laravel comes with three functionalities—setting cache control headers, setting specific tags, and purging.

    Step 1. Setting the Cache Control

    You can configure the settings of your LSCache in the config/lscache.php file. From here, you can control the TTL (Time to Live), ESI (Edge Side Includes), and the default cacheability:

    • LSCACHE_DEFAULT_TTL – Set how long a cache lasts in seconds. The default for this setting is 0.
    • LSCACHE_ESI_ENABLED – This setting allows you to enable ESI. ESI lets you fragment web pages, providing a faster and more efficient way of caching them. You can set either true or false values to enable or disable this setting. By default, this setting is configured to be false.
    • LSCACHE_DEFAULT_CACHEABILITY – In this setting, you can set the default cache setting such as private, public, no-cache, or no-vary.
    • LSCACHE_GUEST_ONLY – You may also want to configure the cache if it can be enabled for guests only through this setting. It also accepts true or false, with the latter as the default value.

    Middleware is used to configure the cache-control header. You can override the settings in your Laravel routes similar to the codes below.

    The first route ‘/’ uses the default cache-control header in your config/lscache.php. For the ‘/account’ route, the ‘lscache:no-cache’ header prevents the route from being cached.

    In the case of the ‘/contact’ route, notice that three settings have been overridden. The route has been set to have a max-age of 10 seconds (TTL), a private cacheability, and an enabled ESI.

    Step 2. Setting Specific Tags

    Sometimes, it is a good practice to assign tags to web pages so that you can easily target them the moment you want to purge the cache. You just need to include the lstags middleware in your route, as shown in the example below.

    Step 3. Purging

    Suppose data gets updated in your server and you want to remove an existing cache to recache the new data. In which case, you just need to purge the existing cache first. You can do this by configuring your controller to use the purge method:

    The purge() method lets you purge a specific page. If you want to purge all pages, you can use the purgeAll() or purge(*) instead. You can also purge pages with a specific tag by including the tag keyword inside the purge method, as in:

    LSCache::purge(‘tag=products’);

    Conclusion

    Configuring LSCache in your Laravel applications may be a bit tricky, but you’ll get the hang of it eventually, especially when you fully understand why it is needed. Throughout this article, we provided all the essentials of the LSCache plugin, how to configure it, and, more importantly, its impact on your Laravel apps.

    There are numerous tools out there that you can use to cache and optimize your web pages, and it might thrill you to know that LSCache is among the best!

    Recommended read: What is Laravel and how to use it?

  • How to Use Cloudflare Firewall Rules to Protect Your Web Application

    How to Use Cloudflare Firewall Rules to Protect Your Web Application

    For more than ten years, the Cloudflare team has provided security services to website creators worldwide and is currently helping thousands of businesses maintain and secure their online resources.

    Since its creation, Cloudflare has released many strong firewall utilities, such as IP rules, CIDR rules, ASN rules, country rules, and HTTP user-agent blocking, to name a few, and Cloudflare Firewall Rules are a recent addition to these. These rules combine how firewall utilities are used, and provide users with more flexibility and control over how their firewall works.

    In this article, you’ll learn everything you need to know about firewalls, how to start implementing and editing Cloudflare Firewall Rules on your website, and why security is so important.

    What Are Cloudflare Firewall Rules?

    Cloudflare Firewall Rules are a flexible and intuitive framework website owners can use to filter HTTP requests – giving you complete control of which requests are able to reach your application.

    Firewall rules integrate well with existing Cloudflare tools, as they allow you to combine multiple techniques into a cohesive set of rules. For example, you can create one rule to block traffic from users matching a particular pattern, instead of having to use three or four different rules in as many places to accomplish the same result.

    They also give you the advantage of continuously checking the site traffic and responding accordingly to threats. You can define expressions that inform Cloudflare of what or what not to look at and what kind of action should be taken when those particular requirements are satisfied.

    Why Are Firewalls Necessary for Your Website?

    Cloudflare is mainly used to decrease web page load speed and protect your site from online threats. It also fights against spammers, malware injections, and DDoS attacks.

    Around 70% of WordPress installations are prone to hackers, making it more necessary to use Firewalls from Cloudflare to protect your site from unwanted threats. Some of the reasons why firewalls are required for your website are:

    • Cloudflare utilizes three different types of minification, JavaScript, CSS, and HTML, to reduce file size and increase load speeds by removing unwanted white spaces, newline delimiters, and unnecessary characters.
    • With the introduction of HTTP/3, Cloudflare supports multiple page elements parallelly over a single TCP connection along with push technology and header compression.
    • Cloudflare WAF protects your site from many vulnerabilities that popular CMS tools (WordPress, Joomla, etc.) are prone to. Cloudflare WAF has more than 145 rules to protect your site from all types of web application attacks.
    • Cloudflare has a rate-limiting function that helps mitigate DOS attacks, brute force login attempts, and other malicious intent against the application layer. The rate-limiting function allows you to configure thresholds, define responses, and gain insights on websites.

    As you can see, Cloudflare not only improves SEO by speeding up your website, it provides a whole host of advanced security features to protect your site from attacks.

    Cloudflare Firewall Rules – Matching & Actions

    Cloudflare Firewall Rules are made up of two main functionalities: Matching, which lets you define a filter to precisely match your traffic, and Actions, through which you determine the action Cloudflare will take after you set the matching filter.

    Matching

    Matching lets you filter out any incoming traffic to your website. For example, if you wanted to restrict certain countries, redirect visitors to a location-specific page, or filter out particular IP addresses, then you would use matching rules to do this.

    Among the most important features Cloudflare is introducing is the known bots (cf.client.bot) field. It provides you with a Cloudflare-approved list of good bots obtained through reverse DNS lookups. You will find a comprehensive list of bots approved by sites such as Google, Yahoo, Bing, Linkedin, Apple, and more.

    Note: Since the “allow listing” function has been removed, it’s recommended that you include cf.client.bot in an Allowed rule. This would prevent Cloudflare Firewall Rules from unintentionally blocking good crawlers.

    What’s more, Cloudflare Firewall Rules also come with an algorithm that gives a threat score to IPs by measuring their online reputation. The threat score ranges from 0 to 100 and is divided into the following categories:

    • High – for scores from 0 to 13;
    • Medium – for scores from 14 to 23;
    • Low – for scores from 24 to 48;
    • Essentially Off – for scores greater than 49.

    However, setting up matching rules alone won’t achieve much. This is where Actions come in.

    Actions

    With matching filters set up, you can instruct Cloudflare Firewall Rules to apply the standard Cloudflare actions (Block, JavaScript Challenge, and Challenge) as well as the new Allow action.

    • Block: used for blocking traffic from getting access to your web application.
    • JavaScript Challenge: used to block traffic from visitors who don’t have JavaScript support, which is usually bots.
    • Challenge (Captcha): used to set up a Captcha challenge to block potential bots.
    • Allow: used for allowing visitors access to your web application.

    Three Examples of Cloudflare Firewall Rules In Action

    In this section, you’ll find three ways to set up Cloudflare Firewall Rules by using the dashboard and why they might be helpful.

    We’ll be covering:

    • How to block particular countries from visiting your site
    • How to make your WordPress site more secure with captcha
    • How to prevent bad bot traffic from coming to your site

    Note: Another way to set up these rules is by using API and Terraform.

    To begin, log into your Cloudflare dashboard. From there, choose the domain name for which you want to set up Cloudflare Firewall Rules.

    cloudflare firewall rules in action step 1

    Next, click on Firewall from the top sections and then on Firewall Rules.

    cloudflare firewall rules in action step 2

    This section lets you set up a new firewall rule, browse and filter existing rules, activate, deactivate, modify, and delete rules. To try out the below examples, click on Create a Firewall rule.

    cloudflare firewall rules in action step 3

    Example 1 – Block All Countries Except the USA

    To block all countries except a single one (in our example, it will be the United States of America), follow the steps below:

    1. First, give your rule a name.
    2. From the Field drop-down, choose Country.
    3. Next, from the Operator drop-down, choose does not equal.
    4. In the Value drop-down, choose the United States.
    5. Finally, choose an action drop-down, select Block, and then click on the blue Deploy button in the lower right-hand corner.
    cloudflare firewall rules block all countries

    Conversely, if you would like to block a single country, pick equals from the Operator drop-down and then follow the procedure as mentioned above.

    Expression Editor:

    (ip.geoip.country ne “US”)

    Example 2 – WordPress Security

    WordPress security is an important thing that site owners don’t think much about. Every day, Google blacklists about 10,000+ websites for malware and around 50,000+ websites every week for phishing. It’s essential to keep your WordPress site secure from malware and threats and avoid getting your site blocked.

    Why Is WordPress Security Important?

    Whether your website is big or small, hackers don’t care about it. One way or the other, they can find different ways to use the information against you. They typically look for your personal and financial information and then try to cause damage to you and your company with the collected info.

    Mark Ronso, Marketing Manager at Top Writers Review, said, “a business’s reputation can be seriously damaged due to a hacked website. Hackers commonly install malicious software or viruses to extract the data in the background, which can result in a loss of trust in your business and customers turning to a competitor.”

    Hence, to keep your business safe and secure, you’ll need to protect your site through WordPress plugins or a Cloudflare firewall. So, which one is the best, and what’s the difference between the two?

    WordPress Plugins vs. Cloudflare Firewall – Which Is Better?

    A lot of people choose to install free plugins to handle the security of their site, instead of having to use a third-party tool like Cloudflare – usually, because it’s too complicated or to save money. In reality, Cloudflare doesn’t take long to install and provides you with much more functionality than any other WordPress plugin.

    Here are the key differences you should know about:

    Cloudflare firewall:

    • Cloudflare firewall seamlessly integrates with CDNs like WordPress
    • Cloudflare’s Automatic Platform Optimization (APO) caches your site and optimizes the assets, increasing your site’s speed.
    • Cloudflare firewall offers a free SSL certificate and DNS service, along with powerful DDoS protection.
    • Increases the speed and performance of your site by rewriting insecure URLs dynamically to their secure counterparts.
    • Free to get started

    WordPress Security Plugins:

    • Regularly scans your site for malware code and has a real-time firewall feature that protects your site from known and unknown threats.
    • Many free plugins don’t offer features like IP blocking, country blocking, and protection from brute-force logins.
    • Some WordPress plugins allow you to rename the login gateways to avoid potential attacks.
    • You never know what permissions you’re giving up to the plugin developer.

    All things considered, most WordPress plugins don’t increase your site’s speed or offer as many advanced features that Cloudflare firewall provides. Cloudflare firewall is recommended over free security plugins to protect your website from any attacks.

    How to Secure Your WordPress Site With Cloudflare Firewall

    Repeat the process mentioned above of creating a new firewall rule and naming it, but this time, click on the Edit expression.

    Secure Your WordPress Site With Cloudflare Firewall edit expression

    By doing so, you are directly accessing the Expression Editor. In the field, paste the following:

    ((http.request.uri.path contains “/xmlrpc.php”) or (http.request.uri.path contains “/wp-login.php”) or (http.request.uri.path contains “/wp-admin/” and not http.request.uri.path contains “/wp-admin/admin-ajax.php” and not http.request.uri.path contains ” /wp-admin/theme-editor.php”)) and ip.geoip.country ne “US”

    After that, pick Challenge (Captcha) from the Choose an action drop-down, and then click Deploy.

    Secure Your WordPress Site With Cloudflare Firewall challange captcha and deploy

    Now you will have set up a Captcha challenge for all visitors outside the US who attempt to reach WordPress xmlrpc.php, wp-login.php, and /wp-admin (except admin-ajax.php and theme-editor.php), in order to block potential hackers from accessing your WordPress website.

    If your login or admin URLs have been changed, feel free to edit the original expression to match.

    Example 3 – Block Bad Bot Traffic

    Bad bots are assigned to do a number of fraudulent practices and malicious activities like ad scams, malware attacks, and data theft. Around 40% of internet traffic consists of bad bot traffic, and, during the pandemic, there was a 788% increase in bad bot traffic to retail websites globally between September and October 2020, resulting in a loss of $82 million during peak season.

    Blocking out bad traffic helps avoid attackers trying to launch a DDoS attack on your site. Most DDoS attacks slow down your site by directing a large amount of traffic towards your site, overloading the server, and making it go offline. 

    While the list of user agents to block may vary based on your specific needs, here are some common ones to consider:

    • Yandex: A Russian search engine bot.
    • muckrack: Associated with media monitoring services.
    • Qwantify: A bot from the Qwant search engine.
    • Sogou: A Chinese search engine bot.
    • BUbiNG: A web crawler.
    • CFNetwork: Associated with Apple’s networking framework. While legitimate Apple users utilize CFNetwork, some malicious bots or scrapers may also impersonate it.
    • Scrapy: A Python-based web crawling framework.
    • SemrushBot: Associated with the Semrush SEO tool.
    • AhrefsBot: A bot from the Ahrefs SEO tool.
    • Baiduspider: A bot from the Baidu search engine.
    • python-requests: A Python library for making HTTP requests.
    • Various “crawl” and “spider” user agents: These may include legitimate search engine bots, but it’s essential to filter out excessive or suspicious crawling behavior.

    The procedure here is similar to the previous example. The only difference is that you should choose Block from the Choose an action drop-down and paste the following in Expression Editor:

    (http.user_agent contains "Yandex") or (http.user_agent contains "muckrack") or (http.user_agent contains "Qwantify") or (http.user_agent contains "Sogou") or (http.user_agent contains "BUbiNG") or (http.user_agent contains "CFNetwork") or (http.user_agent contains "Scrapy") or (http.user_agent contains "SemrushBot") or (http.user_agent contains "AhrefsBot") or (http.user_agent contains "Baiduspider") or (http.user_agent contains "python-requests") or (http.user_agent contains "crawl" and not cf.client.bot) or (http.user_agent contains "Crawl" and not cf.client.bot) or (http.user_agent contains "bot" and not http.user_agent contains "bingbot" and not http.user_agent contains "Google" and not http.user_agent contains "Twitter" and not cf.client.bot) or (http.user_agent contains "Bot" and not http.user_agent contains "Google" and not cf.client.bot) or (http.user_agent contains "Spider" and not cf.client.bot) or (http.user_agent contains "spider" and not cf.client.bot)

    This rule will block bot traffic with user agents containing the strings “crawl,” “bot,” “spider,” and some other custom user agents.

    cloudflare firewall rules example 3 block bad bot traffic

    Remember that blocking user agents should be done thoughtfully. Regularly review your website logs and adjust your blocking rules as needed to strike a balance between security, performance, and user experience.

    How To Test That Your Firewall Rules Work

    Once you’re all set up, you should check to see if your Cloudflare Firewall Rules work. To do this, you can access the Firewall Event Activity Log by going back to the Overview section of the firewall. There, you can see a list of firewall events and details related to them.

    test that your firewall works

    Note, checking your Firewall Rules can take some time to do if you don’t get much traffic. If this is the case, wait a couple of days and monitor Google Analytics to make sure there are no abnormalities before returning to Cloudflare and checking the activity log.

    The most important thing to look out for are challenge and block events.

    When challenge and block events appear on the list, take your time to go through them and see if any good bots were blocked when they shouldn’t have been, or if any known bad bots made it through. You need to make sure no positive traffic gets denied access to your site because of an error in setting up firewall rules.

    Summary – Use Cloudflare Firewall Rules To Your Advantage

    RunCloud lets you easily manage your server and web application, and seamlessly integrates with Cloudflare. We hope you’ve found this guide useful in setting up & effectively implementing Cloudflare firewall rules to improve the security and performance of your web application.

    Get started with RunCloud today.

    What firewall rules are you currently deploying via Cloudflare? Let us know & join the conversation in the comments below! 💬

  • Google FLoC – What You Need to Know & How To Opt Out

    Google FLoC – What You Need to Know & How To Opt Out

    There has been a lot of talk lately surrounding Google’s Federated Learning of Cohorts (FLoC) initiative, which is quickly becoming a hot-button topic both in the tech community and major mainstream publications.

    In this blog post, we’ll cover what Google FLoC is, why it matters, and how we’ve made it easy to disable it in RunCloud.

    What Is Google FLoC & Why It Matters

    FLoC is a proposed feature by Google that lets browsers collect, profile, and store usage patterns based on a user’s browsing habits over time.

    This new type of tracking, which is done directly within the browser, would then be used by Google and its advertising partners for widespread tracking and personalization of ads.

    FLoC is part of a larger response by Google to the slow decay (and increased blocking) of third-party cookies on the web. Why? Because as users become more privacy-aware, the ease of tracking and identifying them across multiple websites for the purposes of advertising and surveillance has become much more difficult in recent years.

    With the proposed FLoC feature enabled, the browser will create “cohorts” that group users with similar browsing habits together. This cohort ID will grow in size and relevance as it continually gathers information about the sites that users visit, the ads that they view, their behavioral patterns, how often they browse, etc.

    Each individual cohort is then combined with other cohort IDs when sent to Google, who will then display ads to individual users based on the relevancy of the data that has been collected within their shared cohort.

    Why FLoC Is Considered Premature

    In the acronym for FLoC, the word cohort was carefully chosen. A cohort is defined as a “group of individuals having a statistics factor in common”.

    Google’s promise is that FLoC cohort IDs will be anonymous data points in a larger network and that each cohort’s data will be sent to advertisers without them knowing the identity of individual users.

    The problem with FLoC however is two-fold, both in principle and in practice.

    Principally, the user’s browser is supposed to be sacred. It’s simply a tool to interact with the larger web. FLoC aims to turn the browser into a real-time tracking mechanism that collects the most sensitive information about an individual user’s browsing habits without the user being able to circumvent or opt out of this data collection.

    In practical terms, it’s not difficult for advertisers to understand and identify patterns once the FLoC data set becomes large enough. For example, cohorts comprised of users that share the same location data, shop in the same neighborhood, are active in the same time zone, etc. can be easily grouped together by demographic.

    To make matters worse,, if FLoC data is used in combination with other tracking mechanisms such as social media analytics, existing third-party cookies, or data sets purchased from data brokers, it becomes a trivial task to fingerprint users based on age, class, ethnicity, political parties, etc.

    Why FLoC Sets A Dangerous Precedent

    Google announced that in Chrome version 89 they will forcibly enable and trial their FLoC data-collection initiative without the consent of users or webmasters.

    The Electronic Frontier Foundation was one of the first privacy advocates to bring to light the dangers of this announcement. They correctly pointed out that instead of reducing the overreach of personalized tracking in the ad-tech industry, Google is now seeking to leverage it’s Chrome browser to do the data mining itself.

    Google Chrome’s market share is currently pegged at almost 70%. That represents more than two-thirds of the entire user base of the web. Once the FLoC rollout has exited it’s current beta stage and is mainlined into the Chrome codebase, it immediately begins profiling the majority of Internet users and sends that information straight to Google.

    Other browser vendors such as Mozilla Firefox, Brave, Microsoft Edge, Vivaldi, and Opera have recently weighed in on FLoC, some of them making broader statements as they wait to see how the situation unfolds, while others have already chosen not to support any such data aggregation efforts whatsoever.

    The most notable response is that of Brave, with an entire blog post that opens with this clear statement:

    Brave opposes FLoC, along with any other feature designed to share information about you and your interests without your fully informed consent. The privacy-affecting aspects of FLoC have never been enabled in Brave releases […] Brave is also disabling FLoC on our websites, to protect Chrome users learning about Brave.

    How to Opt Out of FLoC Data Collection

    For end-users, the easiest choice when it comes to opting out of FLoC’s data collection is simply not to use Chrome. However, a Chrome Extension was released by DuckDuckGo that disables FLoC tracking within the browser. If this extension will be disabled by Google or simply ignored by the browser itself is yet to be seen.

    The larger point of contention however lies with webmasters and web server administrators. FLoC requires that a website provide an explicit HTTP response header if it wants to opt out of the program. This suggests that Google is counting on webmasters to not be bothered with this task.

    The Easiest Way To Opt Out of FLoC (with RunCloud)

    Manually inserting the necessary FLoC header in your web server configuration, and then reproducing this for multiple applications is quite time-consuming. Fortunately, RunCloud makes this easier than ever – we’ve integrated the necessary pre-defined HTTP headers for all users so they can disable FLoC in less than a minute.

    Once logged in, navigate to your server, and under Web Applications > NGINX Config you’ll be able to select and add the required config rule. After adding the required headers, the next step is to clear your NGINX FastCGI cache (RunCache) and then test your website or web application to ensure the headers are being delivered.

    We’re currently implementing a similar feature to support websites and applications using the OpenLiteSpeed web server and will be rolling it out in the coming days.

    If you choose not to opt out of FLoC as a website owner, you are helping Google to add more profiling data on your visitors by leveraging your website as a data point that adds to the user’s fingerprint on the web. Opting out of Google’s new FLoC initiative & protect your users in a matter of less than a minute with the help of RunCloud – here’s how:

    So if you’re a RunCloud user and currently using a server that runs on NGINX, opting out couldn’t be easier – in just a few clicks.

    Alternatively, in order to opt your website out of the FLoC network, webmasters need to add a custom HTTP response header to their website to be served with each request. This comes in the form of a Permissions-Policy header, with the following syntax:

    Permissions-Policy: interest-cohort=()

    For the popular NGINX web server, this can be achieved with the add_header directive, which needs to be added to each website’s configuration file. The following code snippet shows the syntax that’s required:

    server {
        location / {
          add_header Permissions-Policy interest-cohort=();
        ...
        }
    }

    After adding the snippet to your configuration file, you’ll need to reload NGINX in order for the changes to take effect.

    NGINX has built-in syntax checking that should be used in combination with a reload or restart, the following command will do both:

    nginx -t && service nginx reload

    Once enabled in NGINX, the Permissions-Policy header will be respected by Chrome and disables FLoC data collection for users that visit your website — in other words, your website will not be used as a profiling data point for your users’ browsing habits.

    Opting Out of Google FLoC on OpenLiteSpeed (RunCLoud)

    If you’re using the similarly popular OpenLiteSpeed web server, you can add the necessary FLoC header by editing your vHost configuration file (vhost.conf) which is located in the /usr/local/lsws/conf/MY_VHOST/ directory.

    OpenLiteSpeed uses what are called Contexts for adding custom headers and other functionality to a web application. In the example below, we’ll be adding the following code to the root context in an example WordPress configuration located at /usr/local/lsws/conf/vhosts/wordpress/vhconf.conf:

    context / {
      location                $DOC_ROOT
      allowBrowse             1
      note                    This header disables FLoC
      extraHeaders            set Permissions-Policy interest-cohort=()
    }

    If you use RunCloud to manage your OpenLiteSpeed servers, adding the above snippet to your configuration file is as easy as navigating to your server and under LiteSpeed Server Config:

    The Context snippet can be placed after your Index directive. And, fortunately – with RunCloud, there’s no need to manually restart OpenLiteSpeed. After you’ve inserted the snippet and click Update Config, we automatically enable the configuration changes under the hood.

    Otherwise, after saving the changes to your configuration file – you’ll need to do a graceful restart of OpenLiteSpeed in order for the changes to take effect. The following command will achieve that:

    systemctl restart lsws

    Opting Out of Google FLoC on OpenLiteSpeed (Non-RunCloud Method)

    If you prefer to use the graphical OpenLiteSpeed WebAdmin Console instead, you can achieve the same functionality with the following steps outlined in the screenshots below.

    The OpenLiteSpeed WebAdmin runs on port 7080, which would be closed by default in your firewall.

    To enable access to that port via UFW, use the following command:

    ufw allow 7080

    UFW stands for Uncomplicated Firewall and is an extremely popular and easy-to-use wrapper around IPTables firewall rules. Most Linux distributions come with it pre-installed, but you can manually install it for your distribution.

    For Debian/Ubuntu run the following command:

    sudo apt install ufw -y

    For servers using CentOS, run the following command:

    yum install ufw -y

    UFW will not be immediately active by default. But before activating it, it’s important to set the necessary default rules:

    ufw default deny incoming
    
    ufw default allow outgoing

    And then use UFW’s syntax to add common ports that you’ll need on your server:

    ufw allow ssh
    
    ufw allow http
    
    ufw allow https

    Those rules take care of SSH (else you’ll be locked out when you try to reconnect), as well as HTTP and HTTPS web traffic.

    You can now enable UFW by running:

    ufw enable

    You can check the status of your firewall by running ufw status

    Finally, add the custom rule for OpenLiteSpeed WebAdminwhich will be active immediately:

    ufw allow 7080

    Next, login to your WebAdmin Console which is located at http://YOUR_SERVER_IP:7080 and navigate to the list of Virtual Hosts:

    Next, select the Virtual Host that you wish to edit. In this case we’ll be editing “wordpress”. Select the + icon to add a new Context:

    Choose Static as the context type and press the Next icon:

    There are a number of fields available when adding Contexts from within the WebAdmin console. For the purposes of disabling FLoC, only the following fields need to be populated:

    The URI scheme and whether it’s Accessible or not are mandatory fields.

    The $DOC_ROOT is not strictly needed, but it’s better to utilize this variable as OpenLiteSpeed uses it internally to match your website’s document root.

    The Notes field is optional as well but is useful for displaying what the rule does in the WebAdmin list of Contexts.

    Finally, the Header Operations is where we set the FLoC header.

    As with the CLI, you’ll need to do a graceful restart of OpenLiteSpeed for these changes to take effect. You can do so by clicking on the green Restart button located next to the process ID (PID) of OpenLiteSpeed:

    When you’re finished in the WebAdmin Console, remember to restrict access to this port by denying connections in your firewall using UFW:

    ufw deny 7080

    How To Disable/Opt Out of Google FLoC (WordPress Plugin Method)

    If you use WordPress & wish to go the less technical route º there’s an open-source plugin that will add the necessary Permissions-Policy headers to your website.

    In your dashboard, head to Plugins > Add New and search for Disable FLoC by Roy Tanck. This plugin author has developed numerous plugins and is also a core contributor to WordPress.

    More importantly, this plugin will not overwrite or otherwise interfere with any existing Permissions-Policy or other security headers you’ve configured…

    Verifying FLoC protections in RunCloud

    After enabling your custom RunCloud headers to disable FLoC, you can verify the existence of the headers in a number of ways.

    The easiest method is to test your website online using securityheaders.com, which should display the Permissions-Policy interest-cohort=() string in the list of headers.

    If you’re comfortable on the command line, you can use the curl utility to inspect your website’s headers, with the following command:

    curl -I https://mywebsite.com

    The output should contain the string permissions-policy: interest-cohort=()

    Lastly, you can use your browser’s DevTools to inspect headers. Visit your website and open your browser’s DevTools with the shortcut CTRL + Shift + C. Navigate to the Network tab and you’ll be prompted to Reload your page to inspect the requests and responses.

    Once you’ve reloaded your page the first item in the list is the HTML of the page itself (with a GET/200 request/response code). Click on that entry, and on the right-side panel under the Headers tab you’ll be able to view all the response headers; of which permissions-policy: interest-cohort=() should be there.

    Summary – Say No To FLoC, Protect Your Users

    Following the announcement of Google FLoC, our team was excited to be able to provide our users an effortless opt-out process because we believe privacy should always be an option, control should belong to the website owner – if not the users themselves…

    Want to share your thoughts on Google’s FLoC intiative or have any other questions about opting out? Let us know & join the conversation by leaving a comment below. 💬

  • How to Set Up an Amazon EC2 (AWS) Server to Host Your Websites

    With AWS, Amazon’s cloud computing platform, you can create virtual servers in the cloud using either Amazon EC2 or Amazon Lightsail.

    Amazon EC2 is for highly configurable and performant environments, while Amazon Lightsail is for easy-to-use and affordable ones.

    This tutorial will guide you through hosting your web applications on Amazon EC2. You can also follow a short video tutorial at the end.

    Note: If you want to use Amazon Lightsail, please check our other tutorial – how to setup Amazon Lightsail to host your websites.

    Video Tutorial: How to Set Up Amazon EC2 (AWS)

    Prefer watching a video over reading? We’ve got you covered.

    You can watch this companion video tutorial while following this written guide.

    Step 1. Create an Amazon EC2 Instance

    To use AWS, you need to sign up or log in to your account.

    Tip: You can try out AWS services for free up to certain limits with the AWS Free Tier. The Free Tier has three types of offers: a 12-month Free Tier, an Always Free offer, and short term trials. Refer to AWS documentation for more details.

    Choose An AWS Region

    Before you create your Amazon EC2 instance, you need to pick a region from the top-right menu. Different regions have different Amazon EC2 dashboards.

    AWS has many regions around the world, such as N. Virginia, Cape Town, Hong Kong, Mumbai, Seoul, Tokyo, etc. You should pick a region that is near you or your customers. This way, your users will experience less delay when accessing your web applications.

    Launch Instance

    Search for “EC2” in the search bar at the top of your screen. Go to your Amazon EC2 dashboard and click the “Instance” menu on the left sidebar.

    Then click the “Launch Instance” button to start setting up your server.

    On the next screen, you can provide a descriptive name for your server. This name will be displayed in AWS dashboard.

    Choose Ubuntu Server Image

    Next, you need to choose an Amazon Machine Image (AMI) for your instance. If you use RunCloud, we support Ubuntu 20.04, 22.04 and later LTS versions.

    To pick the latest LTS release, just Click on the “Ubuntu” button in the quick start tab under the OS section.

    Choose Amazon EC2 Instance Type

    Under the “Instance Type” option, select one of the predefined instance types for your instance. Each type has a certain number of vCPUs (virtual Central Processing Unit) and memory.

    For example, you can choose the t2.micro instance with 1 vCPU and 1GB Memory that is free for AWS Free Tier users. Each instance type in different AWS region is priced differently. Refer to the AWS pricing chart for up to date information on this topic.

    Create and Download a SSH Key

    Next, you will need to specify the SSH key that you want to use to log into this server. If you already have an existing key-pair, you can either use that, or use the built-in utility to create a new key pair and save it to your local computer. You will not be able to download the file again after it’s created.

    Configure Security Group (Open Required Ports)

    Next, you need to open the required ports on your EC2 instance. This step is very important to make your Amazon EC2 instance reachable on the internet.

    You need open the following 4 ports:

    • SSH – TCP Port 22
    • HTTP – TCP Port 80
    • HTTPS – TCP Port 443
    • Custom – TCP Port 34210

    Additionally, you can also allow incoming UDP traffic on port 443 to enable HTTP3 traffic.

    To add the above rules, click on “Edit” next to the “Network Settings” sub menu and fill in the following details:

    • Auto-assign public IP: Disable (we will assign a static IP in next step)
    • Firewall (security groups): Create New security Group
      • Security group name: runcloud-security-group
      • Description: RunCloud needs these ports to function properly

    Next, you need to add the rules to open required TCP ports and allow connections from anywhere. For the SSH rule, we recommend setting the source type to “My IP“. This will block any connection requests that originate from outside your network.

    You should note that most residential internet connections do not have a permanent IP address, which means that your IP address will change roughly every 24 hours. Due to this, if you try to log in to your server in future, your SSH connection will be blocked.

    To fix this, you can just log back into your AWS account and edit the runcloud-security-group again to use your new IP.

    After adding all of the rules, just leave it and scroll down to the Storage section. Your configuration is temporarily saved in your browser and it will be deployed to AWS when we launch the instance.

    Add Storage

    Within the Storage option you can configure the storage of your server. There are 3 volume types: General Purpose SSD, Provisioned IOPS SSD, and Magnetic storage. Pick the storage type and size that you want, but keep in mind that you will be billed for storage separately.

    Moreover, you will continue to get billed even if you don’t use the storage. For example, if you allocate 200 GB of storage and your server only uses 5 GB then you will be billed for the whole 200 GB every month.

    After adding the storage, you can click on the “Launch Instance” button on the right. This will create a new server with the required settings.

    Step 2. Create A Static Public IP Address

    After creating the server, you will notice that the “Public IPv4 address” filed does not have any value. This is because we disabled the automatic assignment of public IP.

    Why You Need a Static IP Address

    • The public IP address that Amazon EC2 assigns to your instance automatically changes every time you stop and start the instance.
    • If you host your website on Amazon EC2, you should use a static IP address for your server. This way, your website will always be accessible at the same IP address.

    Amazon EC2 provides an Elastic IP address feature for this purpose. An Elastic IP address is a static IP address that stays the same after you stop and start your instance. Please keep in mind that if you use an Elastic IP address, you will not be charged separately. However, if you reserve an IP address and do not use it, then you will be charged for it.

    Moreover, if you terminate (delete) your EC2 instance, your Elastic IP will not be deleted automatically. You will need to go back to Elastic IP dashboard and manually release the IP address.

    Note: AWS limits each account to five (5) Elastic IP addresses per region by default. If you need more than 5 Elastic IP addresses in your AWS account, you can request a quota increase from the AWS Service Quotas console.

    Allocate An Elastic IP Address

    To reserve a new static IP address, go to the “Elastic IPs” section under the “Network & Security” tab in the left menu.

    On the next screen, click on “Allocate Elastic IP address“. This will open up a new screen – select the default values, and click “Allocate“, which will reserve a new IP address. Click on the newly allocated IP address to view its summary.

    After creating an Elastic IP address, you can continue to click the “Associate Elastic IP address” button. This will open up a new page – select the instance you wish to use this Elastic IP address from the drop down menu, and also select its corresponding private IP address.

    Click on “Associate“. Now your Amazon EC2 instance has a static IP address and is ready to be used to host your websites.

    Step 3. Connect Amazon EC2 Instance To RunCloud

    RunCloud lets you connect your cloud servers using three different methods. For Amazon EC2, you can use the manual server installation method.

    Log in to the RunCloud dashboard and click the “Connect a new server” button.

    Select “AWS EC2” from the Server Provider list, and then enter a server name and the static IP address that you created in Step 2. Then click the “Add this server” button.

    On the next screen, choose “Manual Installation” and you will see the script that you have to run on your Amazon EC2 instance.

    Connect to Your Amazon EC2 Instance Using SSH

    Go back to the Amazon EC2 dashboard and find your server under the Instances menu. Select the instance and click on the “Connect” button at the top.

    On the next screen, switch to the “SSH Client” tab. There you will see the commands that you need to execute to connect to your server.

    Open an SSH client and go to the directory where you saved the SSH key that you downloaded when creating the server. To verify that you are in the correct directory, you can run ls <key name> to see if the key is present in the current directory.

    For example, is the name of your key is my-SSH-Key.pem, you will run ls my-SSH-Key.pem. If this shows you the name of your key, then you are in the right place. If you don’t get anything then you need to change the directory using cd command.

    From this directory, run the following command to change the permissions of the SSH key:

    chmod 400 <SSH Key name>.pem

    You can copy the exact command from your AWS dashboard. After changing the permissions, you can run the example command provided in AWS dashboard:

    ssh -i <SSH Key name>.pem ubuntu@myamazonec2-public-dns

    After running the above command, you will get a warning that the authenticity of the server can’t be established when you connect to this server for the first time. Type ‘yes‘ and press “Enter“.

    Run the RunCloud Installation Script

    Finally, we will install the RunCloud agent. We need to run the RunCloud installation script command as the “root” user. Run this command to start a “root” shell.

    sudo -s

    Then, paste and run the RunCloud installer script command. You can find this script in in your RunCloud dashboard. The RunCloud installation will take a few minutes to complete.

    You can check the installer progress on the RunCloud panel too.

    If successful, data about your server will appear, and you will have successfully set up your Amazon EC2 server with RunCloud.

    Once it is completed, you will see the MySQL root password for your database management and the “runcloud” system user password. Please save this information in a secure place.

    Next Steps

    In this article, we have shown you how to set up Amazon EC2 (AWS) to host your websites on RunCloud.

    RunCloud makes it easy to deploy and manage web applications on any cloud server, including AWS. RunCloud and AWS work in tandem to provide you with a fast, secure, and scalable hosting solution for your websites.

    RunCloud is a fantastic tool that saves you a lot of time and hassle when you don’t want to manage your server or don’t have Linux expertise. With RunCloud, you can easily deploy and manage your web applications on any cloud server.

    Continue your journey and learn how to Create Your First Website on RunCloud.

  • How To Set Up Google Cloud Server To Host Your Websites

    The Google Cloud Platform (GCP) is a suite of cloud computing services offered by Google. All GCP data centers are connected through Google’s backbone network – one of the biggest and fastest in the world.

    RunCloud is a cloud server management tool that allows you to maintain full control of your server, and host multiple WordPress, WooCommerce, Laravel, and PHP applications with fast and easy configuration. With RunCloud, you don’t need to be a Linux expert to host your website on Google Cloud Platform servers.

    In this tutorial, we will show you how to set up a Google Cloud server to host your website using RunCloud.

    Step 1. Create a Firewall Rule to Allow Incoming Traffic

    Your server needs to allow incoming TCP connections on ports 80 and 443 to server traffic from the internet. RunCloud also requires TCP port 34210 to communicate with the server. We will make a firewall rule to allow incoming traffic on all these ports.

    Go to the “VPC network” > “Firewall” menu and click on “Create Firewall Rule”.

    Enter the following details, and click “Create Firewall Rule” to create a firewall rule:

    • Name: runcloud-firewall-rule
    • Description: Required by RunCloud to function properly.
    • Network: default
    • Priority: 1000
    • Direction of traffic: Ingress
    • Action on match: allow
    • Targets: Specified target tags
    • Tag: runcloud-server
    • Source filter: IP ranges
    • Source IP ranges: 0.0.0.0/0
    • Protocols and ports: Specified protocols and ports then select TCP and enter “80,443,34210”

    Additionally, you can also allow incoming UDP traffic on port 443 to enable HTTP3 traffic.

    Step 2. Reserve a Static IP Address (Optional)

    By default, Google Cloud instances are assigned an ephemeral external IP address. This means a new ephemeral IP address will be assigned to your instance whenever it is stopped and started again.

    If an instance is stopped, any ephemeral external IP addresses assigned to the instance are released back into the general Compute Engine pool, and become available for use by other projects, (GCP Documentation).

    If the IP address of the cloud instance changes, you will need to manually update it in your RunCloud Dashboard. It is highly recommended to use a static IP address for your server. This static IP is dedicated to you and will not be changed when you stop and restart the server, however you will incur additional charges for a static IP.

    Go to the “Reserve Static IP” option and enter the following details:

    • Name: runcloud-server-ip
    • Description: Static IP address reserved for RunCloud instance.
    • IP version: IPv4
    • Type: Regional
    • Region: Select your region, if you’re unsure then find out the region most suitable for you
    • Attached to: None

    Step 3. Create A Google Cloud Compute Engine Instance

    RunCloud needs a fresh Ubuntu server to function properly, and will not work on an existing production server. Go to the “VM Instances” tab in the “Compute Engine” menu, and click on “CREATE INSTANCE”.

    Select Name and Region

    Give your instance a name, and select the region picked in step 2. We recommend you use a region and zone that is nearest to your target users/visitors. The closer your server location is to your users, the less latency they will experience. This setting is permanent and cannot be changed later.

    Select Machine Type

    Under the “Machine configuration” option, select one of the predefined GCP machine types for your instance. Each machine type gives you a certain number of vCPUs (virtual Central Processing Unit), and a fixed amount of memory.

    After selecting your machine series, you can click on the drop-down menu to select the machine type and configure the number of CPU cores as well as RAM for your server. We recommend starting with the “e2-small” machine type, and scale up to match your workload at a later stage.

    Select Boot Disk and OS

    Next, you need to attach an Ubuntu LTS boot disk to your instance. RunCloud supports Ubuntu 20, 22, and 24 LTS 64-bit at the moment. Click the “Change” button under Boot disk, then select “Ubuntu 22.04 LTS Minimal” for x86/64 architecture.

    For the “Boot disk type” option, select “Balanced persistent disk”. Alternatively, you can choose “SSD persistent disk” for better performance, or “Standard persistent disk” to reduce the storage costs. The boot disk size is customizable from 10 GB to 65,536 GB.

    Apply A Custom Firewall Rule

    We will leave both “Allow HTTP traffic” and “Allow HTTPS traffic” unchecked under the Firewall option because we have already created a custom firewall rule to allow internet traffic. Click on the “Advanced Options” to reveal advanced settings.

    Look for “Network tags” under the Networking section and enter the “runcloud-server” tag created in step 1.

    Assign the Static IP

    Now we will assign the static IP reserved in step 2. If you are not using a static IP, you can skip this step.

    Scroll down to “Network Interfaces” and edit the default interface settings. Leave all the settings to default, and scroll down to the “External IPv4 addresses” option. Change this from “Ephemeral” to “runcloud-server-ip”:

    Click the “Create” button to start your Google Cloud server.

    Step 4. Connect Google Cloud VM To RunCloud

    Connect Your Server

    Begin by logging in to the RunCloud dashboard, and clicking the “Connect a new server” button.

    Next, select “Google Cloud Platform” from the Server Provider list. Enter the name and external IP address of your server, then click “Continue”.

    Install RunCloud Agent

    On the next screen, choose “Manual Installation”, and you will see the script that you have to run on your Google Cloud instance.

    Go to “VM instances” on your Google Cloud dashboard, and click “SSH” next to the instance that you just created. This will launch a web browser-based terminal to log in to your server.

    We need to run the RunCloud installer script command as a “root” user. Run the “sudo su” command to start a “root” shell, and then paste and run the RunCloud installer script command. This should only take a few minutes to complete.

    Once it’s completed, you will see the MySQL root password for your database management, and the “runcloud” system user password. Please save this information securely in a password manager.

    If successful, data about your server will appear in your RunCloud dashboard, and you will have successfully set up your Google Cloud server with RunCloud.

    Video Tutorial – Setup Google Cloud Server With RunCloud

    You can watch this short video tutorial to show you all steps that we have explained above in less than 3 minutes.

    Final Thoughts

    You can use RunCloud with Google Cloud to simplify server management experience. RunCloud agent needs to be installed on a Ubuntu LTS release and requires TCP port 80, 443, and 34210 to function properly. After a successful install, you can manage the server and monitor its performance metrics from the RunCloud dashboard.

    After setting up your Google Cloud server, you can continue to:

  • How to Set Up a Vultr Server with RunCloud

    Vultr is a cloud server provider that aims to make it easy for developers and businesses to deploy their infrastructure on its advanced cloud platform. It has become one of the leading choices for hosting websites. Vultr has a global presence with 32 data centers across the world – You can select the server location that is nearest to you or your target audience.

    In this article, we will show you how to host your websites on Vultr using RunCloud. RunCloud is a server management platform that lets you connect, configure, and manage your web applications on any cloud server provider, including Vultr.

    RunCloud makes it very easy to connect your Vultr server to its dashboard. Let’s see how!

    Method 1: Deploying/Creating a Vultr Server from RunCloud Dashboard (Recommended)

    RunCloud offers a server provisioning functionality that allows you to create and delete new servers directly from the RunCloud dashboard with just a few clicks. All you need to do is add the Vultr API key to your RunCloud account.

    Adding Vultr API Key to RunCloud

    The Vultr API key is a unique identifier that allows RunCloud to communicate with your Vultr account and create servers on your behalf. To get the Vultr API key, follow these steps:

    1. Log in to your Vultr account and go to the API settings tab on Vultr.
    2. Click on the “Enable API” button to generate your API key.
    1. Next, go to your RunCloud dashboard and navigate to the RunCloud Integrations tab in the account settings. Select “Vultr” from the list of available integrations.
    1. On the next screen, provide a descriptive name for this connection in the label field. In the “Personal Access Token” field, paste the API key generated in step 1.
    1. Finally, you need to whitelist IP addresses listed in the RunCloud dashboard on your Vultr account. This will allow RunCloud to access your Vultr account on your behalf. To do this, you need to individually copy each IP address (without the subnet mask, i.e. /32 at the end of the address) and add it to Vultr.

    For example, if you want to add 52.53.52.35/32, you will need to type 52.53.52.35 in the first box and then write 32 in the next box; then you need to click “Add” to add it to the list. You need to repeat this step for all of the IP addresses.

    This might seem like a lot of work for something so trivial, but this is required to properly secure your account. If you do this properly, you can set it and forget it. Once you have added all of the IP addresses, it should look something like this:

    1. After all of the necessary IP addresses have been whitelisted, you can go back to the RunCloud dashboard and test the integration. If you receive a success message, you can click “Save Integration” to add the key to your account.
    1. If you received an error during the last step, you should double check the list of IP addresses that you have whitelisted. If you got access to your Vultr account via an invitation, the root account will need to enable the necessary permissions to create and manage servers via API on their Vultr dashboard.

    To find the root user of your account, go to your Vultr profile menu, there you should see the email address of the root user that manages your account.

    That’s it! Your Vultr API key is now added to RunCloud and you can use it for building servers.

    Provisioning a Vultr Server with RunCloud Integration

    After adding the API key to your RunCloud account, you can build your Vultr server from the RunCloud dashboard in just a few clicks. You can choose from different OS images, plans, data center regions, and instances without leaving your RunCloud dashboard.

    Here are the steps to build your Vultr server with RunCloud:

    1. Click on the “Let’s get started” button on the RunCloud dashboard to create your first server.
    2. On the next screen, you will see a list of available server providers. Choose Vultr and click on the “Deploy Server Automatically” option.
    1. Next, scroll down and select your installation type, as well as your server. After this, select the Vultr API key that we just added to RunCloud.
    1. On the next screen, you will see a list of options to customize your server. You can choose the OS image (we recommend the latest version), the server plan, the data center region, and the instance that suit your needs.

      After adding all of the details, click on the “Add server” button to start building your server.
    1. RunCloud will provision your server automatically, and show you the progress on the dashboard. It may take a few minutes to complete.

    When the provision is done, you will see your server details on the dashboard. Congratulations! You have successfully built your Vultr server with RunCloud.

    Video Tutorial: How to Set Up a Vultr Server from RunCloud Dashboard

    If you prefer watching a video tutorial, you can check out this YouTube video that shows you how to set up a Vultr server from the RunCloud dashboard.

    Method 2. Setup Vultr Manual Server Installation.

    Another way to set up your Vultr server with RunCloud is to use the manual server installation method. This method requires you to create a new server on Vultr using Ubuntu 22/24 LTS OS image, and then run the RunCloud installation script on your server using an SSH client. But before we do that, we need to create a firewall.

    Using the Vultr Firewall

    Vultr provides a network-level firewall that runs in front of your server. Configuring it is optional, but it can help reduce unwanted traffic before requests ever reach your instance or the OS firewall.

    This section applies only if you are hosting on Vultr. If you are using another provider, or prefer to manage access purely via the server firewall configured by RunCloud, you can skip this step.

    By default, a Vultr firewall group blocks all incoming connections. You must explicitly allow the ports your server needs to function.

    Create a Firewall Group in Vultr

    1. Log in to your Vultr dashboard.
    2. Go to Network > Firewall.
    3. Click Add Firewall Group.
    4. Enter a descriptive name, such as “RunCloud Server Firewall”, and create the group.
    5. Open the newly created firewall group to manage its rules.

    Add Required Inbound Rules

    Add inbound rules to allow traffic needed for RunCloud and standard web hosting. Each rule should be created individually.

    Allow the following inbound traffic:

    • TCP port 80 – required for HTTP traffic
    • TCP port 443 – required for HTTPS traffic
    • TCP port 34210 – required for RunCloud to communicate with your server

    For SSH access:

    • TCP port 22 – required only if you connect via SSH. You can remove this rule later or restrict it to your IP address if you do not need ongoing SSH access.

    Optional performance enhancement:

    • UDP port 443 – enables HTTP/3 support if your stack and clients support it

    All rules can initially be set to allow traffic from anywhere. If you prefer a more restrictive setup, you can limit SSH access to trusted IP addresses.

    Apply the Firewall Group

    Once the rules are in place, attach the firewall group to your server instance. Firewall rules only affect new connections, so existing connections will not be interrupted.

    At this point, your Vultr firewall will block any inbound traffic that is not explicitly allowed, while still permitting RunCloud and your websites to operate normally.

    Provision VPS and Connect to RunCloud

    Here are the steps to follow:

    1. After opening the necessary firewall ports, go back to the Instances tab and click the “+” button to deploy a new server.
    2. On the next screen, select your desired machine type and region. Then choose Ubuntu as your OS image, and select the version that you want (22 or 24 LTS).
    1. After this, choose the plan, location, hostname, and other options that suit your needs.

      If you plan to use automated backups on RunCloud, you can turn this feature off on Vultr.

      Finally, select the firewall group we created from the drop-down menu, then click the “Deploy Now” button.
    1. Wait for a few minutes while Vultr creates your server, and assigns an IP address and a root password to it. When the server has been provisioned, note down the IP address and password for your server.
    Vultr dashboard
    1. Go back to your RunCloud dashboard and click on the “Connect New Server” button. Choose Vultr as your server provider and click on the “Connect via IP Address” option.

      Select your server stack, enter the IP address of your server and click on the “Continue” button.
    1. On the next screen, paste the root password of your server from the Vultr dashboard. This will install the RunCloud agent on your server.

      Wait for a few minutes while the script installs the necessary packages and scripts on your server. You will see a success message when it’s done.

    That’s it! You have learned how to set up a manual Vultr server installation with RunCloud. You can now start deploying web applications.

    Video Tutorial: How to Set Up Vultr Server with RunCloud

    Final Thoughts

    In this article, we have shown you how to use the server provisioning feature of RunCloud to set up a Vultr server from the RunCloud dashboard. This is a convenient and fast way to create your Vultr server without leaving RunCloud.

    Vultr is a great option for hosting your websites, as it offers high-performance architecture, 100% local SSD, and high-performance Intel CPUs for as low as $5 / month.

    Once you have set up your server, you can start creating your websites, adding your domains, and installing various web applications using RunCloud.

    Here are some tutorials that you can follow:

    We hope you enjoyed this article and learned something new. If you have any questions or feedback, please leave a comment below.

  • How To Create Custom NGINX Configuration Easily Using RunCloud

    How To Create Custom NGINX Configuration Easily Using RunCloud

    NGINX is one of the most popular and powerful web servers in the world. Many websites and web applications use NGINX, and customize it with their own configurations to optimize performance, security, and functionality.

    However, creating and managing custom NGINX configs can be challenging and time-consuming, especially if you have to log into the Linux terminal and edit files manually.

    That’s why we are excited to introduce easy custom NGINX configuration in RunCloud for you. You can now create custom NGINX configs directly from the RunCloud dashboard, without having to touch the command line.

    You can also test and debug your custom NGINX configs from the RunCloud dashboard before you apply them, so you can avoid breaking your website. This will save you a lot of time and hassle, and let you focus on your web development.

    What is NGINX Config?

    NGINX, pronounced like “engine-ex”, is the open source web server that powers more than 400 million websites. It’s now also used for reverse proxying, caching, load balancing, media streaming, and more.

    In this post, we’ll focus on NGINX as a web server. From NGINX success stories, we can see that NGINX open source web server has been used by many big companies, including Adobe, Cloudflare, WordPress.com, ZenDesk, Groupon, etc.

    NGINX is a high performance web server that is great for handling many concurrent connections and serving static content. All RunCloud servers are powered by NGINX web servers.

    In RunCloud, NGINX web server can be configured from NGINX configuration files that are located in the /etc/nginx-rc/ directory, with the primary configuration file found in /etc/nginx-rc/nginx.conf.

    Each web application in RunCloud has their own NGINX configs that are located in the /etc/nginx-rc/conf.d/ directory. Users can create custom NGINX configs that are located in the /etc/nginx-rc/extra.d/ directory.

    RunCloud Stacks

    RunCloud offers different stacks for your web hosting needs. Each stack has its own advantages and limitations. You can choose the stack that suits your website best.

    NGINX + Apache2 Hybrid Stack

    This stack combines the power of NGINX and Apache2. NGINX serves as a reverse proxy for Apache2, but only for PHP files. For static files (eg: CSS, JS, images, fonts), NGINX serves them directly. This way, you can enjoy the speed and efficiency of NGINX for static content, and the compatibility and flexibility of Apache2 for PHP content.

    This stack is ideal for average users who use .htaccess file to configure their website. However, if you need to do something that .htaccess file cannot do, you will need to use a custom Nginx config.

    Native NGINX Stack

    This stack uses only NGINX to handle your website. For PHP files, NGINX passes them to FastCGI to communicate with PHP-FPM. This stack is faster and more secure than the hybrid stack, but it doesn’t support .htaccess file.

    This stack requires you to use custom Nginx config if you want to rewrite or extend Nginx by including your own config.

    Native NGINX + Custom Config Stack

    This stack also uses only NGINX to handle your website, but it doesn’t serve your PHP file. This stack is suitable if you want to run other web applications or frameworks such as Node.js / Python / Golang / WebSocket / Ruby on Rails / etc., using RunCloud.

    This stack relies on custom NGINX configs to fully configure this stack. You can use custom NGINX configs to set up the proxy settings, headers, caching, and more for your web application.

    Create a Custom Nginx Config

    With the new “NGINX config” feature, you can do this directly from the RunCloud dashboard easily. Please log in to your RunCloud Dashboard, choose your server, go to Web Applications menu and click one of your web applications – you will then see the “NGINX Config” menu.

    Click the “Add a New Config” button to start creating your custom NGINX config for the current web application.

    If you are familiar with NGINX config, you can choose “I want to write my own config” and start adding your config.

    You can also start with a predefined NGINX config that we have provided. You can use it directly without customizing it.

    For config “Type”, you can start with location.main (default) and location.main-before. You can start using other types when you are familiar with the NGINX config structure in RunCloud.

    Run and Debug Custom NGINX Config

    Editing NGINX config directly using Linux terminal could be dangerous, and could take your website down if you don’t have enough skill to debug your NGINX config issue.

    RunCloud provides a “Run and Debug” feature that you can use to check if your custom NGINX config is okay or not.

    If your custom NGINX config looks good, clicking “Run and Debug” will give you a green message.

    If your custom NGINX config has some errors, clicking “Run and Debug” will give you red error message with the error details.

    Even if you don’t use the “Run and Debug” feature, and try to click the “Save config” button directly, RunCloud will debug your custom NGINX config automatically, and will stop if it encounters errors. Because of this, there’s no need to be afraid of whether your custom NGINX config could break your website.

    Predefined NGINX configs

    We also provide some predefined NGINX configurations that you can use without customizing them, since they’re tailored according to your web application.

    I want to write my own config

    If you want to customize your NGINX server settings, you can do so by selecting the “I want to write my own config” option from the dropdown menu in the Web Application Settings page. This will allow you to add your own NGINX directives in the Custom Config box. You can write anything you like, as long as it is valid NGINX syntax.

    Apple Pay verification

    If you want to use Apple Pay on your website, you need to verify your domain with Apple. This requires adding a specific file to your server and configuring your NGINX to serve it. To make this process easier, RunCloud provides a ready-made config template for Apple Pay verification. You can find it in the Config Templates page under the NGINX tab.

    All you need to do is select the template and apply it to your web application. This will automatically create the file and add the necessary NGINX directives for you. This way, you can save time and reduce the chances of error when setting up Apple Pay on your website.

    Cloudflare – Restore Visitor IP

    Cloudflare acts as a proxy to your RunCloud server, which means that all visitors will appear to be coming from Cloudflare IP addresses. This is a hindrance to visitor tracking or identifying attackers.

    In order to restore a visitor’s IP address, we need to retrieve the visitor’s originating IP address in the HTTP header from all Cloudflare’s IP addresses.

    You can use this predefined NGINX config to restore your visitor IP address, if needed.

    Header – Opt-out of Google’s FLoC Network

    This template allows you to prevent your website from participating in Google’s new tracking method called Federated Learning of Cohorts (FLoC). FLoC is a feature that lets browsers collect, profile, and store usage patterns based on a user’s browsing habits over time. This data is then used by Google and its advertising partners for targeting and personalizing ads.

    Some people may have privacy concerns about FLoC and may want to opt out of this network. By applying this template to your web application, you can add a header to your NGINX server that tells Chrome not to include your website in its FLoC calculations. This way, you can respect the privacy of your visitors and avoid being part of Google’s tracking system.

    Redirect – from non-www to www

    This simple NGINX config is useful if you want to redirect the non-www version of your website to www version.

    Note: Please use this NGINX config if only you have added both non-www and www versions of your domain to your web application’s Domain Name menu, and you have set up DNS Records for both non-www and www.

    Redirect – from www to non-www

    This simple NGINX config is useful if you want to redirect the www version of your website to non-www version.

    Note: Please use this NGINX config if only you have added both non-www and www versions of your domain to your web application’s Domain Name menu, and you have se tup DNS Records for both non-www and www.

    WordPress – 6G Firewall

    The 6G Firewall is a powerful, well-optimized blacklist that checks all URI requests against a set of carefully constructed .htaccess directives, developed by Jeff Star from Perishable Press. This happens quietly behind the scenes at the server level, which is optimal for performance and resource conservation.

    This predefined NGINX config brings 6G Firewall to NGINX web server in RunCloud servers.

    WordPress – 7G Firewall

    The 7G Firewall is the latest nG Firewall from Perishable Press. This predefined NGINX config brings 7G Firewall to NGINX web server in RunCloud servers.

    Both 6G & 7G firewalls are easy-to-use, cost-effective ways to secure your site against malicious HTTP activity. They help to protect against evil exploits, ill requests, and other nefarious garbage, such as XSS attacks, code injections, cache poisoning, response splitting, dual-header exploits, and more.

    The 6G & 7G firewalls are good alternatives of our Web App Firewall (ModSecurity & OWASP CRS). You can try either 6G or 7G firewall if ModSecurity WAF doesn’t fit with your web application.

    WordPress – Block direct PHP file execution

    This config template is a security measure that prevents hackers from running malicious PHP files on your website. By default, WordPress allows PHP execution in certain directories, such as the /wp-includes/ and /wp-content/uploads/ folders. This means that anyone who can upload files to these folders can also run PHP code on your server.

    Hackers can exploit this vulnerability by uploading backdoor access files or malware that can compromise your website. By applying this template to your web application, you can add a rule to your NGINX server that denies access to any PHP files in these directories. This way, you can protect your website from unauthorized PHP execution and improve its security.

    WordPress – Block wp-trackback.php

    This template prevents spammers from sending fake trackbacks and pings to your WordPress posts. Trackbacks and pings are notifications that another blog has linked to your content, but they can also be abused by spammers who want to create backlinks to their own websites. By applying this template to your web application, you can add a rule to your NGINX server that denies access to the wp-trackback.php file, which is responsible for handling trackbacks and pings.

    WordPress – Block xmlrpc.php

    The WordPress – Block xmlrpc.php config template is another security measure that prevents attackers from exploiting the xmlrpc.php file in WordPress, which is used for remote communication with your site. The xmlrpc.php file allows you to do things like posting to your site from your mobile device, receiving trackbacks and pingbacks from other sites, and using some features of the Jetpack plugin. However, it can also be abused by hackers who want to launch brute force attacks, DDoS attacks, or spam comments on your site.

    By applying this template to your web application, you can add a rule to your NGINX server that denies access to the xmlrpc.php file. This way, you can protect your website from xmlrpc.php attacks.

    WordPress – FlyingPress Plugin

    This config is a set of rules for NGINX server that are related to the FlyingPress plugin. The FlyingPress plugin is a speed optimization plugin for WordPress that boosts your website’s Core Web Vitals and performance. It has features such as critical CSS, lazy loading, bloat removal, font optimization, link preloading, and more.

    This config is for FlyingPress users who want to serve FlyingPress caches directly from NGINX, without touching PHP, especially when you use Native NGINX stack in RunCloud. You can use this config with either FlyingPress standalone only, or combine it with RunCloud Hub. You need to install the FlyingPress WordPress plugin first before using this config.

    The purpose of this config is to serve cached HTML files from the FlyingPress directory if they exist, and if none of the conditions that disable the cache are met. This can improve the speed and performance of your WordPress site by reducing the load on your server and delivering faster responses to your visitors.

    WordPress – Multisite Subdirectory

    The WordPress – Multisite Subdirectory config template is for WordPress sites that use the multisite feature in a subdirectory structure. By applying this template to your web application, you can add some rules to your NGINX server that enable the multisite functionality in a subdirectory mode.

    Note that this template is only needed when using WordPress inside a docker instance on RunCloud. If you’re using a regular WordPress installation on RunCloud, you don’t need this template.

    Developer Tips – RunCloud NGINX Config Structure

    If you’re a developer and want to explore the NGINX config structure in RunCloud, this information could be useful for you.

    When creating a custom NGINX config, we recommend you use location.main or location.main-before type. It works for common cases, your NGINX config will be loaded in the main location block of your web application.

    Configuration options in NGINX are called directives, and are organized into groups known as blocks.

    You can learn more about blocks in NGINX configuration here.

    Location.http

    The http block contains directives for handling web traffic. You can create custom NGINX configs that will be loaded in the http block, right before the server block of your web application.

    Headers

    You can use the headers config to add HTTP headers to your website. For example, you can add security headers, caching headers, or custom headers.

    Location blocks

    The location block lets you configure how NGINX will respond to requests for resources within the server. You can use different location configs to load custom NGINX configs in specific location blocks.

    1. location.main-before: This config will be loaded before the main location blocks in your web application. You can use this to add rules that apply either to all requests, or to specific requests based on prefixes or regular expressions.
    2. location.root: This config will be loaded inside the root location block that serves the document root of your website. You can use this to add rules that apply to the root directory.
    3. location.static: This config will be loaded inside the static location block that serves static assets (css / js / images / fonts / etc) of your website. You can use this to add rules that optimize the delivery and caching of static files.
    4. location.html: This config will be loaded inside the html location block that serves HTML pages in your website. You can use this to add rules that enhance the performance and security of HTML pages.
    5. location.favicon: This config will be loaded inside the favicon location block that serves the favicon.ico file in your website. You can use this to add rules that improve the caching and accessibility of the favicon file.
    6. location.main: This config will be loaded after the main location blocks in your web application. You can use this to add rules that override or complement the previous location blocks.
    7. location.proxy: This config will be loaded inside the proxy location block that passes requests to a backend server or service. You can use this to add rules that modify the proxy settings or headers.

    Runcloud-hub

    The runcloud-hub config is a necessary component when you use the RunCloud Hub plugin for WordPress. The runcloud-hub config enables the communication between the plugin and the NGINX server, and handles the caching rules and headers for your site. Without the runcloud-hub config, the plugin will not work properly and you will not be able to enjoy the benefits of RunCloud Hub features.

    After Action Report

    RunCloud is the ultimate solution for developers who want to host and manage their websites with ease and speed. You don’t need to be a Linux expert to use RunCloud. You can create and deploy your web applications, configure your server settings, and monitor your performance from a simple and intuitive dashboard.

    One of the features that makes RunCloud stand out is the ability to create custom NGINX configs directly from the dashboard. This gives you more flexibility and control over your web server without having to edit files manually. You can use this feature to optimize your website performance, security, and functionality.

    This feature is available for all paid plan users (Basic, Pro, Business). If you are already a RunCloud user, you can start using this feature right away. If you are not a RunCloud user yet, what are you waiting for? Join RunCloud today and see how easy and fast it is to host and manage your websites with RunCloud.

  • How To Use ModSecurity and OWASP CRS For Web App Firewall (WAF) To Secure Your Website

    How To Use ModSecurity and OWASP CRS For Web App Firewall (WAF) To Secure Your Website

    With security as a primary focus this year, we are happy to bring ModSecurity and OWASP CRS for your Web Application Firewall (WAF) in RunCloud.

    This feature helps protect your website from many types of attacks against your web application.

    You can easily enable or disable ModSecurity WAF to each web application in your RunCloud servers and adjust Paranoia Level and Anomaly Threshold parameters.

    Our ModSecurity WAF comes with OWASP ModSecurity Core Rule Set (CRS) and allows you to add Rule Modification easily from the RunCloud dashboard.

    What is ModSecurity

    ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx that is developed by Trustwave’s SpiderLabs.

    WAF can be enabled in your website to provide an external security layer that increases security, detects, and prevents attacks before they reach web applications, because over 70% of all attacks are now carried out over the web application level.

    It can help detect and prevent many attacks against your web application by checking all HTTP(s) requests you are willing to allow or block (e.g., request methods, request headers, content types, etc.) against its set of rules.

    If the check fails, the visitor will not see the content of your website, predefined actions are performed, usually the visitor will get 403 Forbidden screen.

    What is OWASP CRS

    ModSecurity only is not enough to protect your website. You need to configure an additional rule set to make web protection work.

    The OWASP ModSecurity Core Rule Set (CRS) is a set of generic attack detection rules for use with ModSecurity or compatible web application firewalls.

    The CRS aims to protect web applications from a wide range of attacks, with a minimum of false alerts, including:

    • SQL Injection (SQLi)
    • Cross Site Scripting (XSS)
    • Local File Inclusion (LFI)
    • Remote File Inclusion (RFI)
    • PHP Code Injection
    • Java Code Injection
    • HTTPoxy
    • Shellshock
    • Unix/Windows Shell Injection
    • Session Fixation
    • Scripting/Scanner/Bot Detection
    • Metadata/Error Leakages

    How To Install ModSecurity and OWASP CRS

    If you are very familiar with Linux and want to do it by yourself, you can check Netnea Apache / Modsecurity Tutorial to install ModSecurity & OWASP in your Apache server. Please do so at your own risk, because there will be no support when you have issues on this manual setup.

    In RunCloud, we want to make it very easy for everyone, from beginner to expert, to enable or disable ModSecurity and OWASP CRS in each of your web applications on your servers easily, instead of having to log into the linux terminal to do it.

    Please login to your RunCloud Dashboard, choose your server, go to Web Applications menu and click one of your web applications, and you will see the Firewall menu.

    Click “Enable” to to enable Web Application Firewall (WAF) to your current web application, and click “Save Changes”.

    That’s all. It is very easy!

    You can customize WAF Settings by configuring paranoia level, anomaly threshold, and common rule exclusion.

    Paranoia Level

    Using paranoia level, you can choose the desired level of rule check to protect your web application.

    Higher paranoia levels will strengthen web security, but will also increase the possibility of blocking some legitimate traffic due to false alarms (also named false positives or FPs).

    From OWASP CRS website, there is a detailed explanation about the difference of paranoia levels.

    A paranoia level of 1 (PL1) is default. At this level, most core rules are enabled. PL1 is advised for beginners, installations covering many different sites and applications, and for setups with standard security requirements.

    Paranoia level 2 (PL2) includes many extra rules, for instance, enabling many regexp-based SQL and XSS injection protections, and adding extra keywords checked for code injections.

    PL2 is advised for moderate to experienced users who desire more complete coverage, and for all installations with elevated security requirements.

    Paranoia level 3 (PL3) enables more rules and keyword lists that cover less common attacks. PL3 also tweaks limits on all special characters used, which provides high coverage against unknown attack types, obfuscated attacks, and attempted WAF bypasses.

    PL3 is aimed at users who are experienced at the handling of FPs and at installations with high security requirements.

    Paranoia level 4 (PL4) further restricts special characters.

    PL4 is advised for experienced users protecting installations with very high security requirements.

    Recommended level for most use cases is 1 (default) or 2.

    Anomaly Threshold

    ModSecurity assigns a score for each security risk found in a request (Critical: 5, Error: 4, Warning: 3, Notice: 2).

    Anomaly threshold determines the accumulated score for a request to be blocked.

    Recommended level for production website is 5-10.

    Common Rule Exclusion

    OWASP CRS provides common rule exclusions for some popular Content Management System (CMS), including WordPress, Drupal, NextCloud, DocuWiki, and Xenforo.

    If your current web application uses any of those CMS, please tick in the checkbox to reduce false positives and it will be automatically applied to your firewall.

    Bonus: Custom Firewall Rule Modification

    We also bring firewall rule modification to allow you to have more control on allow or block some traffic, or disable any ModSecurity rule ID.

    Note: This special custom firewall rule modification feature is available only for Business plan users.

    Using this feature, you can control incoming traffic by filtering requests based on Cookie, Country, Hostname, IP Address, URI and more.

    First example, you can use custom firewall rules to block traffic from any country.

    Second example, you can use a custom firewall rule to disable a rule when you see any legitimate traffic get blocked in your server (false positive). You can get CRS Rule ID from Nginx Error Log or ModSec Audit Log.

    You can create multiple custom firewall rule and enable/disable it by toggling ON/OFF button, without having to delete this rule.

    How To Test ModSecurity In Your Website?

    After enabling Web Application Firewall (WAF) in your website, you probably want to know if this firewall works for your website or not.

    You can try to visit this link on your website.

    http://yourawesomedomain/?abc=../../

    Visit this page twice, and you will see 403 Forbidden screen page.

    It means that this visit is blocked by ModSecurity successfully.

    If you use a higher paranoia level and get a lot of 403 Forbidden screen, please change Paranoia Level to 1.

    Nginx Error Log and ModSec Audit Log

    ModSecurity will log any blocked traffic in your website.

    You can check it on Nginx Error Log and ModSec Audit Log in your server.

    In RunCloud, you do not need to login to your server via terminal to check these logs.

    You can simply go to the Web Server Log menu under your Web Application in RunCloud dashboard.

    All blocked traffics will get listed on Nginx Error Log.

    You can check ModSec Audit Log to see the details

    Developer Tips: Custom Nginx Config

    If you are an experienced developer and want to see the custom Nginx config that is applied on your web application when enabling Web Application Firewall, you can go to Nginx Config menu under your web application in RunCloud.

    RunCloud adds two custom Nginx config for Web Application Firewall.

    You can click it to see the configs, but you cannot edit or delete it. It will be automatically deleted when you disable WAF for this web application.

    Summary

    At RunCloud, we are all about making your dev life easier, delivering a fast service, and ensuring your server is managed properly.

    Whether beginner or expert developer, we’ve made enabling or disabling Web Application Firewall (WAF) using ModSecurity and OWASP CRS easy for you.

    ModSecurity and OWASP CRS helps protect your website from many types of attacks against your web application.

    This feature is available to all paid plans (Basic, Pro, Business) for a limited time, and only available for Business plan after.

    This feature has been a requested feature that we knew would be useful to you. Never hesitate to suggest new features that you want to see, and we will make it happen.

  • How To Use NGINX FastCGI Cache (RunCache) To Speed Up Your WordPress Performance

    How To Use NGINX FastCGI Cache (RunCache) To Speed Up Your WordPress Performance

    It is no secret that NGINX FastCGI Cache can drastically increase your WordPress performance by improving server response time and reducing the load on PHP-FPM and MySQL/MariaDB server.

    NGINX FastCGI Cache is usually an advanced topic for developer experts or sysadmins who are familiar with linux commands and the NGINX config.

    In this post, we will enlighten everyone from beginner to expert for this topic, and make NGINX FastCGI Cache (RunCache) as one of your top favourite features in RunCloud.

    What is NGINX FastCGI Cache

    Before we talk about NGINX FastCGI Cache, let’s talk about how your website works.

    1. When a user visits your WordPress page, the web browser sends an HTTP/HTTPS request to NGINX.
    2. NGINX passes the request to PHP-FPM and NGINX will catch any PHP codes when trying to grabbing the page.
    3. PHP-FPM processes the page and runs through the MariaDB/MySQL database query to retrieve the page.
    4. PHP-FPM sends the generated “static” HTML page back to NGINX.
    5. NGINX send the generated HTML page to the web browser for the user.

    When using NGINX FastCGI, this built-in NGINX module will be in between NGINX and PHP-FPM and it is able to generate a cached HTML page from PHP-FPM.

    When another user visits the same WordPress page, your website will not perform the same PHP and database requests again because the page is already cached and served by FastCGI.

    As a result, your server response time will be much faster after the initial load.

    Your PHP-FPM and MariaDB/MySQL load will be reduced.

    Your server CPU resource usage will be lower.

    And finally, your server can handle more traffic with the same server specifications when using NGINX FastCGI Cache, ultimately allowing you to keep a more affordable server without having to scale any further.

    NGINX FastCGI Cache vs Varnish Cache

    When talking about server-side caching mechanism, Varnish is also one of the top popular choices.

    Unfortunately, Varnish is designed to accelerate HTTP and doesn’t support the HTTPS protocol.

    After Let’s Encrypt provides a free SSL/TLS for everyone and Google encourages HTTPS Everywhere and made the move to boost search engine rankings for sites using HTTPS URLS, most websites use HTTPS now for their website to ensure safety from online threats.

    There is a workaround to use Varnish with HTTPS, by adding an SSL/TLS terminator in front of Varnish to convert HTTPS to HTTP.

    NGINX FastCGI does support HTTPS protocol, which is an excellent alternative to Varnish, without having to increase any complexity in the server.

    NGINX FastCGI Cache (RunCache) vs WordPress Cache Plugins

    Many WordPress users ask the same question, which one is better?

    Actually, both are good for your WordPress website.

    When using regular shared hosting, NGINX FastCGI is not available and the only option available is the WordPress cache plugin.

    You will need a VPS / Dedicated server to allow you to optimize your WordPress site using NGINX FastCGI Cache.

    With proper setup, NGINX FastCGI Cache can perform better than any WordPress cache plugin.

    Who Need NGINX FastCGI Cache (RunCache) For WordPress

    All WordPress pages can gain huge benefits when using NGINX FastCGI Cache (RunCache).

    For blogs, magazines, news, company profile websites, and all types of “static” WordPress sites, all WordPress pages can be fully cached and served faster, excluding WordPress admin pages, which are not cached for obvious for reasons.

    For e-commerce, membership, forum, and all types of “dynamic” WordPress sites, most WordPress pages can be fully cached and served faster, except some pages those should stay dynamic.

    For example, in the case of WooCommerce, the homepage, shop page, and single product page can be fully cached, but cart, checkout, and my account pages should be excluded. For these dynamic pages, you can use Redis Object Cache to reduce your MySQL database load and make your dynamic pages load faster, but you do not want to cache these pages fully as the latest changes will not be seen

    How To Install NGINX FastCGI Cache (RunCache) Using RunCloud Hub

    RunCloud Hub is a hub for all RunCloud plugins for WordPress. It is not only for NGINX FastCGI Cache (RunCache), but also Redis Object Cache and Server Health & Transfer Stats monitoring directly from your WordPress dashboard.

    If you want to use NGINX FastCGI Cache (RunCache) to speed up your WordPress website, then RunCloud Hub is the perfect choice for you.

    You can read the complete guide on how to install RunCloud Hub here.

    Once you have installed the RunCloud Hub plugin, NGINX FastCGI Cache (RunCache) is automatically installed and enabled in your WordPress website, no complex process required.

    How To Check If NGINX FastCGI Cache (RunCache) Works

    When using any cache WordPress plugin, usually you can check if your WordPress page has been cached by checking the footprint at the end of your web page source code.

    NGINX FastCGI Cache (RunCache) works on the server-side, which means there is no footprint on your web page,  you need to check the headers of your website to see these possible values of x-runcloud-cache.

    • HIT : Page is cached and served from the cache.
    • MISS : Page is served dynamically from the server, not from the cache. The response might then have been cached. Refreshing this page again should change the header from MISS to HIT or BYPASS.
    • BYPASS : Page is served dynamically from the server, not from the cache. It is excluded from cache, for example WordPress dashboard admin pages or WooCommerce cart/checkout pages.
    • STALE : Page is served from the cache in cache directory.
    • EXPIRED : Cache is expired. Page is served dynamically from server.

    There are many ways to check the headers of your website, for example:

    Check HTTP Headers With KeyCDN Performance Test

    KeyCDN Performance Test is a free online web performance test to test your website from 10+ test location, from United States to Asia areas.

    You can use this tools to evaluate TTFB (Time to first byte) of your website from many locations.

    Using this tool, you can also check the response header to see if this web page is served by NGINX FastCGI Cache (RunCache).

    Check HTTP Headers With Google Chrome

    You can also view the response HTTP headers in Google Chrome by following these steps:

    1. In Chrome, visit your web page, and open Web Developer Tools by pressing F12 or right click and select Inspect.
    2. When opened, click and select the “Network” tab.
    3. Refresh the page to get fresh page data.
    4. Select the top HTTP request on the left panel and observe HTTP headers on the right panel.

    Check HTTP Headers With cURL

    If you are familiar with linux command, you can use cURL to check HTTP headers quickly.

    curl -I http://yourdomain

    Performance Benchmark : Handling More Traffics

    By eliminating PHP-FPM and MariaDB/MySQL when serving your WordPress page from NGINX FastCGI Cache, the huge benefit is your server can handle more traffics with the same server specifications.

    For this test, we use DigitalOcean 1GB RAM ($5) and default WordPress installation using Twenty Nineteen WordPress Theme.

    We use two different tools:

    • Loader.io – load testing
    • New Relic Infrastucture – CPU usage monitoring

    First Test – 25 users per second in 1 minute

    Without NGINX FastCGI Cache (RunCache), average response time is 201 ms.

    With NGINX FastCGI Cache (RunCache), average response time is only 9 ms. It is big improvement!

    Without NGINX FastCGI Cache (RunCache), the CPU usage jump to 50%.

    With NGINX FastCGI Cache (RunCache), the CPU usage is very low.

    Second Test – from 0 to 100 users in 1 minute

    For this test we use Loader.io to send from 0 concurrent user and increasing to 100 concurrent users within 1 minute.

    Without NGINX FastCGI Cache (RunCache), average response time is 1071 ms. You can see that as concurrent users increase, the response time increase also.  Your website will be slow when you have more visitors.

    With NGINX FastCGI Cache (RunCache), the average response time is still low, 14 ms, increasing visitors from 0 to 100 users doesn’t affect too much on the response time.

    Exploring RunCache Features

    Using RunCloud Hub WordPress plugin, you will have more controls on how NGINX FastCGI Cache (RunCache) works in your WordPress website.

    RunCache Purger

    Purger settings allow you to have more control when the cache is cleared, for example:

    • Automatically clean cache of homepage when post is edited or has a new post.
    • Automatically clean cache of homepage when post removed.
    • Automatically clean cache of post/page/CPT when published.
    • Automatically clean cache of post/page/CPT when comment approved and published.
    • Automatically clean cache of post/page/CPT when comment removed.

    RunCache Rules / Exclusion

    Rules settings allow you to control Cache Exclusion.

    Exclude URL Path option allows you to exclude cache based on matching URL Path. This is very useful when you have dynamic pages that should not be cached in your website.

    For example, in WooCommerce, you have the Cart, Checkout, and My Account page that must never be cached. For WooCommerce users, no action needed, these pages have been added by default.

    Exclude Cookie option allows you to exclude cache based on matching Cookie name.

    Exclude Browser option allows you to exclude cache based on matching Browser User-Agent.

    Exclude Visitor IP option allows you to exclude cache based on matching Visitor IP Address.

    RunCache also has dedicated settings for query strings, because query strings will not cache by default.

    Allow Cache Query String option make it possible for you to allow cache based on matching query string, for example UTM parameters (utm_source, utm_medium, utm_campaign), fbclid, gclid, etc.

    Exclude Cache Query String option allows you to exclude cache based on matching Query string.

    RunCache Preload

    Preload settings allow you to generate caches of your pages without having to wait for a user to visit your pages. Normally, cache is generated after a user visits a page.

    You have the options to:

    • Preload caches automatically when any purge action was triggered.
    • Preload caches automatically based on schedule time (day/week/month).
    • Preload caches manually by clicking “Run Cache Preload” link.

    If you have big number of posts / pages / products in your WordPress sites, cache preload process somestimes can consume your server CPU resources. It is better to run cache preload manually for this case.

    Is It Compatible With Popular WordPress Cache / Optimization Plugins?

    Short answer, YES!

    The important thing to understand, NGINX FastCGI Cache (RunCache) works on the server level and popular WordPress cache / optimization plugins work on the WordPress/application level.

    They are in different spaces and it should be compatible.

    When you use both page caching feature from RunCache and your favourite cache plugin, it is possible if NGINX FastCGI Cache (RunCache) stores the caches from generated caches of the cache plugin, it doubles the page cache.

    You can choose to disable the page cache feature from your WordPress cache / optimization plugins if you find any issue with RunCache.

    For page cache use cases, RunCache should be faster because once your website page cache is available, it will be served to your visitor directly from your server without WordPress.

    If you do not want to use any cache plugin and fully use RunCache, you can still use any optimization plugin, for example Autoptimize, to minify HTML, CSS, and Javascript files in your website.

    Summary

    In RunCloud, we provide you with full control over your server. That is why we do not apply any server-side caching mechanisms automatically to your server.

    If you want to apply server-side caching to one of your web applications within your server, then RunCache (RunCloud Hub) is your answer.

    RunCache allow you to utilize NGINX FastCGI Cache to speed up your WordPress performance without having to deal with linux command to setup NGINX FastCGI Cache.

    All paid plan users (Basic, Pro, Business) can enjoy the full functionality of this feature.

    It has been a largely requested feature that we knew would be useful to you and we are very excited to bring this feature to RunCloud. Never ever hesitate to suggest new features that you want to see, and we will make it happen.

  • How To Install ImageMagick PHP Extension (Imagick)

    How To Install ImageMagick PHP Extension (Imagick)

    Do you want to manipulate images in various ways without using complex tools or libraries? If you answered yes, then you need to know about ImageMagick, a powerful and versatile image processing software that works seamlessly with PHP web applications.

    Even if you are using a CMS or a framework such as WordPress or Laravel for building your website, you may need to install the ImageMagick PHP extension for advanced image processing.

    In this post, we will show you how to install ImageMagick PHP Extension (Imagick) for your PHP web application on RunCloud, the best web application management platform for developers and agencies.

    Note: If you are using RunCloud Docker, you can install ImageMagick and many other PHP extensions for your Docker containers with a few simple steps. Follow our dedicated tutorial to learn how to install ImageMagick PHP extension on RunCloud Docker.

    What is ImageMagick

    ImageMagick is a free and open-source software that was created in 1987 by John Cristy to create, edit, compose, or convert bitmap images.

    It can read and write over 200 image formats, including PNG, JPEG, GIF, HEIC, TIFF, DPX, EXR, WebP, Postscript, PDF, and SVG.

    You can use ImageMagick to resize, flip, mirror, rotate, distort, shear and transform images, adjust image colors, apply various special effects, or draw text, lines, polygons, ellipses and Bézier curves.

    ImageMagick vs GD Library

    ImageMagick is not the only image optimization library in PHP application.

    GD is another library that is also very popular and it is automatically available in RunCloud server.

    Both ImageMagick and GD Library can be used for:

    • Resize / crop images
    • Apply filters to image, for example color, contrast, brightness, etc.
    • Adding content to image, for example text, shape, other image (watermark), etc.
    • Compress images
    • Convert images to different file types

    The key differences between ImageMagick and GD library are:

    • ImageMagick supports over 100 major image formats
    • ImageMagick usually produces better quality images, although sometimes better quality image will also increase the image file size
    • GD is widely available and usually enabled by default, but you have install and enable ImageMagick

    How to Install ImageMagick PHP Extension

    On WordPress, you might want to use the ImageMagick Engine WordPress Plugin for processing resizing and cropping images in WordPress dashboard.

    When ImageMagick is not installed on the server, you will see “ImageMagick PHP module not found” warning on the plugin Settings page.

    runcloud-imagemagick-01-imagick-php-module-not-found2

    Disclaimer: This tutorial is intended for Ubuntu and Debian based distributions only. If you are using Fedora, RHEL, Windows, or Mac, please refer to the official ImageMagick website for installation instructions.

    The first step to install ImageMagick is to check the PHP version of your web application. This is because the installation process varies depending on the PHP version. However, once you have installed ImageMagick for a certain PHP version, it will work for all web applications that use the same PHP version on your server.

    You can find the PHP version of your web application in your RunCloud dashboard.

    Imagick PHP Module for PHP version X.X

    1. To install ImageMagick PHP extension for any PHP version on your server, you need to log in to your server as a root user using Terminal (Mac OSX / Linux) or Powershell / Putty (Windows).
    ssh root@<youripaddress>
    1. Next, you need to run this command, replacing <version> with the specific PHP 8.x version that you want to install ImageMagick for. For example, if you want to install ImageMagick for PHP 8.1, you would replace <version> with 81.
    apt-get install php<version>rc-pecl-imagick
    1. After the installation is complete, you need to reload the PHP-FPM service on your server by running this command, again replacing <version> with the specific PHP 8.x version that you installed ImageMagick for.
    systemctl reload php<version>rc-fpm
    1. To verify that ImageMagick is installed and activated, you can run this command, which will display the ImageMagick version and configuration:
    /RunCloud/Packages/php<version>rc/bin/php -i | grep imagemagick

    For example, if your website uses PHP 8.0, your commands should look something like.

    # install imagick module
    apt-get install php80rc-pecl-imagick
    
    # reload PHP-FPM
    systemctl reload php80rc-fpm
    
    # check / verify if imagick is installed
    /RunCloud/Packages/php80rc/bin/php -i | grep imagemagick

    Similarly, for website using PHP 7.4, the commands should look like.

    # install imagick module
    apt-get install php74rc-pecl-imagick
    
    # reload PHP-FPM
    systemctl reload php74rc-fpm
    
    # check / verify if imagick is installed
    /RunCloud/Packages/php74rc/bin/php -i | grep imagemagick

    If ImageMagick has been installed correctly, you will get an output similar to the following image.

    imagemagick succesfully installed

    After installing ImageMagick correctly, you can see the warning disappear in ImageMagick Engine WordPress Plugin.

    Optional: Adding PDF Support To ImageMagick

    If you want to allow ImageMagick to process PDF files, you will have to login as root user again to your server and edit policy.xml.

    For example, you can use nano to edit this file by running this command.

    nano /etc/ImageMagick-6/policy.xml

    Then please scroll down and locate this line.

      <policy domain="coder" rights="none" pattern="PDF" />

    You need to disable it by commenting out that line. For example, you can replace that line by following line.

      <!-- <policy domain="coder" rights="none" pattern="PDF" /> -->

    Please save the file and exit the editor.

    Then reload the PHP-FPM again, for example for PHP 8.1 you can run this command again.

    systemctl reload php81rc-fpm

    NOTE: Please be careful when you enable PDF support for Imagick. Make sure you always use it with trusted PDF files.

    How Does WordPress Use the Imagick PHP Extension?

    WordPress supports both ImageMagic and GD Library for PHP image processing extensions to resize and crop images in your website.

    By default, WordPress will try to use ImageMagick. If it is not available or it doesn’t support the requested mime-type, WordPress will use the GD extension.

    If you need more control of the quality of re-sized images, you can use ImageMagick Engine WordPress Plugin.

    Image Watermark WordPress plugin is another cool plugin that allows you to watermark each image that you upload to your WordPress site using Imagick.

    If you enable PDF support for the Imagick PHP extension, you will get one extra bonus, WordPress will automatically generate an image for each PDF you upload to your WordPress site!

    How Does Laravel uses ImageMagick PHP Extension?

    If you use Laravel for your website, there are some libraries that you can use for image processing. Let’s take a look:

    1. Intervention Image is an open-source PHP image handling and manipulation library. It provides an easier and more expressive way to create, edit, and compose images and supports currently the two most common image processing libraries GD Library and Imagick.
    2. PDF to image is a library that makes it easy to work with the PDF files and helps convert PDF files to images using Imagick and Ghostscript.

    FAQs

    • What is the difference between ImageMagick and Imagick?

      ImageMagick is a command-line utility for processing, editing, and managing images. It is available for all different kinds of operating systems, and you can use it as a standalone application or a library. ImageMagick supports hundreds of image formats and can perform a wide range of image manipulation operations, such as resizing, cropping, color correction, watermarking, and more.

      Imagick is a PHP extension of ImageMagick. It provides a native implementation of the ImageMagick API for PHP, which means you can use ImageMagick’s features and functions within your PHP scripts. Imagick is useful for creating dynamic images, generating thumbnails, applying filters, and other tasks that require image processing in PHP.

      To use Imagick, you need to have ImageMagick installed on your server and enable the Imagick extension in your php.ini file.

    • What is GD in WordPress?

      GD is a PHP extension that can handle image processing in WordPress. It is similar to Imagick, but it has some limitations, such as supporting fewer image formats and producing lower-quality images. However, GD is more widely available on web hosting servers and may be faster than Imagick in some cases.

      To use GD in WordPress, you need to have it installed and enabled on your server. You can check if GD is available by using the phpinfo() function.

    • What PHP Extensions does WordPress need ?

      These are essential PHP extensions for WordPress:
      json: Handles communication with other servers and processes data in JSON format.
      mysqli or mysqlnd: Connects to the MySQL database for content storage and user data management.
      curl: Performs remote requests.
      dom: Validates Text Widget content and configures IIS7+.
      exif: Works with image metadata.
      fileinfo: Detects file upload mimetypes.
      hash: Used for hashing (including passwords).
      igbinary: Optimizes serialization.
      imagick: Enhances image quality.
      intl: Enables locale-aware operations.
      mbstring: Handles UTF8 text.
      openssl: For SSL-based connections.
      pcre: Improves pattern matching.
      xml: Used for XML parsing.
      zip: Handles zip archives.
      These extensions empower WordPress, ensuring seamless functionality and compatibility with plugins and themes. 🌟🔧

    • How to Install ImageMagick in cPanel?

      To install ImageMagick in cPanel, log in to WHM using your root credentials.
      Navigate to the Software tab and select Module Installers.
      Click Manage next to PHP PECL, search for “Imagick,” and click Install.

    • Do I need Imagick for WordPress?

      Imagick is not strictly required for a basic WordPress installation, but it significantly enhances image quality and functionality. If you plan to work extensively with images, such as resizing, optimizing, or creating thumbnails, Imagick is highly recommended.

    • How to Fix ImageMagick PHP module not found?

      To fix the ImageMagick PHP module issue on WordPress, you need to install and enable the module on your server using cPanel, SSH, or web hosting support. Then, you can check the module status on your WordPress dashboard under “Tools” > “Site Health”.

    Summary

    In this post, we will walked you through the steps to install the ImageMagick PHP extension for your web application on RunCloud, the best web application management platform for developers and agencies. If you are looking to move away from Cpanel then you should check out RunCloud.

    If you are not using RunCloud yet, you are missing out on a lot of benefits and features that can make your web development and hosting experience easier and faster. With RunCloud, you can host as many websites as you like on a single server.

    Sign up for RunCloud today to see how RunCloud can help you manage your web applications and servers with ease and convenience.