RunCloud CMS

Blog

  • Amazon Route 53 vs. Cloudflare DNS – Which Is Better?

    Amazon Route 53 vs. Cloudflare DNS – Which Is Better?

    A Domain Name System, or DNS, acts as a bridge between your device and the website you want to visit. Without it, you’d have to manually input the IP address of every site you want to visit instead of using a human-readable domain name.

    Slow DNS servers can result in poor load times, and, in worst-case scenarios, if the DNS server happens to go down, accessing websites won’t be possible at all. This is why it’s crucial to choose a good DNS server.

    In this guide, we’ll compare two of the bests DNS providers out there – Amazon Route 53 and Cloudflare. We’ll go through the pros and cons of each service so that you can make a more informed decision about which one better suits your needs.

    Amazon Route 53

    Amazon Route 53 DNS

    Amazon Route 53 prides itself on being “a highly available and scalable cloud Domain Name System (DNS) web service”. Not only does it route users to the different AWS services – such as Elastic Load Balancing and Amazon EC2 instances – but also, it can route users to non-AWS infrastructure.

    Let us look at some of its key features in more detail below.

    Amazon Route 53 – Pricing

    Amazon Route 53 charges you for “what you use”, as they state on their website. In other words, you pay as you go, depending on the number of DNS queries answered by Amazon Route 53, with some exceptions, like queries for qualifying alias records, which don’t incur additional charges.

    Basically, you don’t pay in advance or commit to anything, which can be an advantage depending on your needs.

    Route 53’s price varies according to the type and quantity of queries.

    Query TypeUp to the first billion per month

    ($ per million queries)

    		After the first billion per month

    ($ per million queries)

    Standard$0.40 $0.20
    Latency-based routing $0.60 $0.30
    Geo DNS & Geo Proximity$0.70 $0.35

    With standard queries, for the first 1 billion queries a month, you are charged $0.40 per million queries. Once you have over 1 billion queries a month, the price is $0.20 per million queries.

    With latency-based routing queries, the prices are slightly higher, starting with $0.60 per million queries for the first billion queries per month and $0.30 per million queries for over 1 billion queries per month.

    Finally, with Geo DNS and Geo Proximity Queries, for the first 1 Billion queries a month, you are charged $0.70 per million queries. Again, the price decreases after you have over 1 billion queries monthly, at which point you incur charges of $0.35 per million queries.

    Of course, the final price will depend on what kind of other Amazon Route 53 features you are using as well – such as health checks, Route 53 Resolver, etc. – and can quickly add up if you’re running a large-scale operation.

    Amazon Route 53 – Reliability

    One feature that makes Amazon Route 53 stand out is its high reliability. With this service, you have four DNS servers: .com, .net, .co.uk, and .org. This means that if the root server goes down for some reason, you still have three DNS servers operating smoothly.

    Moreover, since the four DNS servers are geographically distributed, even if some kind of accident were to happen to one of the data centers, the other DNS servers would still be up and running. Finally, all four servers are on different Anycast IPs, which ensures high reliability but comes at the expense of performance.

    Amazon Route 53 – Speed

    Route 53’s query speed is one of its main shortcomings. Amazon’s DNS service is actually better than many of its competitors but still stays far behind Cloudflare’s DNS.

    It doesn’t matter which of their four DNS servers are closest, you have the same chance to hit this one or any of the others. This is the price that’s paid for Route 53’s increased reliability.

    Amazon Route 53 – Privacy

    With Route 53, you have privacy protection for contact information on a domain enabled by default. It hides most of your contact information, preventing spam, and blocking anyone who would otherwise be able to see your personal information by sending a WHOIS query.

    However, Amazon doesn’t issue a guarantee that they won’t use your information themselves, for company or data purposes. This will be a big red flag for many of you.

    Amazon Route 53 – Flexibility

    Amazon Route 53 is very flexible. Thanks to the Amazon Route 53 Traffic Flow, traffic is routed according to several criteria such as geographic location, endpoint health, and latency.

    Various traffic policies can be configured, after which you can choose which ones should be active at a certain time. The simple visual editor also enables you to create and edit traffic policies easily. What’s more, you have a history of changes to your traffic policies with Traffic Flow’s versioning feature. This way, you are free to roll back to a previous version if needed.

    Cloudflare DNS

    Cloudflare DNS

    Primarily popular for its high-quality content delivery network, Cloudflare also features a DNS service called 1.1.1.1. They describe their DNS as the “Internet’s fastest, privacy-first consumer DNS service”.

    Below we’ll examine some key features of this DNS service.

    Cloudflare DNS – Pricing

    1.1.1.1 is free of charge for ordinary users. However, if you are a developer or an enterprise with a professional website, you might want to make use of the Geo DNS feature, i.e. the Cloudflare Load Balancing feature. This means that you have to sign up for a monthly subscription.

    The prices vary per server (origin), where a server can be an IP address or CNAME:

    • $15/month for 2 origins (servers),
    • $25/month for 4 origins (servers)
    • $30/month for 5/6 origins (servers)

    In contrast to Amazon Route 53 where you pay as you go, the downside of Cloudflare DNS is that you have to sign up for a monthly subscription if you are running one or several websites.

    Cloudflare DNS – Reliability

    Compared to Amazon’s Route 53, Cloudflare’s infrastructure is less reliable.

    In case your server goes down, Cloudflare DNS will keep redirecting users to it anyway. Unlike Route 53, it won’t redirect them to a different, functioning server while the issue is being solved.

    Cloudflare DNS – Speed

    Query speed is no doubt the best feature of Cloudflare. This DNS is much faster than other competitors such as Amazon Route 53, Cisco Open DNS, Google Public DNS, or Verisign.

    DNSPerf, the independent DNS monitor, ranks 1.1.1.1 as the fastest DNS service worldwide. Ranking way lower on the same list, Amazon’s Route 53 pales in comparison speed-wise.

    Cloudflare DNS – Privacy

    Privacy is another advantage for Cloudflare DNS. Not only does the company promise that it will never use your browsing data to sell it or to target ads, but it also guarantees that it won’t log your IP address. If there are any potential logs, they are deleted within a period of 24 hours.

    And they mean it: they even claim they retained a big four accounting company to audit their practices on an annual basis.

    You can read more about their motivations regarding privacy here.

    Cloudflare DNS – Flexibility

    Cloudflare DNS is significantly less flexible compared to Route 53. It just doesn’t hold up against the dozens of servers with geolocation-based routing that Amazon boasts.

    Unfortunately, configurability and flexibility are some of the tradeoffs that come with the top-notch speed of Cloudflare DNS.

    Related: Cloudflare R2 vs AWS S3 – Full Comparison

    Conclusion – Cloudflare or Route 53?

    So which one is better for you, Amazon Route 53 or Cloudflare’s 1.1.1.1 DNS?

    In terms of performance, Cloudflare has the upper hand with its incredible speed of 12.52ms. Their commitment to privacy concerns is also a big plus. However, if you’re an avid AWS user – Route 53 might make more sense because you can run health checks against load balancers and easily use geo-routing for specific resources in your Amazon Web Services account.

    All in all, it’s safe to say that both of these are solid premium DNS providers – and you’ll be very happy with your choice either way.

    We at RunCloud use & highly recommend Cloudflare. This is why, with RunCloud’s built-in Cloudflare DNS integration – you can also enjoy its benefits. Deploying websites and managing servers for your web applications has never been easier. It’s one of the many reasons RunCloud is the server management solution trusted by industry-leading system administrators, yet accessible to everyone. Start your 7-day free trial today.

    Which DNS provider do you use & recommend? Let us know & join the conversation by leaving a comment below. 💬

  • How To Install WordPress On OpenLiteSpeed

    How To Install WordPress On OpenLiteSpeed

    WordPress is the world’s leading (and by far the most popular) content management system (CMS) – currently powering over 40% of all websites on the internet & continuing to gain market share year after year.

    After all, it’s trusted by prestigious brands like Bloomberg, the BBC, and TechCrunch – just to name a few – for good reason.

    In this guide, we’ll walk you through how to deploy a WordPress website on OpenLiteSpeed – a server stack built for speed, security, and scalability – using RunCloud as well as manually. So, without further ado – let’s dive in:

    Getting Started – Server Requirements

    To Deploy WordPress on OpenLiteSpeed, you will need:

    1. A server with a fresh, clean installation of Ubuntu 18.04/20.04 x86_64 LTS
    2. You will need at least one static public IP Address (especially for Google Cloud and AWS users where an additional step is required to set up a static public IP Address for your server).
    3. Make sure ports 22, 80, 443, and 34210 are open (especially for Google Cloud, AWS, Azure, and Alibaba Cloud users where an additional step is required to open these necessary ports for your server).

    How To Deploy WordPress on OpenLiteSpeed (Recommended)

    The easiest & therefore recommended way to deploy WordPress on OpenLiteSpeed is using RunCloud. Let’s see how you can get both your server and site up and running in 3 simple steps…

    1. Create or Log Into Your RunCloud Account

    The first step is to log into your RunCloud account. If you don’t have a RunCloud account we’ll recommend you to create one:

    RunCloud Dashboard

    2. Connect Your Server

    Now that you’re logged into your account – you’ll need to go ahead and connect your first server to RunCloud. This only takes a few minutes, to get started, click Let’s get started as shown below:

    Connect Server RunCloud

    Next, you’ll see a list of compatible cloud hosting providers. Go ahead and make your choice (for example, UpCloud) and choose the Connect via IP Address option if you’ve already deployed a new server with your cloud hosting provider:

    Select Server Provider UpCloud

    You can alternatively use our integrations for Vultr, Digital Ocean, Linode, and UpCloud’s APIs to automate the entire server build & deployment process.

    Once selected, scroll down and select OpenLiteSpeed as your preferred server stack:

    OpenLiteSpeed Server Stack RunCloud

    Then, give your server a suitable name (so it’s easy to locate later), enter the server’s IP address, and click Add this server. You’ll then be taken to the following page where you’ll be asked to enter your server’s root password:

    Server Credentials

    You’ll then be prompted to enter your server’s root password, which will be automatically emailed to you by UpCloud once your server has finished deploying. And with other server providers, it’s typically quite easy to locate in their respective account areas. Once entered, click Start the installation.

    As RunCloud configures your server – this is what you’ll see:

    RunCloud Server Configuration

    And once complete, OpenLiteSpeed will have been successfully installed and configured which means you can now deploy WordPress using RunCloud’s easy 1-Click WordPress installation.

    RunCloud Server Dashboard

    3. Deploy WordPress With RunCloud’s 1-Click Install

    Now that your server is connected to RunCloud, the last step is to create your brand-new web application (in this case, WordPress) using our easy, one-click WordPress installation.

    • Select your server and navigate to the Web Application tab – as shown below:
    Create Web Application
    • In the top right corner, click Create Web App and proceed to select RunCloud’s 1-Click WordPress option:
    1-Click WordPress Installation

    There are a few standard WordPress-related settings that you can configure here such as your first user account as well as the site administrator email address – as well as enabling the automatic installation of LiteSpeed’s official caching plugin for WordPress (which we highly recommend leaving enabled).

    For reference, the officially LiteSpeed Caching plugin paired with LSCache is an incredible combination. The plugin is one of (if not) the best & most well-maintained caching plugins for WordPress – here’s a quick preview of what it’ll look like in your WordPress dashboard when you’re done following this tutorial to install OpenLiteSpeed:

    LiteSpeed Cache Plugin WordPress

    And once you’re done entering your credentials, simply click confirm and that’s it. RunCloud will take care of the entire WordPress installation process.

    Add Domain Name

    Once RunCloud finishes deploying WordPress on your brand-new server, here’s what you’ll see:

    Manage Web Applications

    Now you can manage your WordPress installation right here from your RunCloud dashboard. In order for your site to be accessible from a URL of your choice, you’ll need to navigate to your web application’s Domains options where you’ll be able to connect a domain and then be prompted to create the necessary A record to point to this IP address with your DNS provider. Once you’ve connected a domain, you’ll be able to deploy a free Let’s Encrypt SSL certificate in the SSL tab or alternatively install a custom certificate from another service such as Cloudflare.

    With RunCloud, you can finally enjoy hosting and managing servers with features like cloning, staging, atomic deployment, built-in backups, and more…

    As you’ll quickly notice when you begin to take a look around your newly installed WordPress website, just clicking around the WordPress admin area on your new site, you’ll feel a noticeable difference in how snappy pages are loading in comparison to what you’re likely accustomed to. Websites running on NGINX on RunCloud can benefit from the RunCloud Hub as well as RunCache, while sites using OpenLiteSPeed can instead take advantage of the official LiteSpeed Caching plugin.

    So now, let’s actually drop in the demo site we set up for this tutorial to run a quick performance test with GTMetrix and Google PageSpeedInsights.

    Google PageSpeed Insights OpenLiteSpeed
    GT Metrix Performance Test OLS

    With no optimization of any kind done, this is quite impressive & truly a result of OpenLiteSpeed’s highly performant server stack as well as RunCloud’s configuration and UpCloud’s rock-solid infrastructure. Though it is worth noting that most benchmarks begin to observe the more notable differences when comparing OpenLiteSpeed and other server stacks under heavier load so we look forward to you deploying your sites and enjoying the benefits of the OpenLiteSpeed server stack which was built for speed, security, and scalability!

    Migrating Sites from NGINX to OpenLiteSpeed

    If you already have sites hosted on servers running NGINX that you’d like to move over to OpenLiteSpeed servers, the process couldn’t be easier with RunCloud.

    1. Deploy a new server with OpenLiteSpeed (as outlined above)
    2. Clone the web app from the NGINX server to your new OpenLiteSpeed server
    3. Test and if you run into any issues, simply rebuild the web application
    4. Point your domain to your new server

    Ready to get started? Create your RunCloud account today.

    How To Deploy WordPress on OpenLiteSpeed (Manual)

    However, for those of you who are just looking to test OpenLiteSpeed on a sandbox server – here’s how you can manually install WordPress on OpenLiteSpeed:

    1. Installing MariaDB server:

    MariaDB server is a popular open-source alternative to MySQL database. It’s easily available in the standard repositories. The first step is to update the packages list on the server, using the following command:

    sudo apt update

    After the packages list has been updated, run the below command to install the MariaDB server and MariaDB client on your server. There, you will be asked to confirm to use storage space. Type Y and press the Enter key to proceed with the installation.

    sudo apt install mariadb-server

    Use the below command to conduct the secure installation of MySQL on your server.

    sudo mysql_secure_installation

    The command prompt will take you through the wizard, including the following questions. Answer them as shown below:

    • Change the root password: N
    • Remove anonymous user: Y
    • Disallow root login remotely: Y
    • Remove test database and access to it: Y
    • Reload Privilege Table Now: Y

    The MariaDB server has been installed and configured. You can proceed to create the first database.

    Go into the MySQL client by running the following command.

    sudo mysql

    Enter the below commands to build a database and grant all permissions on that database to a new database user account.

    • mysql > CREATE DATABASE wordpress;
    • mysql > GRANT ALL ON wordpress.* TO ‘wordpress’@’localhost’ IDENTIFIED BY ‘password’;

    Flush the privilege table and exit from the mysql shell.

    • mysql > flush privileges;
    • mysql > exit;

    Now, your database is ready to install WordPress.

    The next step is to install all the required PHP extensions.

    1. Installing required PHP extensions

    WordPress works with both PHP and SQL. Before installing WordPress, you will need to install the following PHP extensions to ensure that WordPress runs on the server seamlessly.

    sudo apt install lsphp74-common lsphp74-curl lsphp74-imap lsphp74-json lsphp74-mysql lsphp74-opcache lsphp74-imagick lsphp74-memcached lsphp74-redis

    3. Configuring OpenLiteSpeed

    You will need to configure the OpenLiteSpeed server to host your WordPress site. Here, you are required to set the correct version of the PHP processor, allow the rewrite module and various other features.

    Configure your server to use Isphp74 as a PHP server instead of the default PHP processor.

    • Go to Server Configuration > External App and click the edit icon.
    • OpenLiteSpeed SAPI app
    • Replace lsphp with lsphp74
    • Replace uds://tmp/lshttpd/lsphp.sock with uds://tmp/lshttpd/lsphp74.sock
    • Replace lsphp73/bin/lsphp with $SERVER_ROOT/lsphp74/bin/lsphp

    Once you make the changes, click on the save icon on the top right corner of the panel. The next step is to configure the rewrite module, an important part of the WordPress feature. Go to the Virtual Hosts and click on the view icon.

    Click on the General tab. Edit the General options with the edit icon at the top right corner.

    In the Document Root field, type $VH_ROOT/html/wordpress and click the save button at the top right corner.

    Again click on the General tab of virtual hosts configuration. And click the edit icon next to the Index Files section.

    In the Index Files Field, add index.php at the beginning of the section. Click on the Save button at the top right corner.

    Go to the Rewrite tab of the Virtual Hosts configuration view and edit the Rewrite Control Options.

    Set Enable Rewrite and Auto Load from .htaccess to Yes. Click on the save icon at the top right corner.

    Click on the restart icon to apply the changes once the configuration is done on the OpenLiteSpeed server.

    4. Downloading and extracting WordPress

    Your server is ready to host WordPress. Now, you can download and install WordPress.

    Navigate to the virtual host root which is /usr/local/lsws/Example/html

    cd /usr/local/lsws/Example/html/

    Download the latest version of WordPress using the wget command below.

    wget https://wordpress.org/latest.tar.gz

    Extract the zip files, which will create a directory called ‘wordpress’ in /usr/local/lsws/Example/html

    tar xvfz latest.tar.gz

    5. Setting up the ownership and permissions of the file

    By setting up the right ownership of files and folders, you will not come across any problems while installing or downloading any new themes or plugins. Let’s check how you can set up the ownership of the files and folders.

    Firstly, remove ownership from the WordPress directory through the below command.

    sudo chown -R nobody:nogroup /usr/local/lsws/Example/html/wordpress

    Using the below command, set 750 permissions to the directories and 640 to the files.

    sudo find /usr/local/lsws/Example/html/wordpress/ -type d -exec chmod 750 {} \;
sudo find /usr/local/lsws/Example/html/wordpress/ -type f -exec chmod 640 {} \;0

    6. Installing WordPress

    Through the IP address of your OpenLiteSpeed server or your domain (if set), you can open the WordPress installation wizard in your web browser.

    In the first screen, you will be asked to choose your preferred language. Select your language and click on the Continue button.

    Next, WordPress prompts you to keep the database server information and credentials ready. Click on the “Let’s Go!” button. Fill up the details as shown below:

    • Database name: the database you created through the MySQL shell, wordpress in this example.
    • Username: Here, you need to input the database user
    • Password: Type in the password of your database user
    • Database Host: localhost
    • Table Prefix: wp_ is the default table prefix. However, you can type something else to enhance the security of your website.

    Click on the Submit button to confirm.

    Up till now, the configuration of the database connection for the WordPress installation has been done. Next, click on the “Run the Installation” button to set up your WordPress site.

    You will be asked to enter your website’s details, create an administrator account, and create a password.

    When you have filled up all the details, click on the Install button.

    On successful installation, you will be able to see the login screen. Log in using the username and password that you created earlier in the installation wizard. Once logged in, you can see the WordPress website’s admin dashboard.

    7. Creating and configuring SSL certificates

    Now, WordPress is successfully installed on your web server. To add a security layer between your website server and your audience, you will have to obtain and install SSL certificates.

    If you already use Certbot to obtain SSL certificates for your OpenLiteSpeed server, you can use the already installed Certbot client. Then, you can skip the installation step and check out the steps to obtaining certificates for your WordPress site.

    If you do not have the Certbot installed, use the steps here to get the client.

    Update the packages installed on the server using the following commands:

    sudo apt update

    Install the Certbot client with the following command.

    sudo apt install certbot

    Now you can obtain the SSL certificates for your server with the below command.

    sudo certbot certonly --webroot

    Note: Before you can obtain SSL certificates, you will need to have a domain name: A record pointing to your OpenLiteSpeed server’s public IP address.

    Then, you will have to answer the following questions.

    • Enter Email address: Type in your email address
    • Accept the terms of service: A
    • Share your Email Address with EFF: Type Y for yes and N for No.
    • Enter Domain name: Type your FQDN (fully qualified domain name) here
    • Input the Web root: /usr/local/lsws/Example/html/wordpress/

    The validation process will be completed, once you are done answering the above questions. The certificate files will be saved in /etc/letsencrypt/live/<your-domain>/ directory.

    Configure the WordPress site on your OpenLiteSpeed server to use the SSL certificate. Navigate to the Virtual Host configuration and open the SSL tab. Edit the SSL Private Key & Certificate.

    Type the fields as follows:

    • Private Key File: /etc/letsencrypt/live/<your-domain>/privkey.pem
    • Certificate File: /etc/letsencrypt/live/<your-domain>/fullchain.pem
    • Chained Certificate: Yes
    • CA Certificate Path: /etc/letsencrypt/live/<your-domain>/fullchain.pem
    • CA Certificate File: /etc/letsencrypt/live/<your-domain>/fullchain.pem

    Once completed, go to Listeners and add a new listener.

    Fill in the fields as follows:

    • Listener Name: SSL
    • IP Address: ANY
    • Post: 443
    • Binding:
    • Enable REUSEPORT: Not Set
    • Secure: Yes

    Apply the new settings by clicking the save icon on the right.

    Next, view the SSL listener to configure the Virtual host mapping.

    Add a row in Virtual Host Mappings.

    Choose the virtual host and type in your domain name. Save the settings from the save button on the top right corner.

    Once you’ve configured the SSL with your OpenLiteSpeed server, click on the restart icon to apply the changes.

    You can now visit your website on https protocol as well.

    Now, you are all set to work on your newly installed website.

    Given how time-consuming the manual installation of OpenLiteSpeed (as well as the deployment of WordPress) is, this isn’t recommended for those of you who aren’t system administrators or don’t have significant experience managing servers.

    This is actually exactly why we built RunCloud.

    Painless server configuration that automates all of this so you don’t need to spend hours figuring it out – get started with RunCloud today & get up and running in minutes.

    Already deployed your WordPress website on OpenLiteSpeed? Or, have any other questions or already deployed your WordPress website on OpenLiteSpeed? Let us know & join the conversation by leaving a comment below. 💬

  • How To Properly Back Up Your Website (Disaster Recovery) with RunCloud

    How To Properly Back Up Your Website (Disaster Recovery) with RunCloud

    A proper backup and disaster recovery solution is an absolute necessity for anyone running a website. Whether it’s something going wrong with a server/infrastructure provider or a change on the application level that takes your site down, you need to be ready to handle it fast.

    Fortunately, setting a backup solution that’s actually usable and reliable doesn’t have to be a hassle. So, in this guide, we’re going to walk you through how you can set up website backups with RunCloud Backup – a built-in backup solution designed to bring you peace of mind without slowing down your sites.

    An Introduction to RunCloud Backups

    Most backup solutions run at the application level, such as in the form of a plugin if you’re using a CMS like WordPress which is great in theory because it’s very easy to set up. Unfortunately, some solutions like this can significantly slow down your websites and tend not to be reliable for large sites.

    With RunCloud Backups – both backups & restores are performed at the server level which means you’re not relying on any compatibility or size limitations not getting in the way. In fact, we also continue to closely monitor user feedback on backups ensuring their efficiency and reliability across the board on the hundreds of thousands of web applications that rely on RunCloud.

    RunCloud Backup Pricing

    RunCloud Backup Features

    • Incremental Backup
    • Backup WordPress site (both Web App & Database)
    • Folder/File exclusion
    • Database Table exclusion
    • Backup Frequency (12 hours – 1 week)
    • Schedule Backup
    • On-demand Backup
    • Download Backup

    How To Back Up Web Applications (The Easiest Way)

    1. Log In To Your RunCloud Dashboard

    The first step is to log in to your RunCloud account. If you don’t have a RunCloud account we’ll recommend you create one:

    RunCloud Login

    2. Create Your First Backup

    Navigate to the RunCloud Backup page in your dashboard using the navigation. You’ll see the following (if this is your first time creating a backup with RunCloud).

    To get started, simply click Backup your first site.

    3. Configure Your Backup’s Settings

    You’ll then be able to configure your backup’s settings, which is where you set the following:

    • Backup Plan – Backup Basic or Backup Pro
    • Backup Method: Web Application, Database, or Both

      Note: We highly recommend backing up both your web application and database if you use WordPress as the database is crucial for your website to work.

    • Select your web application
    • Select your database
    • Name this backup
    • Choose your backup frequency
    • Choose your backup retention (how long do you want to store backup files?)
    • Configure notifications for successful & failed backups

    All RunCloud users get 5GB of storage included with their existing plans that can be used with RunCloud’s free backup service. However, if you feel that you’d benefit from advanced functionality such as custom file exclusion, on-demand backups, flexible backup retention & more – you can upgrade to RunCloud Backup Pro starting at just $1 USD per month for up to 50GB of storage.

    RunCloud On-Demand Backups

    Restoring Your Backups – Disaster Recovery

    If you can’t rely on actually being able to use your backups when it comes to disaster recovery – then there’s not much point in having them there in the first place. You need a solid restore process in place so that if a server or site ever needs to be restored, you know how to get it back up & running in no-time.

    This couldn’t be easier than it is with RunCloud Backups. Simply navigate to your backup instance and then view your Backup files. From this list of all backups – choose which one you wish to restore and then click Restore this backup:

    You’ll then be able to select how you wish to restore this backup. What server you wish to restore it to, whether you wish to rollback the existing site or create a new site from the backup and more.

    Backup Restore

    And once you’ve made your selection, simply click Restore this Site and that’s it! 👏

    RunCloud Backups – Frequently Asked Questions

    Can I only restore database or web application files?

    If you chose only to backup files, then files that were backed up will be restored. If you chose only to backup the database, then only the database will be restored. And if you backup both web application and database, both will be restored. You cannot restore one or the other.

    What happens to my backups after my trial?

    Before your trial is up, you will need to select which sites you want to move over to Backup Basic. Any sites on Backup Pro will be deleted unless you purchase a Backup Pro plan. You will notified three times to migrate your data and choose a plan: 1 week, 3 days, and 1 day.

    What if I delete my web application?

    We do not delete any of your data unless requested to do so. Therefore, if you have backups and you delete your web application, the backups will be saved and can still be restored to an existing website or a test site (Pro).

    Are all my files backed up?

    All files are backed up as incremental backups meaning your first backup will be a full backup and each backup afterwards will be incremental backups, which mean that only files that have changed will be backed up. If you selected to retain backups for a week, then once the full backup is deleted, another full backup will be made, and after that, each backup will be incremental.

    Our backup service is smart enough to understand the difference between a full backup and incremental backups, so you need not worry. This new service was designed like this to maximize the amount of space before files are deleted.

    What happens if I reach my backup limit?

    Once you have reached the maximum limit of your plan, your backups will be paused until space is cleared or you upgrade your plan.

    Conclusion – RunCloud Backup, A Built-In Backup Solution You Can Actually Rely On

    While we highly recommend having a backup solution such as RunCloud’s built-in Backup service in place, for more advanced sites with multiple people making changes to your codebase, we highly recommend using version control with GitHub for Continuous Integration and Deployment.

    And with RunCloud working in the background to ensure backups are taken on the server level, you don’t have to worry about having a reference point to restore to – no matter what happens. For instance, if you were one of the millions affected, our free solution that couldn’t be easier to get started with could have saved your data from being lost in OVH’s data center fire in France.

    The last thing you want to deal with is data loss on a service your customers rely on in production. And at RunCloud, we’re driven to make it easier for you to run your business giving you everything you need to manage your servers. If you have absolutely any questions, comments, or suggestions – feel free to leave a comment below! 💬

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

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

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

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

    What Is Google FLoC & Why It Matters

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

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

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

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

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

    Why FLoC Is Considered Premature

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

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

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

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

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

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

    Why FLoC Sets A Dangerous Precedent

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

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

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

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

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

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

    How to Opt Out of FLoC Data Collection

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

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

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

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

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

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

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

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

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

    Permissions-Policy: interest-cohort=()

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

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

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

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

    nginx -t && service nginx reload

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

    Opting Out of Google FLoC on OpenLiteSpeed (RunCLoud)

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

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

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

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

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

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

    systemctl restart lsws

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

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

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

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

    ufw allow 7080

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

    For Debian/Ubuntu run the following command: 

    sudo apt install ufw -y

    For servers using CentOS, run the following command:

    yum install ufw -y

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

    ufw default deny incoming

ufw default allow outgoing

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

    ufw allow ssh

ufw allow http

ufw allow https

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

    You can now enable UFW by running:

    ufw enable

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

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

    ufw allow 7080

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

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

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

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

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

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

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

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

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

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

    ufw deny 7080

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

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

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

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

    Verifying FLoC protections in RunCloud

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

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

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

    curl -I https://mywebsite.com

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

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

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

    Summary – Say No To FLoC, Protect Your Users

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

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

  • PHP 8.0 Now Available On RunCloud

    PHP 8.0 Now Available On RunCloud

    Introducing The Latest Version Of PHP 8.x

    PHP 8.x was released on December 23, 2020 and RunCloud has been working hard to ensure compatibility with its servers. Several weeks later, today, RunCloud is ready to introduce to its users that PHP 8.x which is now available to all accounts located in the web application settings, existing and new. While we highly encourage you keep your PHP version up to date, we do not yet recommend you upgrade to PHP 8.x on your live production servers, especially if you are using WordPress. If you are creating a new web app without WordPress, you may freely give PHP 8.x a try.

    There are still many WordPress plugins that are not yet compatible with PHP 8.x and will cause your server or website to error. While PHP 8.x does have good backwards-compatibility with PHP 7.x, we do recommend slowly updating your web applications over time. Currently, RunCloud Support can only offer technical support for errors and bugs that are directly related to the RunCloud dashboard and your web application. If you still choose to update your RunCloud’s PHP version to 8.x, here are some of the latest fixes, bugs, and new features, as well as features that may have been removed.

    PHP 8.0.1 is now available with more bug fixes and updates in RunCloud

    RunCloud always runs after new updates of PHP and always has been forward to embrace all the most recent updates of PHP. Recently, PHP has officially released the most updated version, 8.0.1 on the 7th January of 2021. So we always look forward to providing you with the most details of PHP, while you have the choice to upgrade or continue with your current version of PHP 7.x. We always recommend the latest version of PHP 7.x to you, as the latest versions are the fastest and most secure.

    There is no doubt, PHP is one of the most popular and dominant languages on the Internet. And we need to learn and cope up with the new features to get most out of this language. Lets get started on a review of the latest features.

    What’s new in Version 8.0?

    PHP Version 8.0 has come up with some great new features like the following:

    • Named Parameters: PHP 8.0 allows named parameters during function or method calls in addition to traditional positional parameters, which helps a lot for new and experienced programmers. This will certainly make the function or method parameter names part of the public API. The non-standardized DocBlock @no-named-arguments expresses that the library does not provide backwards-compatibility for named parameters.
    • Attributes: In PHP 8.0,  Attributes allows declaring meta-data for functions, classes, properties, and parameters. Attributes map to PHP class names (declared with an Attribute itself), and they can be fetched programmatically with PHP Reflection API, which is a great feature of PHP 8.0.
    • Constructor Properties:  In the constructor, PHP 8.0 enables declaring the visibility (public, private, or protected) and type. Those properties will be registered as class properties with the same visibility and type they are declared in the constructor.This backwards-incompatible feature can help reduce boilerplate code when declaring value-object classes.
    • Just-in-Time Compilation: The Just-in-time (JIT) Compilation is a great feature of PHP. PHP Opcache supports JIT. It’s been disabled by default, and if you enable it, JIT compiles and caches native instructions. It does not make a noticeable difference in IO-bound web applications, but provides a performance boost for CPU-heavy applications.
    • Union Types: Union Types extend type declarations (return types, parameters, and class properties) to declare more than one type.
    • Null-safe Operator: Null-safe operator provides safety in method or property chaining when the return value or property can be null.

    • Matching expressions: Match expressions are similar to switch blocks, but match blocks provide type-safe comparisons, supporting a return value that does not require break statements to break-out, and supports multiple matching values. Also it guarantees that at least one branch is matched, ensuring all cases are accounted for.

    • Weak-Maps: A WeakMap is another new feature of PHP 8.0, which allows to store and associate arbitrary values for object keys, but without preventing the garbage collector from clearing it the object falls out of scope everywhere else. A WeakMap is similar to SplObjectStorage, as in both WeakMap and splObjectStorage use objects as the key, and allows storage of arbitrary values. However, a WeakMap does not prevent the object from collecting the garbage.

    New Functions and Classes of version 8.0:

    PHP 8.0 introduces a few new functions to ease string inspections which contain or starts with substring, or ends with substring to replace the meticulous strpos() !== false calls that are less readable, and error-prone due to weak type comparisons.

    PHP 8.0 also brings functions such as fdiv, get_resource_id, get_debug_type, and preg_last_error_msg

    Apart from that, the new Stringable interface has been added and the new PhpToken class has been included which provides a more fluent Object-Oriented interface as an alternative to the legacy array-based to token_get_all function.

    Deprecations: The following deprecations are being occurred in 8.0

    • PostgreSQL: Several aliased functions 
    • Deprecate required parameters after optional parameters in function/method signatures
    • `ReflectionParameter::getClass())`, `::isArray()`, and `::isCallable()` methods 
    • Disabled functions: Reflection and `get_defined_functions()` 
    • `libxml_disable_entity_loader` function 

    Apart from that  two functionality or features have been adjusted. They are-

    • XMLRPC extension is moved to PECL and 
    • `FILTER_FLAG_SCHEME_REQUIRED` and `FILTER_FLAG_HOST_REQUIRED` flags are removed

    Functionality or Syntax Changes in PHP 8.0: 

    There have been some changes in 8.0 with previous versions and they are mentioned below-

    • Default error reporting is set to `E_ALL`
    • Inheritance rules are not applied to `private` class methods
    • Calling non-static class methods statically result in a fatal error
    • Apache Handler: Module name and file path changes
    • Locale-independent `float` to `string` casting
    • Class magic method signatures are strictly enforced
    • `substr`, `iconv_substr`, `grapheme_substr` return empty string on out-of-bound offsets
    • PHP Startup Errors are displayed by default
    • GD Extension: Windows DLL file name changed from `php_gd2.dll` to `php_gd.dll`
    • `crypt()` function requires `$salt` parameter
    • PDO: Default error mode set to exceptions
    • `@` Error Suppression operator does not silent fatal errors
    • Trailing commas are allowed in parameter lists and closure `use` lists
    • Implicit negative array key increments do not skip negative numbers
    • `XMLWriter` objects replace `xmlwriter` resources
    • OpenSSL: `resource` to object migration
    • `XMLParser` objects replace `xml` resources
    • String to number comparisons no longer coerce string to a number
    • Strict type checks on arithmetic operators
    • Sorting functions maintain positions of equal value items
    • Internal function warnings now throw `TypeError` and `ValueError` exceptions
    • Expressions can now `throw` Exceptions
    • JSON extension is always available
    • `catch` exceptions only by type
    • `+`/`-` operators take higher precedence when used with concat (`.`) operator
    • `CurlHandle` class objects replace curl handlers
    • Fatal errors on incompatible method signatures
    • Disabled functions behave as if they do not exist
    • `GdImage` class objects replace GD image resources
    • Assertions throw exceptions by default
    • Sockets extension resources (`Socket` and `AddressInfo`) are class objects

    The difference between version 8.0 and 8.0.1: 

    In version 8.0.1 some of the bugs of version 8.0 have been fixed, which makes the newer version more capable and flexible for the users. Some of the major bug fixings are -White space not unfolded for CC/BCC headers, Iterable not co-variant to mixed, Build of PHP extension fails due to configuration gap with libtool, stream filter loses final block of data, and so on.

    Last, but not the least, RunCloud support can assist you in the update should you need any additional help, although RunCloud cannot offer any support for individual plugins that may be experiencing a conflict with the new PHP 8.0 or 8.0.1 version.

    Switching PHP versions on RunCloud:

    Located within your Web Application, scroll down the Navigation menu and click on Settings. Right at the very top is the setting for PHP version which you can switch from PHP 7.x to PHP 7.8. If you encounter any errors, you may switch it back immediately. It is highly recommended that if you are running a WordPress website or a live website, you do not upgrade at this time. If you are starting a new web application without WordPress or running a website that is not running on WordPress, you should be okay to upgrade, but please proceed with caution.

    After selecting your PHP version, click the Update button and you will be on the new PHP version! Please check your website to make sure there are no errors. Should you encounter any issues with your upgrading to PHP 8.0 from your dashboard, do not hesitate to open a ticket to RunCloud support! If you have any suggestions or ideas for RunCloud, we are always happy to hear from you!

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

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

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

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

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

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

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

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

    Step 1. Create an Amazon EC2 Instance

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

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

    Choose An AWS Region

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

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

    Launch Instance

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

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

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

    Choose Ubuntu Server Image

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

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

    Choose Amazon EC2 Instance Type

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

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

    Create and Download a SSH Key

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

    Configure Security Group (Open Required Ports)

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

    You need open the following 4 ports:

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

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

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

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

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

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

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

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

    Add Storage

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

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

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

    Step 2. Create A Static Public IP Address

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

    Why You Need a Static IP Address

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

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

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

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

    Allocate An Elastic IP Address

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

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

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

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

    Step 3. Connect Amazon EC2 Instance To RunCloud

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

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

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

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

    Connect to Your Amazon EC2 Instance Using SSH

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

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

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

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

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

    chmod 400 <SSH Key name>.pem

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

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

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

    Run the RunCloud Installation Script

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

    sudo -s

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

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

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

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

    Next Steps

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

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

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

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

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

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

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

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

    Step 1. Create a Firewall Rule to Allow Incoming Traffic

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

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

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

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

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

    Step 2. Reserve a Static IP Address (Optional)

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

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

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

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

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

    Step 3. Create A Google Cloud Compute Engine Instance

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

    Select Name and Region

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

    Select Machine Type

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

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

    Select Boot Disk and OS

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

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

    Apply A Custom Firewall Rule

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

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

    Assign the Static IP

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

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

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

    Step 4. Connect Google Cloud VM To RunCloud

    Connect Your Server

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

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

    Install RunCloud Agent

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

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

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

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

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

    Video Tutorial – Setup Google Cloud Server With RunCloud

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

    Final Thoughts

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

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

  • How to Set Up a Vultr Server with RunCloud

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

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

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

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

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

    Adding Vultr API Key to RunCloud

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

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

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

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

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

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

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

    Provisioning a Vultr Server with RunCloud Integration

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

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

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

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

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

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

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

    Method 2. Setup Vultr Manual Server Installation.

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

    Using the Vultr Firewall

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

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

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

    Create a Firewall Group in Vultr

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

    Add Required Inbound Rules

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

    Allow the following inbound traffic:

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

    For SSH access:

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

    Optional performance enhancement:

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

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

    Apply the Firewall Group

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

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

    Provision VPS and Connect to RunCloud

    Here are the steps to follow:

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

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

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

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

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

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

    Video Tutorial: How to Set Up Vultr Server with RunCloud

    Final Thoughts

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

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

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

    Here are some tutorials that you can follow:

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

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