RunCloud CMS

Author: RunCloud Team

  • 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.

  • RunCloud One-Click Droplet is Now Available on DigitalOcean Marketplace

    RunCloud One-Click Droplet is Now Available on DigitalOcean Marketplace

    We are happy to announce that RunCloud One-Click Droplet is available on DigitalOcean Marketplace.

    RunCloud One-Click Droplet allows you to spin your new DigitalOcean servers with RunCloud images and straightly manage your servers inside RunCloud Panel afterward.

    No need to connect your droplet through IP Address or spin the server inside our panel again.

    Step 1. Create Your RunCloud One-Click Droplet

    Login to your DigitalOcean account and create your droplet.

    Instead of choosing Ubuntu 16.04/18.04/20.04, you can click Marketplace tab and search for RunCloud.

    There is a RunCloud image in DigitalOcean Marketplace, RunCloud-20.04 with Ubuntu 20.04 LTS. Select it then continue the process to create a droplet.

    For authentication, you can choose to use root password or SSH keys. For this example, we will create root password for our new droplet.

    Once the droplet is created, you will see your new droplet with RunCloud logo.

    Step 2. Connect Your DigitalOcean Server To RunCloud Account

    RunCloud generate a verification link that is accessible via SSH. It allows you to claim the server and add it to your RunCloud account.

    Login to server via SSH

    Please login to your server as the root user using Terminal (Mac OSX / Linux) or Powershell / Putty (Windows). Please change “youripaddress” with the IP Address of your server.

    ssh root@youripaddress

    Get or copy the verification URL

    After you have logged in to your server, you can see the verification URL to claim your server.

    This verification URL will be valid only for 24 hours.

    Register / login to RunCloud

    It is recommended that you have a RunCloud account before using RunCloud One-Click Droplet.

    If you did not have an account yet, you can register here for free.

    Open the verification URL to claim your server

    After you have logged in to your server, you can open the verification URL in your browser.

    Add the server name and click “Claim This Server” button to claim your ownership of the server.

    After few moments, you will redirected to your Droplet/Server summary page.

    Congratulations! Claim process was successful and you can start manage your droplet via RunCloud Panel.

    Walkthrough Video

    Summary

    RunCloud is a cloud server management tool that allows you to maintain full control of your server and host multiple web applications with fast and easy configuration. With RunCloud, you don’t need to be a Linux expert to host your website, powered by DigitalOcean.

    With this RunCloud One-Click Droplet release, you can have 4 different ways to setup your DigitalOcean servers using RunCloud.

    1. RunCloud One-Click Droplet, spin your RunCloud servers directly from your DigitalOcean dashboard.
    2. Direct Server Provisioning using DigitalOcean API, spin your DigitalOcean servers directly from RunCloud dashboard.
    3. Direct Server Installation via IP Address and root password
    4. Manual Server Installation via IP Address

    RunCloud One-Click Droplet is the fastest one because no need to do an extra step to setup your server with RunCloud.

  • 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.

  • RunCloud Supports Ubuntu 20.04 LTS (Focal Fossa)

    RunCloud Supports Ubuntu 20.04 LTS (Focal Fossa)

    We are happy to officially support Ubuntu 20.04 LTS (Focal Fossa) in RunCloud.

    You are able to connect Ubuntu 20.04 LTS to RunCloud through IP Address installation.

    What is Ubuntu LTS

    Ubuntu LTS (Long Term Support) versions are released every 2 years and are guaranteed to receive support for at least 5 years after release.

    LTS releases are the ‘enterprise grade’ releases of Ubuntu and are utilised the most. An estimated 95% of all Ubuntu installations are LTS releases.

    ubuntu 20.04

    The previous LTS version, Ubuntu 18.04 LTS, will stop receiving updates after April 2023. Ubuntu 18.04 LTS will receive security fixes and critical updates until April 2028.

    Ubuntu 20.04 LTS, codenamed Focal Fossa, is the latest Long Term Support release and was released on 23 April 2020, and will get maintenance updates for 5 years, until April of 2025.

    What’s New In Ubuntu 20.04 LTS For RunCloud?

    Generally, an Ubuntu LTS contains only a few major changes for a server.

    You can refer to the Ubuntu 20.04 LTS release notes for new features.

    Linux Kernel 5.4

    Ubuntu 20.04 TLS is based on the long-term supported Linux kernel 5.4.

    Notable features and enhancements in linux kernel 5.4 are:

    • Since kernel 5.3, it supports new hardware including Intel Comet Lake CPUs and initial Tiger Lake platforms, AMD Navi 12 and 14 GPUs, Arcturus and Renoir APUs along with Navi 12 + Arcturus power features.
    • Since kernel 4.15, it supports AMD Rome CPUs, Radeon RX Vega M and Navi GPUs, Intel Cannon Lake platforms.
    • Boot speed improvements through changing the default kernel compression algorithm to lz4 (in Ubuntu 19.10) on most architectures, and changing the default initramfs compression algorithm to lz4 on all architectures.

    Supported PHP Versions

    Ubuntu 20.04 LTS on the RunCloud servers only supports PHP 7.2, 7.3, and 7.4 when this article is published.

    If you still want to use PHP 7.0 or 7.1, please use Ubuntu 16.04 LTS (Bionic Beaver).

    Ubuntu 16.04 vs 18.04 vs 20.04 Comparison

    Starting from today, RunCloud officially supports Ubuntu 16.04 LTS, Ubuntu 18.04 LTS, and Ubuntu 20.04 LTS.

    You can find a comparison between these OS in the RunCloud servers.

    OSUbuntu 16.04 LTSUbuntu 18.04 LTSUbuntu 20.04 LTS
    Code NameXenial XerusBionic BeaverFocal Fossa
    Released Date2016-04-212018-04-262020-04-23
    Available PHP Version7.4
    7.3
    7.2
    7.1
    7.0
    5.6
    5.5    		7.4
    7.3
    7.2
    7.1
    7.0    		7.4
    7.3
    7.2
    Initial Kernel Version4.44.155.4
    Standard support until2021-042023-042025-04
    Extended Security Maintenance Until2024-042028-042030-04

    Upgrade From Ubuntu 16.04/18.04 to 20.04???

    Do you need to upgrade from Ubuntu 16.04/18.04 LTS to Ubuntu 20.04?

    Short answer, NO!

    We do not recommend upgrading Ubuntu to a new major release at all.

    Upgrading to a major release could break all of your website on that server, it will also remove RunCloud agent, and it makes your server no longer connected to RunCloud anymore.

    If you have a RunCloud server with Ubuntu 16.04 or 18.04, please stay with this OS version, do not upgrade it to Ubuntu 20.04.

    RunCloud provides your Ubuntu 16.04 or 18.04 servers with the latest Ubuntu security updates, and takes care of this automatically for you, so you do not have to worry about anything.

    If you want to try to use Ubuntu 20.04 LTS for your current web application, please connect a fresh Ubuntu 20.04 server to RunCloud and use our Clone Web App feature to clone your web app to your new Ubuntu 20.04 server.

    Connect Ubuntu 20.04 Server To RunCloud

    RunCloud provides three different methods to connect your server to RunCloud.

    • Direct Server Provisioning using server provider API
    • Direct Server Installation via IP Address and root password
    • Manual Server Installation via IP Address

    For Ubuntu 20.04, currently, we support Direct Server Installation and Manual Server Installation via IP Address installation.

    Direct Server Provisioning for each supported Server Provider will be available soon.

    Direct Server Installation via IP Address and root password

    Using the direct server installation method, you only need to create a server with fresh Ubuntu 20.04 install, input your server IP address and root password, then sit back and relax, our direct server installation will setup your server in minutes.

    Manual Server Installation via IP Address

    Using the manual server installation method, you only need to create a server with fresh Ubuntu 20.04 install, login to your server console as root user, run RunCloud installation script, then sit back and relax, our manual server installation will setup your server in minutes.

    Summary

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

    With Ubuntu 20.04 LTS support, you are able to connect Ubuntu 20.04 LTS to RunCloud through IP Address installation.

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

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

  • 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.

  • How To Install Mautic Marketing Automation Software in RunCloud (2020 Update)

    How To Install Mautic Marketing Automation Software in RunCloud (2020 Update)

    Mautic is powerful marketing automation software. It is free and it is also the world largest open-source marketing automation project.

    More than 200.000+ organizations use Mautic. It makes Mautic an excellent choice if you want to run email marketing campaigns and marketing automation directly from your server, with full total control.

    runcloud-mautic-13-dashboard

    In this post, we will discuss about how to install Mautic using RunCloud easily.

    Get Your Cloud Server And Connect To RunCloud

    Cloud server is the best choice when you want to run your business with Mautic. It makes Mautic stable and also scalable. When your business start growing and Mautic needs more server resources, you can increase the resources (RAM/CPU) of your cloud server easily, anytime.

    Five dollar ($5) cloud server from DigitalOcean / Linode / Vultr / UpCloud / other provider is more than enough to start using Mautic.

    Quick guide on how to setup and connect your server to RunCloud

    Create PHP Web Application In RunCloud

    After setup and connect your server to RunCloud, you can create PHP web application to install Mautic.

    Using RunCloud, you can create multiple website (web applications) in one server. Basically you can install Mautic on the same server where you host your other websites using RunCloud.

    Go to “Web Application” menu under your server in RunCloud, and click “Create Web App” button.

    runcloud-mautic-01-create-new-php-webapp

    Let’s create your PHP web application for Mautic.

    For “Web Application Name“, you can use “mauticapp“.

    For “Domain name“, you can use either your own domain/subdomain or RunCloud test domain. For this example, we will use RunCloud test domain.

    If you decide use your own domain, you will need to do an extra step to configure DNS record and wait for DNS propagation.

    You can read our quick guide on how to add your domain.

    For “Web Application Owner“, you can create new “mauticuser” system user.

    It is best practice to use different system user for different web application in the same server, for extra security purpose.

    runcloud-mautic-03-php73-version-advanced-settings

    For “PHP Version“, you can select PHP7.3 to install Mautic v2.16 stable release. Please do not use PHP7.4 because Mautic still do not officially support it.

    For “Web Application Stack“, you can choose “Nginx + Apache2 Hybrid” to allow you use .httaccess file in Mautic.

    Please click “Advanced Settings” checkbox to configure some extra settings to make your Mautic installation run smoothly.

    For date.timezone, you can select your current timezone where you run your business.

    For disable_functions, it is optional, you can remove all php_posix functions from the list.

    The php_posix is disabled by default inside RunCloud for security reason. For Mautic installation, it is just a recommendation to enable php_posix, not a requirement. But if you really want to enable php_posix, you can replace all the disable_functions with the text below.

    getmyuid,passthru,leak,listen,diskfreespace,tmpfile,link,ignore_user_abord,shell_exec,dl,set_time_limit,exec,system,highlight_file,source,show_source,fpassthru,virtual,proc_open,proc_close,proc_nice,proc_terminate,escapeshellcmd,ini_alter,popen,pcntl_exec,socket_accept,socket_bind,socket_clear_error,socket_close,socket_connect,curl_multi_exec,symlink,ini_alter,socket_listen,socket_create_listen,socket_read,socket_create_pair,stream_socket_server

    For max_execution_time, please increase the value to 120 to avoid any timeout / error issue on the installation process.

    Then, click “Add Web Application” button to create your PHP web application for Mautic.

    Prepare Mautic Installer

    There are two ways to prepare Mautic installer:

    1. Download Mautic installer files and upload it to your web application using SFTP.
    2. Download and extract Mautic installer files using SSH.

    In this post, we will show you the second way, using SSH.

    You need to login to your server using SSH from either Terminal (Mac/Linux) or PowerShell / Putty (Windows).

    If you want to login using password, not using SSH key, you will need to change the password of “mauticuser” system user that you have created from System User menu.

    If you use Terminal, you can run this command to login to your server.

    ssh mauticuser@<youripaddress>

    You will login to your server using “mauticuser” system user, not root. Please change “youripaddress” with the IP Address of your server.

    NOTE: Please do not login using “root”, to avoid any file/folder permission issue.

    Change the working directory to your “mauticapp” web application root path.

    cd webapps/mauticapp

    Download the Mautic script. The download might be a bit slow. Just wait for it to finish.

    wget https://www.mautic.org/download/latest -O mautic.zip

    Unzip/extract the downloaded file.

    unzip mautic.zip

    Run Mautic Installer

    After preparing your Mautic installer, you can visit your domain/subdomain where you install Mautic.

    Mautic recommends to secure your installation with an SSL certificate. You can skip this step if you use RunCloud free domain.

    If you use your own domain/subdomain, you can install Let’s Encrypt SSL Certificate to your website. You can read our quick guide to secure your website with HTTPS.

    Click “Next Step” button.

    Mautic Installation – Database Setup

    runcloud-mautic-09-database-setup

    You need to create MySQL database to install Mautic. Go to “Database” menu under your server in RunCloud.

    runcloud-mautic-06-create-database

    Click “Create Database” button and create new “mauticdb” database.

    runcloud-mautic-07-create-database-user

    Click “Create Database User” button and create new “mauticdbuser” database user.

    Then click “Grant User” button in your “mauticdb” database to connect it to “mauticdbuser” user.

    Now you continue database setup process using database name and user that you have created.

    Click “Next Step” button.

    Mautic Installation – Administrative User

    In this step, you can create the admin user for your Mautic installation.

    Click “Next Step” button.

    NOTE: If you get Error 500 screen after clicking “Next Step” button, it is possible because you have permission issue or you do not increase max_execution_time when creating PHP web application above.

    You can fix it by running this command on your web application root path.

    rm -rf app/cache/*
chmod 777 app/cache
php app/console cache:warmup

    Mautic Installation – Email Configuration

    In this step, you can setup Mautic email configuration. Mautic support sending email using PHP Mail, but we highly recommend you to use third party SMTP, for example SendGrid, Mailgun, or Amazon SES.

    You can skip this step for now and setup email configuration later from your Mautic dashboard.

    Click “Next Step” button.

    Perfect!

    When you see Mautic login screen, it means you have installed Mautic successfully!

    Setup Mautic Cron Jobs

    Mautic requires some cron jobs to run some maintenance tasks. You need to setup cron jobs to make sure Mautic can run properly.

    Fortunately, you can add cron jobs easily using RunCloud.

    Go to “Cron Job” menu under your server in RunCloud, and click “Create” button to create our first Mautic cron job.

    Cron Job – Updating Contact Segments (Required)

    runcloud-mautic-14-setup-cron-job

    For “Job Label”, add mautic:segments:update

    For “User”, add mauticuser, your system user for this Mautic web app.

    For “Vendor Binary”, select /RunCloud/Packages/php73rc/bin/php because you use PHP7.3 for this Mautic web app.

    For “Command”, copy paste this command below.

    /home/mauticuser/webapps/mauticapp/app/console mautic:segments:update

    NOTE: Please update this command if you use different system user (not mauticuser) and web application name (not mauticapp).

    Because Mautic use multiple cron jobs, it is HIGHLY recommended that you stagger the required jobs so as to not run the exact same minute.

    For “Minute”, please use 0,15,30,45 to run this cron job every 15 minutes. We will use different minutes for different cron jobs.

    Click “Create Cron Job” button.

    Cron Job – Updating Campaigns (Required)

    Please repeat the process for following cron job.

    Label : mautic:campaigns:update

    Campaign :

    /home/mauticuser/webapps/mauticapp/app/console mautic:campaigns:update

    Minute : 5,20,35,50

    Cron Job – Executing Campaign Events (Required)

    Please repeat the process for following cron job.

    Label : mautic:campaigns:trigger

    Campaign :

    /home/mauticuser/webapps/mauticapp/app/console mautic:campaigns:trigger

    Minute : 10,25,40,55

    Cron Job – Processing Email Queue (Optional)

    Please repeat the process for following cron job.

    Label : mautic:emails:send

    Campaign :

    /home/mauticuser/webapps/mauticapp/app/console mautic:emails:send

    Minute : 2,17,32,47

    Perfect!

    You have completed cron jobs setup for Mautic.

    Please check this article if you want to setup other optional cron jobs in Mautic.

    Summary

    If you want to use Mautic for your marketing automation software, using RunCloud and cloud server is a perfect combination to install and run Mautic Marketing Automation Software.

    Are you using Mautic with RunCloud? Do not hesitate to share your experience with us.

  • How To Use Redis Object Cache To Speed Up Dynamic WordPress Site

    How To Use Redis Object Cache To Speed Up Dynamic WordPress Site

    With RunCloud, you don’t need to be a Linux expert to host high-performance WordPress websites, both “static” WordPress sites (simple blog) and “dynamic” WordPress sites (WooCommerce and membership).

    For any types of highly dynamic websites, you can use Redis Object Cache to use less database resources by caching the results of complex database queries, speed up PHP execution time in your server, and make your dynamic website load much faster.

    In this blog post, we will explain Redis Object Cache, which is probably not a term that many WordPress users are familiar with.

    WordPress Caching System

    WordPress users usually understand at least two caching systems: page caching and browser caching.

    Actually, there are many caching system in WordPress, for example:

    • page caching
    • browser caching
    • database caching
    • object caching
    • transient caching
    • fragment caching
    • opcode caching
    • CDN caching

    In RunCloud, we divide them into three types:

    1. Server-side Caching: caching at the server level. NGINX page caching (RunCloud Hub) and Varnish page caching are two examples of server-side caching.
      • They are not available on regular shared hosting.
      • You will need a VPS / Dedicated server to allow you to optimize your website using server-side caching.
      • Another example of server-side caching is “persistent” object caching.
    2. WordPress-side Caching: caching at the WordPress level. Page caching feature of many popular caching WordPress plugins is one example of WordPress-side caching.
      • You can control it from your WordPress dashboard.
    3. Client-side Caching: caching at the local browser level. Browser cache is an example of client-side caching.
      • Once you visit your website, your browser saves the static data of your website, such as images, CSS, and javascript files.
      • Everytime you visit your website again or hit the F5 button to refresh your website, static data will be served from the local browser cache.

    For this post, we will only be covering the object cache, specifically Redis Object Cache.

    What is Redis Object Cache

    If page caching works on caching the HTML page output, then object caching works on caching your database queries.

    WordPress has special WP_Object_Cache class for caching the result of complex database queries, which may be computationally expensive to regenerate, to reduce your server load.

    By default, the object caching is non-persistent, data stored in the cache resides in memory only and only for the duration of the request.

    We can make it persistent, cached data can be used across page loads, by using persistent object caching system, for example:

    • Redis Object Cache
    • Memchached Object Cache
    • APC / APCu Object Cache
    • File-based Object Cache

    Redis Object Cache is the first choice because it is very popular and used by many popular websites like Twitter, GitHub, Weibo, Pinterest, Snapchat, Craigslist, Digg, StackOverflow, Flickr, and many others.

    When a user visits a WordPress page, many complex database queries are performed on your server and the results are cached by Redis Object Cache.

    When another user visits the same WordPress page, your website will not perform the same complex database queries again, because the results are already cached and served by the Redis Object Cache.

    It will reduce your database queries, reduce your server load, and make your dynamic WordPress site load faster.

    Who Need Redis Object Cache

    Page caching is enough for many WordPress sites, especially for blogs, magazines, news, and company profile websites.

    But if your WordPress site has many dynamic pages, page caching will be not enough because your dynamic pages should be not cached using page caching.

    For example, Redis Object Cache will be very useful for these dynamic websites to reduce your MySQL database load and make your dynamic pages load faster.

    • E-commerce websites using WooCommerce, Easy Digital Downloads, etc. Your cart, checkout, and my account pages are dynamic pages.
    • Membership websites. Your member area and some password protected pages are dynamic pages.
    • Forums and Social Networking websites using BBPress, BuddyPress, etc.

    How To Use Redis Object Cache

    Redis Object Cache is a server-side caching, and it requires Redis to be installed and activated in your server.

    For RunCloud users, there is no need to install Redis yourself, as Redis has been installed to your server.

    It saves your time dealing with the linux command to install Redis. It can be complicated for common users with minimum linux knowledge.

    In RunCloud, there are two ways to use Redis Object Cache.

    1. RunCloud Hub WordPress Plugin
    2. Redis Object Cache WordPress Plugin

    How To Install Redis Object Cache Using RunCloud Hub

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

    If you want to use a combination of Nginx page caching and Redis object caching, 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, Redis Object Cache is automatically installed and enabled in your WordPress website, no complex process required.

    runcloud-redis-object-cache-runcloud-hub

    You can also disable Redis Object Cache temporarily by unchecking “Handle Object Cache” option under Redis settings in RunCloud Hub page.

    How To Install Redis Object Cache Using Redis Object Cache WordPress Plugin

    If you do not want to use RunCache (Nginx page caching) in RunCloud Hub, and only want to use Redis Object Cache, you can use Redis Object Cache WordPress Plugin.

    First, you need to run Redis on your RunCloud server. Redis has been installed in your server, but it is probably inactive. Go to Services menu under your server in RunCloud, and enable Redis.

    Second, install and activate Redis Object Cache WordPress Plugin.

    Third, enable the object cache under Settings – Redis, or in Multisite setups under Network Admin – Settings – Redis.

    runcloud-redis-object-cache-wordpress-plugin

    Note: If you use Redis Object Cache in multiple websites (web applications) in single RunCloud servers, you have to add WP_CACHE_KEY_SALT constant to wp-config.php of each web applications. Please read plugin documentation for more details.

    How To Check If Redis Object Cache Works

    Redis Object Cache works by reducing your complex database queries. We can monitor and compare the database queries before and after using Redis Object Caches.

    You can install and activate Query Monitor WordPress plugin to help you monitor the number of database queries in a WordPress website.

    In this example, we use a default WordPress installation with Twenty Nineteen WordPress theme.

    runcloud-redis-object-cache-dashboard-before
    Redis Object Cache in WordPress Dashboard page (BEFORE)
    runcloud-redis-object-cache-dashboard-after
    Redis Object Cache in WordPress Dashboard page (AFTER)

    In WordPress dashboard, Redis Object Cache can reduce the number of database queries from 25 to 10 queries only.

    runcloud-redis-object-cache-frontend-before
    Redis Object Cache in WordPress Homepage (BEFORE)
    runcloud-redis-object-cache-frontend-after
    Redis Object Cache in WordPress Homepage (AFTER)

    In WordPress homepage, Redis Object Cache can reduce the number of database queries from 18 to 5 queries only.

    You can imagine when you use Redis Object Cache in a WooCommerce (ecommerce) website, where the number of database queries in your WordPress can be 50-100 queries per page, Redis Object Cache can help a lot!

    Summary

    Redis Object Cache is a very useful feature to speed up dynamic WordPress sites, especially ecommerce (WooCommerce) and membership sites by reducing database load to make your dynamic pages load faster.

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

    Never ever hesitate to suggest new features that you want to see, and we will make it happen.

  • How to Easily Clone a Web Application in RunCloud

    How to Easily Clone a Web Application in RunCloud

    Cloning a website is not an easy task and requires some knowledge of FTP, sFTP, or SSH. From there, you will need to backup all files, any databases, copy those files, move them to the new server, import the database into a new server, change over your WordPress configuration file information, update the database to reflect any of those changes, update WordPress settings to match the old website, checking to ensure everything was copied over, and so on and so forth. You get the point that this is a painfully tedious process for any user and can be very time-consuming, especially where there are multiple websites involved.

    We are introducing a Clone Web Application feature in RunCloud to clone your website (web application) easily.

    Cloning A Website (Web Application) in RunCloud

    This feature allows you to clone a web application within the same server or clone it to a different server within your RunCloud account.

    And we support cloning both custom PHP web applications and WordPress web applications. It means you can clone an existing web application within your RunCloud account.

    You can find “Clone Web App” in the menu under Tools menu within your RunCloud web application.

    Cloning A Web Application To A Different Server

    For the advanced, cloning a web application to the same server might involve some Linux commands and an import of the database, but to move it to a completely different server entirely might take some time and knowledge. We make it easier for you.

    If you clone a WordPress web application or PHP application (for example Laravel) that has a database, you don’t want to forget to clone the database in the process. Missing a table from the database or an important file can cause errors and prevent a website from functioning.

    After you have clicked the Clone Web App button, you will be taken into a screen that will allow you to set which server you would like to clone to, the port to use, the web application owner, and the settings for the database. Once you have entered in all of this information, click Clone Webapp to Server button to start the process.

    While cloning is not an instant process, RunCloud takes care of the entire process making your life easy with just a few button clicks. When cloning a web application to a different server, an exact copy of your web application will be transferred using the same configurations. The whole process takes just a few moments to clone all of your files, the database, and WordPress settings.

    You can even monitor the progress by clicking on the Notification icon at the top right.

    Done! Now your web application has been cloned to a different server within your RunCloud account.

    If you want to switch your live website to this cloned web app, you need to continue with by changing your A records in your DNS management service. Do not forget to check your domain name settings and also re-deploy Let’s Encrypt SSL/TLS in your cloned web app if you want to secure it with HTTPS.

    Cloning A Web Application Within The Same Server

    Cloning a web application within the same server is useful, for example, if you want to create a different project from an existing web app, without starting from scratch.

    If you use WordPress and you want to clone your web app for development purposes, do not use this feature, as it is better to use One-Click WordPress Staging that will give you additional features to sync/merge between your production and staging website.

    However, if you want to create an entirely new website that is similar, but might contain different content, such as a website branching off another, you might consider using this feature.

    Another use case might be if you are teaching a classroom of students and setting up a server, and you want all of the students to use the same website setup, then you could clone the website multiple times to the same server.

    When cloning web applications within the same server, it is highly advised to make sure to use a different name for both web application and database name. Upon finalizing the setup, click “Clone this webapp” button to begin the process.

    Cloning a web application within the same server is usually faster compared to cloning to a different server. You can monitor the progress by clicking the Notification icon at the top right. It will give you the details of RunCloud cloning your web application.

    Done! Now you have cloned your website within the same server.

    Summary

    Clone Web Application feature is very useful to clone/duplicate your existing web application quickly, within the same server or to a different server within your RunCloud account.

    Pro and Business plan users can enjoy the full functionality of this feature. For Basic plan users, this feature is available to try until 1st June 2020, and you are only able to clone web applications within the same server.

    When it comes to our users, we know RunCloud is important to you, and you rely on its services. We are always listening to what your pains are, and we want to solve them and make your life easier.

    The web app cloning feature has been a largely requested feature, receiving 218 upvotes that we knew would be useful to you. Never ever hesitate to suggest new features that you want to see, and we will make it happen.