RunCloud CMS

Category: WordPress

  • How to Fix WordPress HTTP Error When Uploading Images (Quick Guide)

    How to Fix WordPress HTTP Error When Uploading Images (Quick Guide)

    Running into the “HTTP error” when uploading images to WordPress is frustrating, especially when everything else seems to be working fine.

    There’s no detail in the message, no hint at the cause, and no obvious fix. It could be a plugin conflict, a server setting, or something else entirely.

    This quick guide walks you through the most common causes and reliable fixes. Whether you’re a beginner or managing multiple sites, you’ll be able to get uploads working again in minutes.

    What is the WordPress HTTP Error When Uploading Images?

    The WordPress HTTP error is a common issue when uploading an image or video to the media library fails. Unfortunately, this error message is generic and doesn’t pinpoint the exact cause, making troubleshooting tricky.

    This error message signals that something went wrong during the upload process, but WordPress couldn’t determine the reason. When you’ve found the perfect image and are suddenly faced with a vague error message, it can be very frustrating to have your workflow interrupted.

    📖 Suggested read: How to Fix WordPress Revisions Not Showing [SOLVED]

    Common Causes of the WordPress HTTP Error

    Many things can trigger the WordPress HTTP error when uploading images. These errors can be caused by either client-side issues (like your browser or internet connection) or server-side problems (related to your hosting environment or WordPress configuration).

    One of the most common causes of this error is insufficient memory to handle the upload process. If you are using image optimization or security plugins, this can also cause plugin or theme conflicts and interfere with media uploads.

    Additionally, if you haven’t configured your WordPress settings correctly, you can encounter issues like incorrect file permissions for the uploads directory, an outdated PHP version, or problems with image processing libraries like Imagick. Sometimes, the problem can be as simple as a temporary glitch in your browser’s connection to WordPress or an expired login session.

    It is possible that the specific image file itself is causing the WordPress HTTP error. WordPress and web servers have limits on the maximum size of a file that can be uploaded; if your image exceeds this limit, the upload will fail. Depending on your hosting provider’s settings, this limit can range from a few megabytes to much larger. You can check your site’s current upload limit in your WordPress dashboard’s Media > Add New section.

    The type of file you’re trying to upload matters as well. WordPress has a default list of permitted file types for security reasons. If you attempt to upload a file format that isn’t on this allowed list (e.g., trying to upload a .tff font file or an .svg file without specific configuration), you’ll likely encounter an error.

    Finally, how you name your image files can also lead to upload failures. Depending on your WordPress instance, file names containing special characters (like $, *, &, #, %, @, !, etc.), accent marks, spaces, or unusual punctuation can cause issues with the WordPress media library. It’s always best to use simple, web-friendly file names consisting only of letters, numbers, and hyphens to avoid such problems. For instance, a filename like “my-awesome-image-1.jpg” is much less likely to cause an error than “My Awesome Image #{1}.jpg”.

    📖 Suggested read: How to Fix WordPress Stuck in Maintenance Mode? [100% WORKING]

    Step-by-Step Solutions to Fix the WordPress HTTP Error

    If you encounter the WordPress HTTP error while uploading images, you can try the following solutions to solve this problem:

    #1 – Refresh and Re-log in to WordPress

    Before diving into more complex fixes, it is a good idea to try the simplest one first. Refresh the page and try uploading the image again. Sometimes, temporary browser glitches or a brief loss of internet connectivity can cause the HTTP error.

    If refreshing doesn’t work, log out of your WordPress admin area and log back in, as your login session might have expired, leading to a security token mismatch that prevents uploads.

    #2 – Resize or Rename Your Image Files

    As we mentioned above, large image files can exceed your server’s upload limits, triggering the HTTP error. To solve this, you can try reducing the image’s dimensions or compressing its file size using an image editor before uploading.

    If you’re looking for WordPress plugins to do this, we recommend reading this excellent article from Patchstack on the best WordPress image optimization plugins.

    Additionally, ensure your image file names don’t contain special characters, spaces, or accents, as these can cause conflicts; rename files using only letters, numbers, and hyphens (e.g., my-new-image.jpg).

    In the past, we have also noticed that some poorly configured firewall rules block images with names that contain certain sensitive words. So, if your image name contains the phrase wp-login.php or wp-admin, you should consider renaming it to something else and trying again.

    #3 – Deactivate Plugins and Themes Temporarily

    Updating a plugin or theme in the background can easily cause a WordPress HTTP error. To check for this, temporarily deactivate all your plugins and try uploading the image; if it works, reactivate the plugins individually, testing after each, to find the problematic one.

    If plugins aren’t the issue, switch to a default WordPress theme like Twenty Twenty-Four to see if your current theme is causing the error.

    #4 – Increase PHP Memory Limit for WordPress

    WordPress and its plugins require a certain amount of server memory (RAM) to function correctly. If an image upload process demands more memory than allocated, it can result in an HTTP error.

    The exact step to modify this limit will vary depending on your hosting environment. Some hosting providers allow you to set this limit by defining the WP_MEMORY_LIMIT variable in the wp-config.php file, whereas others require you to modify the memory_limit directive in the php.ini file.

    However, if you are using RunCloud, this can be done with just a single button.

    Read the following documentation page to learn how RunCloud users can adjust PHP memory limits through their server management panel.

    #5 – Check and Fix Uploads Folder Permissions

    Linux servers assign specific permissions to each file and folder on your server. If you have configured incorrect file permissions on your wp-content/uploads folder, it can prevent WordPress from writing files to it.

    By default, the directory permissions should be 755 or 744, and individual file permissions should be 644. You can check and change these permissions using an FTP client or your hosting control panel’s file manager.

    If you are using RunCloud, you can resolve file permissions issues with a single click by going to Tools > Fix Ownership.

    #6 – Update PHP Version and Server Settings

    You might already know this, but running an outdated version of PHP can lead to various compatibility issues, including the HTTP error during image uploads. Ensure your server is using a recent, stable PHP version recommended by WordPress.

    The exact steps to change your PHP runtime will vary depending on your operating system and hosting provider. However, if you are using RunCloud, you can easily update the PHP runtime of your WordPress application by going to Settings > PHP Version and simply selecting from the dropdown list.

    Additionally, if you need to use an outdated version of PHP for your website, then RunCloud also provides a secure way to use EOL PHP runtimes without compromising the security of your other web applications.

    #7 – Temporarily Disable Security Modules

    If your web server uses security modules like mod_security (an Apache module) or Content-Security-Policy (CSP) to block suspicious activity, these can occasionally misinterpret legitimate image uploads as a threat and block them, resulting in an HTTP error.

    If you suspect this is the issue, you can temporarily disable the necessary security module and try again.

    However, disable security features cautiously and only temporarily for testing, as they are important for your site’s protection.

    We recommend consulting your host before making these changes, as they can have a lasting impact on your website.

    If you want to learn more about this, we recommend reading our previous post on using mod_security and OWASP for a web app firewall (WAF) to secure your website.

    #8 – Use FTP or Add From Server Plugin as a Last Resort

    Note: This is a workaround rather than a direct fix for the HTTP error, but it can be a lifesaver when you’re in a hurry.

    If all other troubleshooting steps fail and you urgently need to upload images, then you can bypass the WordPress media uploader by using an FTP client (like FileZilla) to upload images directly to a temporary folder on your server. Read our previous articles to learn how to do this effectively.

    After uploading via FTP, the images will not show up automatically in your WordPress dashboard, and you will need to run a specific WordPress command to register these images with the WordPress media library so they appear within your dashboard. ​

    After logging in to your server via SSH, you can run the wp media import ~/picture.jpg command from your WordPress installation directory. This command instructs WordPress to scan the specified path (in this example, a file named picture.jpg within the home directory) and import it into the Media Library.

    If you have uploaded the image to a different directory, you can simply replace the ~/picture.jpg with the path of your image file. You can specify the exact path to a single image file or use wildcards like * to match and import multiple images simultaneously.

    After executing the above command, you will receive a confirmation message for each image imported into the WordPress media library.

    📖 Suggested read: How to Fix the WordPress HTTP 500 Internal Server Error (Easy)

    Why Choose RunCloud for WordPress Hosting and Support?

    RunCloud is a powerful server management panel that simplifies WordPress hosting, development, and maintenance, especially when tackling issues such as the HTTP error during image uploads.

    RunCloud provides developers and agencies with the tools they need for efficient workflows. By offering a suite of specialized features, RunCloud ensures your WordPress sites run smoothly, securely, and are easy to manage. Here are a few reasons why you should use RunCloud to manage your servers:

    Reason 1: Expert WordPress Support for Troubleshooting Errors

    • Simplified Problem Isolation: RunCloud offers a clean and controlled server environment, which makes it easier to pinpoint the causes of WordPress errors, including the HTTP error.
    • Staging Environments: RunCloud allows you to easily create WordPress staging environments. These allow you to test solutions for errors like the HTTP upload issue, experiment with PHP versions, or try deactivating plugins without affecting your live site, significantly reducing the risk of breaking things.
    • Access to Logs: RunCloud provides straightforward access to server logs, which are invaluable for diagnosing complex WordPress errors that don’t provide much information on the front end.

    Reason 2: Optimized Server Performance for Seamless Image Uploads

    • Optimized Stack: RunCloud configures your server with an optimized stack (e.g., NGINX, Apache, various caching options like Redis or Memcached) out of the box. This ensures your WordPress site has the resources and speed needed for smooth operations, including handling image uploads efficiently and reducing the likelihood of HTTP errors caused by resource limitations.
    • Easy Resource Scaling: If insufficient server resources are causing upload errors, RunCloud makes it simpler to manage your server resources or to guide you if you need to upgrade your server plan with your chosen cloud provider (like DigitalOcean, Vultr, AWS, Google Cloud, etc.).
    • PHP Version Management: The RunCloud dashboard makes it easy to switch and manage multiple PHP versions. This is important for ensuring compatibility with the latest WordPress versions and for resolving HTTP errors that might stem from outdated or problematic PHP versions.

    Reason 3: Easy Management and Advanced Security for WordPress Sites

    • User-Friendly Interface: RunCloud provides an intuitive dashboard that simplifies complex server management tasks, such as setting up new WordPress sites, managing databases, and configuring SSL certificates, even for non-Linux experts.
    • Git Integration and Deployment: For developers, RunCloud supports WordPress deployment via Git. This means you can version control your WordPress projects, including themes and plugins, and deploy changes systematically from your Git repository to your staging or production environments, streamlining your development workflow and making rollbacks easier.
    • Team Collaboration and Permissions: RunCloud facilitates teamwork by allowing you to assign specific permissions to team members for different servers and applications. This granular control ensures that colleagues or clients only have access to what they need, and changes can be tracked, enhancing security and accountability.
    • Security Features: RunCloud implements various security measures, including easy SSL certificate deployment (Let’s Encrypt), firewall management, and regular security updates for server packages. This proactive approach helps protect your WordPress sites from threats that could otherwise lead to errors or downtime.

    📖 Suggested read: The Complete WordPress Speed Optimization Guide

    Wrapping Up: Fixing WordPress HTTP Errors When Uploading Images

    In this post, we have provided you with several solutions to resolve the HTTP error in your WordPress installation. By working through the solutions above, you should be able to restore your site’s media uploading functionality and get back to creating engaging content.

    Your hosting environment plays a crucial role in ensuring that your WordPress site runs smoothly and that image handling is optimized. RunCloud significantly simplifies the management of these aspects.

    For instance, RunCloud supports Imagick, a powerful image processing library that WordPress can use to improve image manipulation and quality. RunCloud also uses various caching mechanisms (such as Redis or Memcached), dramatically speeding up your website’s loading times by serving optimized images and content more efficiently.

    One of RunCloud’s most valuable features for troubleshooting and development is its provision for WordPress staging environments.

    Before you apply any fix for the HTTP error, update PHP, or change critical settings on your live website, you can test everything in a safe, isolated staging copy. This allows you to confirm that your changes work as expected and don’t introduce new problems.

    Ready to take control of your WordPress hosting and eliminate frustrating errors for good?

    Sign up for RunCloud today and streamline your WordPress management.

    FAQs on the WordPress HTTP Error When Uploading Images

    Why does WordPress show HTTP errors when uploading images?

    WordPress displays a generic HTTP error when it encounters an issue during the image upload process that it can’t specifically identify. This could be due to insufficient server resources, such as memory limits, incorrect file permissions, or temporary server-side glitches.

    How do I increase the upload size limit in WordPress?

    You can increase this limit by modifying directives like upload_max_filesize and post_max_size in your server’s php.ini file or via .htaccess. With RunCloud, managing these PHP settings for your WordPress sites is straightforward through your control panel, simplifying the adjustment.

    Will changing my theme or plugins fix the HTTP error?

    Potentially, yes, if a theme or plugin is poorly coded and consumes excessive server resources or interferes with the upload process. Temporarily deactivating them can help isolate if one is the culprit behind the HTTP error.

    Can server issues cause the HTTP error in WordPress?

    Absolutely. Server-side problems such as insufficient PHP memory limits, low disk space, or outdated PHP versions are common culprits for the HTTP error. A platform like RunCloud helps you easily manage server configurations and resources to prevent such issues.

    What is the best way to optimize images for WordPress uploads?

    The best approach is to compress images before uploading using tools or plugins to reduce file size without significant quality loss. Choosing appropriate formats like WebP or JPEG for photos and ensuring dimensions are suitable for web display also significantly helps.

  • How to Fix WordPress High CPU Usage (10 Instant Solutions)

    How to Fix WordPress High CPU Usage (10 Instant Solutions)

    Is your WordPress site running slow, timing out, or crashing altogether? High CPU usage is often the cause.

    In this guide, you’ll learn how to identify what’s putting pressure on your server – and how to fix it.

    From bloated plugins to inefficient queries, we’ll cover 10 practical solutions that can quickly reduce CPU load and boost performance.

    We’ll also show how RunCloud helps you monitor, manage, and optimize your server more effectively.

    What Causes High CPU Usage in WordPress?

    If your WordPress site is consuming too much CPU, inefficient plugins or poorly coded themes could be the reason.

    For instance, a plugin performing complex database queries on every page load, like some related posts plugins without proper caching, or a feature-rich theme with numerous dynamic elements that aren’t optimized, can significantly strain the server’s processor.

    Even WordPress core features, such as the built-in CRON job (wp-cron.php), which executes a job on every visit, can contribute to this overhead for busy sites.

    External traffic and background processes are other major contributors to high CPU usage. A sudden surge in legitimate traffic from a viral post can naturally increase CPU load, but so can attacks from bots trying to brute-force logins, scrape content, or exploit vulnerabilities. These bots generate a high volume of requests and force WordPress to execute PHP scripts and database queries repeatedly. Malware infections can also run hidden processes and consume CPU for nefarious purposes like sending spam or participating in DDoS attacks.

    Finally, the underlying server environment and its configuration also play an important role. An underpowered hosting plan, especially shared hosting with limited resources, can quickly hit CPU limits even with moderate traffic. Outdated software versions, particularly older PHP versions, which are significantly slower and less efficient than modern counterparts (like PHP 8.x), can also be a contributing factor.

    Furthermore, a lack of proper caching mechanisms, both at the WordPress level (object cache, page cache) and server-level (like NGINX FastCGI cache or Varnish), forces WordPress to regenerate content dynamically for every request, a highly CPU-intensive operation.

    📖 Suggested read: WordPress Performance FAQs

    Quick Fixes to Instantly Reduce WordPress CPU Usage

    Let’s explore 10 different ways to bring down CPU utilization on servers:

    #1 – Remove or Replace High-CPU Plugins and Themes

    Using process monitoring tools, identify resource-intensive plugins or themes to lower CPU usage. Once found, replace them with more lightweight alternatives or remove them if they are no longer required.

    RunCloud’s server monitoring graphs make it visibly clear when a specific plugin or theme activation is causing CPU spikes, helping you pinpoint the culprit efficiently.

    Poorly coded plugins are notorious for causing high CPU load due to inefficient database queries, excessive background tasks, or unoptimized code execution on every page load. Similarly, themes packed with heavy JavaScript, numerous dynamic elements, or unoptimized built-in features can overwhelm your server’s processor.

    With RunCloud, you get detailed insights into your server’s performance, including slow scripts and slow queries. By observing these metrics before and after deactivating a suspected plugin or switching themes, you can confirm its impact.

    📖 Suggested read: How do you check Linux CPU usage or utilization? (5 Ways)

    #2 – Update WordPress Core, Plugins, and Themes

    After removing unnecessary plugins, ensure that your WordPress core, all plugins, and your theme are updated to their latest versions. Updates often include performance improvements and bug fixes that can reduce CPU load. Outdated software can contain inefficiencies or vulnerabilities that lead to increased resource consumption.

    RunCloud ensures your underlying server stack (like PHP runtime) is easily upgradable with just a few clicks. This provides an optimized and secure foundation that allows your updated WordPress site to perform at its best.

    📖 Suggested read: The Complete WordPress Speed Optimization Guide

    #3 – Optimize Your Database and Clean Up Junk

    If you manage a very large website, you should consider optimizing your WordPress database by cleaning out unnecessary data like post revisions, spam comments, and orphaned metadata, which can bloat tables and slow down queries.

    Using a database optimization plugin or tools such as phpMyAdmin (which RunCloud can help you install and manage) can significantly improve query speed and reduce CPU strain.

    RunCloud simplifies database management by allowing you to easily access and manage your MariaDB/MySQL databases.

    #4 – Set Up Effective Caching (Object, Page, CDN)

    If your WordPress website gets a decent amount of traffic, you should consider implementing caching at multiple levels: object caching (like Redis or Memcached) for database queries, page caching for static HTML versions of your pages, and a CDN to offload assets.

    Caching works by storing frequently accessed data or pre-rendered page content, so the server doesn’t have to generate it from scratch for every visitor.

    • Object caching stores the results of complex database queries
    • Page caching serves full static HTML pages
    • Browser caching tells visitors’ browsers to store local copies of assets.

    Each of these layers helps reduce the direct load on your server’s CPU and PHP processes.

    📖 Suggested read: Best Practices for Caching WooCommerce with RunCloud Hub

    Additionally, a CDN caches copies of your website’s static files on a global network of servers. When a user visits your site, these files are served from the CDN server closest to them, rather than directly from your main hosting server. This drastically reduces the load on your origin server, as it no longer has to serve every single image, CSS, or JavaScript file to every visitor. This dramatically reduces the PHP and database operations needed to serve a page, directly cutting CPU usage.

    RunCloud offers one-click installations for Redis and Memcached and supports server-level page caching like NGINX FastCGI cache, making setup incredibly straightforward.

    #5 – Limit or Disable wp-cron Jobs

    The default wp-cron.php is triggered whenever someone visits your site, and if you have many scheduled tasks or high traffic, it can fire frequently, consuming CPU resources. For example, if multiple visitors hit your site simultaneously, wp-cron.php might try to run multiple times, leading to unnecessary load. Disabling it and using a server cron means tasks run at specific, controlled intervals (e.g., every 2 minutes).

    You should disable the default WordPress cron and replace it with a server-side cron job scheduled at reasonable intervals. This ensures planned tasks run efficiently without impacting user experience or overloading the server during peak traffic.

    RunCloud provides a user-friendly Cron Job manager in its dashboard, allowing you to set up server-level cron jobs with only a few clicks.

    #6 – Block Bad Bots and Malware

    It’s no surprise that malicious bots constantly crawl sites, look for vulnerabilities, brute-force login pages, and scrape content. All of this triggers unnecessary PHP executions and database queries, driving up CPU usage.

    If malware makes it onto your server, it can run hidden scripts, send spam, or launch DDoS attacks – each of which puts a heavy load on your CPU.

    To prevent this, block bad bots and scan regularly for malware. Left unchecked, these threats can waste server resources and slow your site to a crawl.

    RunCloud increases your security by facilitating the setup of Fail2Ban, which automatically blocks IPs showing malicious behavior. While RunCloud is not a WAF, it allows easy integration with services like Cloudflare (including a WAF).

    📖 Suggested read: Best nine htop Alternatives for Linux, Mac & Windows in 2025

    #7 – Optimize Images and Media Files

    Large, unoptimized images slow down your site and increase server load, especially if your theme or plugins resize them on the fly.

    Compressing and resizing images reduces file size without sacrificing quality. This speeds up page loads, cuts bandwidth use, and eases the strain on your server.

    Ideally, you should handle image optimization before upload. Use tools like TinyPNG, Squoosh, or ImageOptim to compress files. For dynamic sites, consider a plugin or CDN that handles responsive image delivery and WebP conversion automatically. The less work your server has to do at runtime, the faster your site will load.

    Advanced Solutions for Persistent High CPU Usage

    When the quick fixes don’t work and your WordPress site is still struggling, you might need to roll up your sleeves and implement more advanced solutions.

    #8 – Switch to LiteSpeed or NGINX Hosting.

    If you regularly encounter issues, consider migrating your WordPress site to a server stack powered by NGINX or LiteSpeed. These web servers are renowned for their superior performance and efficiency in handling concurrent connections compared to traditional Apache.

    NGINX excels at rapidly serving static content and acts as a highly efficient reverse proxy. At the same time, LiteSpeed (especially LiteSpeed Enterprise with LSCache) offers built-in, advanced caching specifically designed for WordPress, often outperforming plugin-based caching solutions. Both options significantly reduce PHP and database processing overhead.

    Their event-driven architecture allows them to manage many requests with lower resource consumption, directly translating to reduced CPU load, especially during traffic spikes.

    RunCloud configures and optimizes an NGINX stack for your WordPress sites by default, providing a high-performance foundation out of the box. If this interests you, then you should learn more about how to migrate your existing web applications to RunCloud.

    📖 Suggested read: How to Install WordPress with RunCloud | Step-by-Step Guide

    #9 – Upgrade Your Hosting Plan or Server Resources

    Sometimes, despite all optimizations, your website’s legitimate traffic, complex functionalities, or sheer size simply demand more processing power, RAM, or faster I/O than your current hosting plan provides.

    If monitoring tools consistently show your server hitting its CPU limits even after thorough optimization, it’s a clear sign you’ve outgrown your current resources. You will need to upgrade to a VPS with more CPU cores, increased RAM, and faster NVMe SSDs.

    Read our “What is the Right Server Size?” documentation guide to learn more.

    #10 – Use Advanced Firewall Rules to Block Malicious Traffic

    If your server sees a sudden uptick in traffic, it may be attacked by malicious traffic. This can range from distributed denial-of-service (DDoS) attacks overwhelming your server with requests, to constant brute-force attempts on your login pages, or automated bots scanning for vulnerabilities.

    Each activity forces WordPress and your server to process unnecessary requests, significantly draining CPU resources. If you regularly face these attacks, you should consider implementing an advanced firewall strategy, encompassing both Web Application Firewalls (WAFs) at the network edge and server-level tools to filter this harmful traffic before it can execute PHP scripts or query your database.

    RunCloud makes it easy to protect your server against these threats.

    For instance, with just a few clicks within the RunCloud dashboard, you can configure Fail2Ban. This powerful tool monitors server logs for suspicious activities, such as repeated failed login attempts or patterns indicative of comment spam bots, and automatically blocks the offending IP addresses.

    Explore strategies like those discussed in “How to Block WordPress Spam Comment Bots With Fail2ban Rate Limiting” to learn more about how to use Fail2Ban specifically for security, including integrating it with Cloudflare or setting up rate limiting to block WordPress spam comment bots.

    RunCloud also supports ModSecurity, an open-source WAF that can provide an additional layer of protection directly on your server.

    RunCloud-managed servers integrate seamlessly with cloud-based WAF solutions like Cloudflare for a more comprehensive, edge-level defense. This combination is particularly effective in securing WordPress login pages using Cloudflare Zero Trust policies.

    Wrapping Up: Who Should Prioritize Fixing High CPU Usage in WordPress?

    Fixing the high CPU usage in WordPress is important for anyone running a serious website.

    • E-commerce store owners can lose direct revenue from slow checkouts or site unavailability.
    • High-traffic bloggers and content publishers risk losing readers and ad impressions due to poor performance.
    • Businesses relying on their website for leads will see conversion rates plummet if their site is sluggish.

    Even agencies and developers managing multiple client sites must proactively address CPU issues to maintain client satisfaction and site stability, as a poorly performing site reflects badly on their services. If your website’s speed, uptime, and user experience are important to you, then monitoring and optimizing CPU usage should be a top priority.

    This is where a robust server management panel like RunCloud becomes indispensable.

    RunCloud provides you with the Server Health Overview for your specific server. Here, you see live, at-a-glance metrics: CPU Usage, RAM Usage, Disk Space, and even Current Load Average.

    Within RunCloud’s settings, you’ll find a Notifications section. Here, you can configure thresholds for CPU usage (e.g., send an alert if CPU is above 80% for 5 minutes). This proactive notification means RunCloud often tells you there’s a problem before your users even notice, allowing you to investigate using the detailed graphs.

    Why RunCloud is a Better Option Than Limited Hosting

    The key advantage of using RunCloud to manage your own VPS is control. Unlike shared hosting, or simply upgrading to a more expensive plan, you get full visibility into what’s happening on your server – along with the tools to act on it.

    With shared hosting, if you hit a CPU limit, your only option is usually to upgrade, often without knowing if it will even fix the underlying issue. With RunCloud managing your VPS, you have the power to:

    1. Implement server-level caching (NGINX FastCGI, Redis, Memcached) with a few clicks.
    2. Easily switch PHP versions or configure PHP settings.
    3. Manage server-level cron jobs.
    4. Install security tools like Fail2Ban.
    5. Fine-tune your web server (NGINX) configuration.

    Switch to RunCloud and start solving performance issues properly.

    FAQs on Fixing WordPress High CPU Usage

    Why is my WordPress site using so much CPU?

    High CPU usage on your WordPress site is often caused by poorly coded plugins, an unoptimized theme, or excessive background tasks like frequent cron jobs. RunCloud provides excellent monitoring features that allow you to pinpoint resource-hungry processes.

    How do I reduce CPU usage in WordPress?

    Start by identifying problematic plugins or themes using monitoring tools to reduce CPU usage. Then consider optimizing images, implementing robust caching (server-level is great!), and ensuring your database is clean. RunCloud’s monitoring can help track the impact of these changes, and its alerts will notify you if usage spikes again.

    Should I switch hosting providers to fix CPU issues?

    Switching hosts can help if your current plan is underpowered, but before you do, make sure you’ve optimized your WordPress site and server configuration. If you’re on shared hosting with limited control, upgrading to a VPS and managing it with RunCloud gives you more resources, better visibility, and the tools to properly diagnose and fix CPU issues.

    Does using a CDN help with CPU usage?

    Yes, a Content Delivery Network (CDN) significantly helps reduce CPU usage by offloading static assets (images, CSS, JS) from your origin server to the CDN’s distributed network. This means your server handles fewer requests, directly lowering its CPU load, an effect you can clearly observe with RunCloud’s server monitoring.

    How do bots and malware increase CPU usage?

    Malicious bots can hammer your site with requests, attempting brute-force logins or scraping content. Malware might also execute hidden scripts or processes, both of which consume significant CPU resources.

    How often should I optimize my WordPress site for CPU?

    You should perform a review and optimization at least quarterly, or whenever you notice performance degradation, make significant site changes, or receive high usage alerts from your monitoring system. RunCloud’s monitoring provides a continuous overview, helping you decide when proactive optimization is needed based on usage trends.

    Can caching plugins cause high CPU usage?

    Ironically, caching plugins can cause high CPU usage if they are poorly configured, conflict with other plugins, or have an overly aggressive cache generation process on a busy site. This is why at RunCloud, we offer server-level caching, which can be more efficient and stable.

  • LiteSpeed Cache WordPress Plugin Configuration Tutorial

    LiteSpeed Cache WordPress Plugin Configuration Tutorial

    LiteSpeed Cache is a caching plugin for WordPress that helps improve the performance of a website by storing frequently accessed data in a cache. This allows the website to load faster for visitors by reducing the amount of time it takes for the server to process and retrieve the necessary data.

    LiteSpeed Cache is built for the LiteSpeed web server, which is known for its high performance and low resource usage.

    In this article, we will walk through the steps of installing the LiteSpeed plugin on your WordPress site and explain how to configure it correctly.

    Why Use LiteSpeed Cache Plugin On WordPress?

    One of the key benefits of using LiteSpeed Cache is that it can significantly improve website loading speed by caching website content and resources.

    Caching involves storing a copy of a webpage’s content and resources, such as images and CSS files, on the server. When a user requests the same page, the server can quickly serve the cached version, rather than having to generate the page from scratch each time. This can greatly reduce the amount of time it takes for a page to load.

    This can lead to a better user experience for visitors, which can help increase engagement and reduce bounce rates. Additionally, a faster website can also lead to improved search engine rankings, as search engines such as Google take page load speed into account when determining page rank.

    LiteSpeed Cache includes other features such as minification and concatenation of HTML, CSS, and JS files to reduce the size of resources. This also helps to decreases the website loading time.

    LiteSpeed Cache also supports CDN integration, which can further speed up page loading times by delivering content and resources to users from a server that is geographically closer to them.

    Suggested read: How To Configure LSCache for Laravel

    How to Install the LiteSpeed Cache Plugin on WordPress

    Installing the LiteSpeed Cache plugin on a WordPress website is a straightforward process. Here are the steps you can follow to install the plugin:

    • In the WordPress dashboard, navigate to the “Plugins” menu, and click on the “Add New” button.
    • In the “Add Plugins” page, type “LiteSpeed Cache” in the search bar, and click on the “Search Plugins” button.
    LiteSpeed Cache plugin homepage
    • From the search results, select the “LiteSpeed Cache” plugin by LiteSpeed Technologies, and click on the “Install Now” button.
    • Once the installation is complete, click on the “Activate” button to activate the plugin.
    • After the plugin is activated, you will see a new “LiteSpeed Cache” menu item in the WordPress dashboard (see below).
    LiteSpeed Cache menu in wordpress
    • Now navigate down to the “General” tab and click on “Request a Domain key” to start using the plugin.

    Configuring Redis ACL with LSCache on OpenLiteSpeed Servers

    On RunCloud, all new Redis instances are secured with Access Control Lists (ACL) by default. If you want to use Redis for object caching in WordPress using LSCache on your OpenLiteSpeed server, you’ll need to perform a few configuration steps.

    Before we go any further, ensure that Redis is installed, activated, and running correctly on your server.

    1. Define the Cache Prefix in wp-config.php

    You’ll need to define a specific cache prefix in your WordPress wp-config.php file. This is necessary for limiting the scope of keys when Redis ACLs are in use. To do this, open your wp-config.php file (found in the root directory of your WordPress installation) and add the following line:

    define('LSOC_PREFIX', 'application-name-rcredis:');

    You must replace application-name-rcredis: with your actual application-specific prefix. You can find the prefix value required for your application, along with the necessary Redis username and password, within your RunCloud dashboard under the “Settings” tab of your web application.

    After adding the correct prefix, save your wp-config.php file.

    1. Configure LSCache Object Cache Settings in WordPress

    Once the prefix is defined, navigate to your WordPress admin dashboard and go to LSCache > Cache, and then click on the “Object” tab. Here, you’ll configure LSCache to connect to your Redis instance using ACL credentials.

    On this screen, you will need to fill the following fields:

    • Object Cache: Set this toggle to ON. This enables LSCache’s external object cache functionality and allows it to use Redis (or Memcached) instead of relying solely on WordPress’s internal object caching.
    • Method: Select Redis from the dropdown menu.
    • Host: This is the IP address Redis listens on. If Redis is running on the same server as your OpenLiteSpeed web server (which is the default and most common setup), then you need to use the value 127.0.0.1.
    • Port: In this field, enter 6379, which is the default network port for Redis.
    • Username: Enter the Redis ACL username provided in your RunCloud dashboard.
    • Password: Enter the corresponding password for the Redis ACL username that you noted in the previous step.
    1. Save Changes and Verify Connection

    After filling in all the above fields using the details from your RunCloud dashboard, click the “Save Changes” button. After saving the changes, refresh the page, LSCache will then attempt to connect to your Redis server using the credentials you’ve provided. If the configuration is correct and Redis is accessible with the given ACL details, you should see a status update similar to this:

    LSCACHE with Redis in OLS
    • Redis Extension: Enabled confirms that your PHP environment has the necessary Redis extension loaded.
    • Connection Test: Passed confirms that the LSCache has successfully connected to your Redis server using the ACL username and password, and can communicate with it for object caching.

    Your WordPress site is now configured to use Redis with ACL for object caching via LSCache, which can significantly improve its performance and scalability.

    Step-By-Step Instructions On How To Configure The Plugin For Optimal Performance

    These are the steps we would advise you follow to configure the LiteSpeed Cache plugin for optimal performance on a RunCloud server:

    1. In the WordPress dashboard, navigate to the “LiteSpeed Cache” menu and click on the “Presets” tab. This tab contains some recommended presets, which are designed to work well for most websites. Pick the one closest to your requirements; we’ll fine tune the individual settings later. 
    2. Under the “Cache” tab:
      • Make sure that “Enable Cache” and “Cache Login Page” are both enabled.
      • Under “Cache TTL“, set the time for which a page will be cached before it needs to be rebuilt. If the content on your website is updated frequently, then you should consider a shorter time period like 5 minutes; if most of the content is static then you can pick longer timeframes such as 1 day, or even a week.
      • Under “Purge All on Upgrade“, select “Auto Purge” if you want the plugin to automatically purge the cache when you update WordPress or any plugins. This is useful because if you’ve recently updated your website’s content or design, you’ll want visitors to see those changes.
      • Under the “Excludes” section you can exclude certain pages or posts from being cached.
      • Enable “Browser Cache” and “Object Cache” to store static files locally in the user’s browser.
    LiteSpeed Cache settings
    1. In the “CDN” tab:
      • Turn on “QUIC.cloud CDN“ and enable “CDN Mapping”.
      • Configure the integration with Cloudflare or a content delivery network (CDN) by switching on the “Cloudflare API” option and entering the necessary information.
    2. Under the  “Image Optimization” tab:
      • Turn on “Auto Request Cron” to automatically optimize images on a schedule.
      • Make sure to turn on “Image WebP Replacement” to start using WebP versions of images. This significantly improves load times by replacing images with a newer image format.
    3. Under the “Page Optimization” tab:
      • Enable “CSS Minification“, “JS Minification“, and “HTML Minification” to minify the appropriate files.
      • Enable “DNS Prefetch Control“ to speed up the loading times of all URLs.
      • Enable “Lazy Load Images” and “Optimize Images on Upload” to optimize image loading and reduce page load times.
      • Turn on “Load JS Deferred” to defer JavaScript execution.
    LiteSpeed Cache js settings
    1. Once you have configured the plugin settings, click on the “Save Changes” button to save the settings.

    It’s important to note that the settings may vary depending on the website structure and the specific needs of the website. Therefore, it’s recommended to consult the plugin documentation for detailed information on configuration and optimization options.

    Testing Performance Improvements

    It’s always a good idea to test the website performance both with and without the plugin, and compare the results to see the actual impact of the plugin on your website’s performance.

    There are several tools available for testing website performance. Some popular options include:

    • Google PageSpeed Insights: This tool analyzes a webpage and provides a score, and suggestions for how to improve its performance.
    • GTmetrix: This tool analyzes a webpage and provides a score, along with detailed information about the page’s load time and resources.
    • Lighthouse: This is an open-source tool that can be run either as a browser extension, or in the command line. It analyzes web pages and provides performance metrics, and suggestions for improvements.

    Troubleshooting Tips For Common Issues

    There are several common issues that users may experience when using the LiteSpeed Cache plugin on a RunCloud server. Below are some troubleshooting tips that can help resolve these issues:

    • Cache not working: Make sure that the LiteSpeed web server and the LiteSpeed Cache plugin are both installed and configured correctly. Also, check the plugin settings to ensure that caching is enabled for the appropriate pages and posts.
    • Integration with Cloudflare or CDN not working: LiteSpeed Cache can integrate with Cloudflare or a content delivery network (CDN) to serve cached pages and resources to visitors. If the integration is not working, check the plugin settings to ensure that the appropriate integration is enabled and configured correctly.
    • Conflicts with other plugins or themes: Conflicts with other plugins or themes can cause issues with LiteSpeed Cache. In such cases, deactivate or remove any conflicting plugins or themes, and check if the issue is resolved.
    • Incorrect page cache: If LiteSpeed Cache is not caching pages correctly, make sure that the plugin settings are configured correctly for your website, and clear the cache.
    • Not seeing any improvements: In some cases, even after proper configuration, you may not see any improvements in website performance. One possible reason is that the website is already performing well, and LiteSpeed Cache is not able to make any significant improvements. In such cases, it’s always a good idea to monitor the website performance, and compare the results both with and without the plugin.

    After Action Report – Monitoring Site Performance

    LiteSpeed Cache is a highly effective caching plugin for WordPress that can significantly improve website performance.

    As your development projects become more complex and your team grows, it’s essential to have more control over your servers, and it’s always a good idea to test and measure the performance difference both with and without the plugin.

    RunCloud provides a comprehensive solution for managing your cloud servers, deploying websites and web applications, and monitoring server health – all through a secure and user-friendly management panel. Sign up for RunCloud today, and see the difference for yourself.

  • How to Block WordPress Spam Comment Bots With Fail2ban Rate Limiting

    How to Block WordPress Spam Comment Bots With Fail2ban Rate Limiting

    Is your website drowning in WordPress comment spam? If you’re battling endless waves of bot-generated junk, you’ve likely tried the usual suspects…

    • Perhaps you’ve implemented CAPTCHAs, only to find they frustrate legitimate users, can still be bypassed by sophisticated bots, and potentially slow down page loads.
    • Maybe you’ve installed anti-spam plugins but worry about their impact on site performance, potential conflicts they introduce, or recurring subscription fees.

    Do you ever wish there was a different, more fundamental way to tackle this?

    Fortunately, there is.

    This guide will walk you through the process of setting up Fail2Ban on your server (specifically tailored for a RunCloud environment, but it is easily adaptable on any other server) to automatically block the IP addresses of bots or individuals who attempt to post comments too frequently on your WordPress sites.

    Instead of analyzing the content of the comment, which can be complex and resource-intensive, this method focuses purely on the frequency of comment submission attempts.

    We will configure Fail2Ban to monitor your web server’s access logs for POST requests to the wp-comments-post.php file. If any single IP address makes more than five such requests within a one-hour period, Fail2Ban will automatically block that IP address at the firewall level for an initial period, with subsequent blocks increasing in duration for repeat offenders.

    Why Use Fail2Ban for Blocking Spam Comments

    We have already written a detailed guide on how to protect your WordPress login page using Fail2Ban. However, you can also use Fail2Ban to reduce spam comments on your site.

    The core idea here is simple: legitimate users rarely post multiple comments in rapid succession across different posts within a short timeframe. Automated bots, however, often hit the wp-comments-post.php endpoint repeatedly as they crawl sites looking for comment forms.

    By setting maxretry = 5 and findtime = 1h, we are telling Fail2Ban: “If you see the same IP address making a sixth attempt (or more) to post a comment via wp-comments-post.php within any 60-minute window, block that IP address.” The first five attempts are allowed, but the sixth triggers the ban.

    Benefits of Using Fail2Ban for Rate Limiting WordPress Comments

    • Server-Wide Protection: This single Fail2Ban rule protects all WordPress sites hosted on the same server that log to the specified NGINX log directory, without needing configuration on each site. If a bot attempts to spam comments across multiple websites hosted on your server simultaneously, its IP address will be quickly blocked based on the cumulative activity seen in the logs. 
    • Protection across the entire website: It doesn’t just stop users from posting comments, it completely blocks the user from even opening the site or accessing it via API for the defined duration. This is much stronger than blocking a spam comment.
    • More Robust Than User/Email Blocking: Spammers frequently cycle through fake or stolen usernames and email addresses, making blocks based on that data less effective; however, obtaining and rotating unique IP addresses at scale is significantly harder and more expensive for them.
    • Protects from Trusted user accounts: Even if a normally trusted (moderated) user account is compromised or a bot inadvertently slips through initial approval, this Fail2Ban rate limit ensures that the user can only submit a handful of comments before their excessive posting frequency triggers an automatic IP block.
    • No Plugin Bloat: This method avoids installing additional WordPress plugins, keeping your site’s codebase leaner and reducing potential third-party code conflicts or vulnerabilities.
    • Firewall-Level Efficiency: The IP blocking is handled by the server’s firewall (like iptables or nftables), which is highly efficient and prevents the spam traffic from even reaching WordPress or PHP, reducing server load compared to application-level filtering.
    • Adjustable Thresholds: You can easily modify the maxretry (attempts allowed) and findtime (time window) parameters in the Fail2Ban jail configuration to make the blocking more or less aggressive based on your observations.

    Drawbacks of Using Fail2Ban for Rate Limiting WordPress Comments

    • Doesn’t Stop Initial Spam: This method is reactive based on frequency. It will not prevent the first one or two spam comments from a new IP address from being submitted; the block only occurs after the threshold (maxretry) is exceeded within the findtime. You still need WordPress-level tools (like Akismet, moderation queues, or disabling comments) to handle those initial attempts.

    📖 Suggested read: 11 Alternatives to reCAPTCHA to Protect Your Site from Spam

    Step-by-Step Instructions for Rate Limiting WordPress Comments Without CAPTCHA

    This section will walk you through the steps for configuring your Fail2Ban client to block spam comments automatically. But before we go ahead, make sure you satisfy the following requirements:

    Prerequisites

    • You will need SSH access to your server with sudo privileges.
    • You need to ensure that Fail2Ban is installed and running on your server. If you are using RunCloud, you don’t need to do anything, as RunCloud includes Fail2Ban out of the box.

    📖 Suggested read: DKIM – What Is It & Why Your Emails Need It

    Step 1: Locate Web Server Logs

    Fail2Ban monitors server logs to block and restrict server access. Therefore, the first step is to identify the location of the NGINX access log files that record incoming requests to your WordPress sites, as Fail2Ban needs to monitor these files for comment submission attempts.

    On servers managed by RunCloud, NGINX stores separate access logs for each web application you’ve created within the /home/<username>/logs/nginx/ directory, named following a pattern like your-app-name_access.log.

    Since you might have multiple WordPress sites (web applications) on the same server and want Fail2Ban to protect all of them with this rule, you need to ensure the logpath directive we configure later correctly points to all relevant access logs.

    Viewing logs for fail2ban access

    📖 Suggested read: 10 Security Tips to Secure a VPS Server in 2025 [Ultimate Guide]

    Step 2: Create the Fail2Ban Filter Definition

    After locating the log files, we need to tell Fail2Ban what pattern to look for in the log files. We’ll create a filter configuration file specifically for WordPress comment posts.

    Open or create the filter file using a text editor like nano:

    sudo nano /etc/fail2ban/filter.d/wordpress-comment.conf

    Paste the following content into the file:

    # Fail2Ban filter for WordPress comment posting attempts
# This filter looks for POST requests to wp-comments-post.php
[Definition]
failregex = ^<HOST> .* "POST /wp-comments-post.php HTTP.*

    Let’s understand this code snippet bit by bit.

    • [Definition]: This standard section header is required for Fail2Ban filters.
    • failregex: This line defines the regular expression to match:
      • ^<HOST>: Matches the client’s IP address (Fail2Ban automatically replaces <HOST> with the IP pattern) at the beginning of the log line.
      • .*: Matches any characters between the IP address and the specific request string.
      • "POST /wp-comments-post.php HTTP.*: Matches the literal string indicating a POST request being made to the WordPress comment processing script.

    After editing the file, save it and exit the editor (in nano, press Ctrl+X, Y, then Enter).

    Step 3: Test the Regular Expression (Optional but Recommended)

    Before enabling the rule, it’s wise to test your failregex against one of your actual NGINX access logs to ensure it correctly identifies comment posting attempts.

    Run the fail2ban-regex command, replacing your-app-name_access.log with the actual name of one of your application’s access log files:

    sudo fail2ban-regex /home/runcloud/logs/nginx/your-app-name_access.log /etc/fail2ban/filter.d/wordpress-comment.conf
    fail2ban regex matching for blocking SPAM comments

    Analyze the provided output. Fail2Ban will report the following metrics:

    1. Lines matched by failregex.
    2. Lines ignored by ignoreregex (should be 0).
    3. Total lines read.

    You should see a positive number of matches if your log file contains recent comment posting attempts (legitimate or spam). It will also list the actual log lines that matched, allowing you to verify. If you don’t see any matched entries, then you will need to troubleshoot your fail-regex before moving forward.

    📖 Suggested read: The 6 Best WordPress Security Plugins (2022)

    Step 4: Create the Fail2Ban Jail Configuration

    Now, we define a “jail” that uses the filter we created and specifies the conditions for banning (like maxretry, findtime) and the ban duration (bantime). It’s important to add this configuration to jail.local to avoid it being overwritten by package updates.

    Open /etc/fail2ban/jail.local with your text editor. If this file doesn’t exist, you can create a new one. By default, Fail2Ban reads from /etc/fail2ban/jail.conf, and it’s best practice to copy jail.conf to jail.local and make your customizations there.

    sudo nano /etc/fail2ban/jail.local

    Scroll to the end of the file and add the following jail definition:

    [wordpress-comment-rate-limit]
backend = auto
allowipv6 = auto
enabled = true
port = http,https
filter = wordpress-comment
logpath = /home/runcloud/logs/nginx/*_access.log
bantime.increment = true
bantime.factor = 6
bantime.maxtime = 1w
bantime = 3h
findtime = 1h
maxretry = 5

    We have already written a detailed Guide to Configuring Fail2Ban, but let’s quickly break down these parameters to understand what they do:

    • [wordpress-comment-rate-limit]: A unique name for this specific jail configuration.
    • enabled = true: Activates this jail. Set to false to disable it without deleting the configuration.
    • port = http,https: Specifies the ports Fail2Ban should block traffic on for the banned IP. Blocking web traffic is appropriate here.
    • filter = wordpress-comment: Tells Fail2Ban to use the filter definition we created in Step 1 (referencing the filename wordpress-comment.conf without the .conf extension).
    • logpath = /home/runcloud/logs/nginx/*_access.log: Specifies the log file(s) to monitor. The wildcard * ensures it monitors the NGINX access logs for all applications managed by RunCloud in the standard location. Adjust this path if your logs are stored elsewhere.
    • maxretry = 5: The number of matches (comment posts) allowed from a single IP before triggering a ban. A value of 2 means the third attempt will trigger the ban.
    • findtime = 1h: The time window within which the maxretry count must occur. If an IP posts more than 5 times within any 1-hour period, it gets banned.
    • bantime = 3h: The initial duration for which the IP address will be banned (3 hours).
    • bantime.increment = true: Enables escalating ban times for repeat offenders.
    • bantime.factor = 6: Multiplier for the ban time. Each subsequent ban for the same IP will be multiplied by this factor (e.g., 2nd ban = 3h * 6 = 18 hours).
    • bantime.maxtime = 1w: The maximum duration an IP can be banned for (1 week). Even with the factor, bans won’t exceed this length.

    If you want to monitor multiple websites using the single configuration, then you can either individually list out the log file for each of the application in its separate line (as shown above) or you can use a wildcard to read all the log files in a directory (/home/runcloud/logs/nginx/*_access.log).

    After making the necessary changes, you can save the file and exit the editor (Ctrl+X, Y, Enter in nano).

    📖 Suggested read: How to Use ModSecurity and OWASP CRS for Web App Firewall (WAF) to Secure Your Website

    Step 5: Reload Fail2Ban Configuration

    For the new filter and jail to take effect, you must reload the Fail2Ban service. To do this, you can simply execute the following command in your terminal:

    sudo systemctl reload fail2ban
sudo systemctl status fail2ban

    Fail2Ban will now start monitoring the specified NGINX logs using your new rule. Now, whenever someone tries to repeatedly post several comments in a short period, your firewall will completely block that IP address for the defined period. 

    If you accidentally block yourself, read our guide on How to Unban an IP Address in Fail2Ban.

    Step 6: Monitor Fail2Ban (Optional but Recommended)

    After enabling the jail, you can check the status of Fail2Ban and see if your new jail is active and if any IPs have been banned. Check the overall status and list active jails:

    sudo fail2ban-client status

    Additionally, you can also get detailed status for your specific jail using the following command:

    sudo fail2ban-client status wordpress-comment-rate-limit

    The above command will show if the jail is running, the filter being used, the log paths, and, importantly, a list of IP addresses currently banned by this specific jail.

    📖 Suggested read: PHP Security – Best Practices To Secure Your Web App in 2025

    Final Thoughts

    This guide has explored an effective, server-level technique to mitigate WordPress comment spam by implementing Fail2Ban rate limiting. This method tackles the problem from a different angle, focusing on the frequency of posting attempts rather than just the content. It provides a powerful layer of defense against automated bots hammering your wp-comments-post.php endpoint.

    What makes this approach particularly effective and distinct from standard WordPress anti-spam plugins is its server-wide application. A single Fail2Ban rule protects all the WordPress sites hosted on your RunCloud server, efficiently blocking malicious IP addresses at the firewall level before they can strain your web application resources. This is usually unachievable with site-specific plugins alone.

    By using Fail2Ban, you gain efficient, low-overhead protection that complements your existing WordPress security practices. This highlights the power of RunCloud: it provides an intuitive platform for managing your servers and applications while still granting you the full underlying access and control necessary to implement advanced, custom security measures like this Fail2Ban configuration.

    Ready to experience powerful, flexible server management that doesn’t lock you out? Sign up for RunCloud today and take control of your web hosting environment.

    FAQs on Stopping WordPress Comment Spam

    Does disabling comments improve site security?

    Yes, disabling comments entirely reduces your site’s attack surface by removing a primary vector for user-submitted content and potential code injection attempts. Although it is not a complete security solution, it eliminates comment-specific vulnerabilities and simplifies security management. But it also removes the way you interact with your users.

    Can comment spam hurt my SEO?

    Absolutely. Excessive spam comments filled with low-quality or malicious links can dilute your page quality, negatively impact user experience, and potentially lead to search engine penalties. They also consume crawl budget and server resources that could be better used on legitimate content.

    Is it safe to allow comments from registered users only?

    It’s safer than allowing anonymous comments, significantly reducing bot spam, but it doesn’t eliminate the threat entirely, as bots can automate registration. To stop fake user signups, you should also implement strong registration security, like email verification and reCAPTCHA on registration forms.

  • How to Install WordPress on Ubuntu

    How to Install WordPress on Ubuntu

    Most Ubuntu servers can handle far more than a single website. Hosting multiple sites on the same server helps you use resources more efficiently and cut costs.

    This guide will walk you through the essential steps for installing and configuring multiple WordPress websites using the popular NGINX (LEMP) stack.

    Why Host Multiple Sites on a Single Server?

    Before diving into the technical steps, let’s clarify why consolidating websites onto one server using NGINX is such a good strategy:

    1. Significant Cost Savings: This is often the most compelling benefit. Instead of paying for multiple hosting plans or servers, you use the hardware or VPS plan you already have, drastically reducing monthly hosting costs.
    2. Optimized Resource Utilization: Make full use of your server’s CPU, RAM, and storage. Many websites, especially those with low-to-moderate or complementary traffic patterns (e.g., one busy during the day, another at night), can coexist happily without demanding excessive individual server resources.
    3. Easier Maintenance: Managing updates and configurations on a single server is often simpler than maintaining multiple separate environments.
    4. Centralized Infrastructure: Server-wide tasks like backups, security scanning, or performance monitoring become more streamlined when focused on a single machine hosting multiple WordPress sites.

    Steps for Hosting Multiple WordPress Sites on Ubuntu via NGINX

    Follow these steps to host multiple WordPress sites on a single Ubuntu server using the NGINX stack.

    For enhanced security and easier management down the line, we’ll follow the best practice of creating a separate database and a dedicated database user for each WordPress site. This isolates each site’s data, preventing potential issues on one site from affecting others.

    Step 1: Install the LEMP Stack (NGINX, MariaDB/MySQL, PHP)

    First, install the LEMP stack (Linux, NGINX, MariaDB, and PHP) which provides the foundation for your WordPress sites:

    • (L)inux: The operating system (Ubuntu, in our case).
    • (E)NGINX: (Pronounced “Engine-X”) Our high-performance web server. This software listens for incoming connections from visitors’ browsers and serves the appropriate web pages or passes requests to other processes (like PHP).
    • (M)ariaDB/MySQL: The database system that stores WordPress content. WordPress needs a database to store posts, pages, user information, settings, theme/plugin options, and more. We’ll install MariaDB, a widely used, community-developed fork of MySQL, which functions as a seamless replacement.
    • (P)HP: WordPress uses the PHP scripting language.
      • php-fpm (FastCGI Process Manager): This library serves web requests with NGINX.
      • php-mysql: WordPress uses this library to communicate with the database.

    Execute the following commands on your Ubuntu server to install the necessary software:

    sudo apt update
sudo apt install nginx php8.3-cli php8.3-fpm php8.3-mysql mariadb-server -y

    In addition to this, WordPress also relies on several specific PHP extensions to perform various tasks such as handling images (php-gd), managing international characters (php-intl, php-mbstring), dealing with XML data (php-xml, php-xmlrpc), working with zip files (php-zip), and making external requests (php-curl). We need to install these alongside PHP-FPM.

    Install these PHP extensions now to avoid errors later:

    sudo apt install php8.3-curl php8.3-gd php8.3-intl php8.3-mbstring php8.3-soap php8.3-xml php8.3-zip -y

    With the core LEMP stack installed, our server now has the essential building blocks ready.

    Step 2: Secure MariaDB/MySQL Installation

    After installing the database server, you need to run the included security script to initialize your database.

    Run the security script and follow the prompts to:

    • Set a root password
    • Remove anonymous users
    • Disallow remote root login
    • Delete the test database
    • Reload privileges
    sudo mysql_secure_installation

    This process is fairly simple, just follow the on-screen prompts and select the default options.

    📖 Suggested read: How to Change/Reset MySQL Root Password on Ubuntu Linux?

    Step 3: Create Database and User for the First WordPress Site

    Create a separate database and user for each site to isolate data and improve security. If you create multiple websites on the same server, you must execute the following commands separately for each site you create, and with unique credentials.

    Log in to the MariaDB/MySQL shell as root:

    sudo mysql -u root -p

    Enter the root password you set during mysql_secure_installation in Step 2 and then create the database using the following command (use a descriptive name, e.g., runcloud_site1_db):

    CREATE DATABASE runcloud_site1_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

    Create a dedicated database user (replace runcloud_site1_user and YourStrongRunCloudPassword):

    CREATE USER 'runcloud_site1_user'@'localhost' IDENTIFIED BY 'YourStrongRunCloudPassword';

    Using ‘localhost’ means this user can only connect from the server, which is more secure.

    Grant privileges to this newly created user only on their specific database:

    GRANT ALL PRIVILEGES ON runcloud_site1_db.* TO 'runcloud_site1_user'@'localhost';

    Apply the changes and exit the MariaDB/MySQL shell:

    FLUSH PRIVILEGES;
EXIT;

    Step 4: Download and Prepare WordPress Files for the First Site

    Next, you need to download and extract the WordPress core files on your server. Before doing that, you must decide where to keep these files. Most website administrators keep these files in the /var/www/ directory. You can do this using the following command:

    sudo mkdir -p /var/www/runcloud_site1.com/public_html

    In the above command, replace runcloud_site1.com with the actual domain or a descriptive name for the site.

    Download and extract WordPress into your site’s root folder:

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

    Extract the archive into the correct folder. Once again, make sure to replace the runcloud_site1.com with the name of the folder that you created earlier.

    sudo tar -xzf latest.tar.gz -C /var/www/runcloud_site1.com/public_html/ --strip-components=1

    Set the correct ownership and permissions so NGINX and PHP-FPM can access them. To do this, replace the runcloud_site1.com in the following command with your domain name and run it in your terminal:

    sudo chown -R www-data:www-data /var/www/runcloud_site1.com/public_html

    Step 5: Configure NGINX Server Block for the First Site

    NGINX uses server block files (similar to Apache’s Virtual Hosts) to manage individual sites. Inside each block, we will define important details about how to handle web requests for this website.

    1. server_name: This tells NGINX which domain name(s) (like yourdomain.com or www.yourdomain.com) this block is responsible for.
    2. root: This specifies the exact directory on your server where the website’s files (your WordPress installation) are located.

    By creating a separate server block for each website, NGINX knows precisely where to direct incoming traffic based on the requested domain.

    Create a new NGINX configuration file for your site in sites-available using the following command:

    sudo nano /etc/nginx/sites-available/runcloud_site1.com.conf

    In this config file, paste the configuration below, making sure you first replace the following placeholders:

    1. runcloud_site1.com and www.runcloud_site1.com with your actual domain(s) or any subdomain you configure in step 6.
    2. /var/www/runcloud_site1.com/public_html with the correct path to your site’s files.
    3. php8.3-fpm.sock with the correct PHP-FPM socket path if you are using a different PHP version.

    If you are unsure how to do this, refer to our blog post, which explains how to edit files on remote servers with SSH and Nano.

    server {
    listen 80;
    listen [::]:80; # For IPv6
    server_name runcloud_site1.com www.runcloud_site1.com; # Your domain(s) here
    root /var/www/runcloud_site1.com/public_html; # Path to WP files
    index index.php index.html index.htm;
    # Handle requests - try file, then directory, then pass to WordPress
    location / {
        try_files $uri $uri/ /index.php?$args;
    }
    # Pass PHP scripts to PHP-FPM
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        # Make sure the socket path matches your PHP version
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
    location = /wp-config.php {
        deny all;
    }
    # Add caching headers for static files (optional but recommended)
    location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|woff|woff2)$ {
        expires 1M;
        access_log off;
        add_header Cache-Control "public, max-age=604800";
    }
    # Handle favicon/robots.txt directly (optional)
    location = /favicon.ico { log_not_found off; access_log off; }
    location = /robots.txt { log_not_found off; access_log off; allow all; }
}

    Save and close the file (Ctrl+X, then Y, then Enter).

    After this, you need to enable the site by creating a symbolic link from sites-available to sites-enabled:

    sudo ln -s /etc/nginx/sites-available/runcloud_site1.com.conf /etc/nginx/sites-enabled/

    After creating the configuration, you can deploy it immediately. However, it is always a good idea to test this configuration before deploying.

    Run the following command to check the syntax of your configuration file:

    sudo nginx -t

    If you get a message that says “test is successful”, you can proceed to the next step. Otherwise, you will need to review your config file for typos.

    Finally, reload NGINX to load the new site configuration using the following command:

    sudo systemctl reload nginx

    Step 6: Configure DNS Records

    Ideally, you should configure your DNS records first, and then install WordPress on your server. DNS propagation is a slow process, and it can take anywhere between 30 seconds and 48 hours for the changes to propagate.

    The exact steps to do this will vary depending on your VPS provider and DNS registrar. For example, if you are using DigitalOcean to host your server and purchased your domain from Cloudflare, then you will need to log in to your Cloudflare account and create an A record for your domain (runcloud_site1.com) pointing to your server’s public IPv4 address.

    Also, create a CNAME record for www pointing to runcloud_site1.com, or a separate A record if you prefer. Add AAAA records if using IPv6.

    If you are hosting multiple websites on the same server, then you will need to create a separate DNS record for each domain name and point them to the same IP address.

    If you face any errors or want to learn more, then we recommend visiting the RunCloud blog, where we have already published in-depth articles on the following topics:

    Step 7: Run the WordPress Installation

    After creating your DNS records, wait a couple of minutes. Once the DNS records have propagated, open your web browser and navigate to your domain name (e.g., http://runcloud_site1.com).

    You should see the WordPress setup screen. Select your language.

    installing WordPress on ubuntu linux server

    In the next step, you’ll be asked for database information. Enter the details you created in Step 3:

    • Database Name: runcloud_site1_db
    • Username: runcloud_site1_user
    • Password: YourStrongRunCloudPassword
    • Database Host: localhost
    • Table Prefix: wp_ (or change if desired)

    WordPress will attempt to connect to the database and create the wp-config.php file. Once the database connection is successful, click “Run the installation“.

    On the next screen, provide your site title, create an administrator username with a strong password, and enter your email address.

    Finally, click “Install WordPress“. Once the installation is complete, you will be greeted with the following screen:

    Now you can log in to your new WordPress dashboard!

    Step 8: Setting Up Additional WordPress Sites (Optional)

    To host more websites (e.g., site2.org), repeat the relevant steps for each new site:

    1. Database: Repeat Step 3 to create a new, separate database (e.g., site2_db) and a new, dedicated user (e.g., site2_user) with a unique, strong password, granting privileges only on site2_db.
    1. Files: Repeat Step 4 to create a new directory (e.g., /var/www/site2.org/public_html), download/extract WordPress into it, and set the correct www-data ownership.
    2. NGINX Config: Repeat Step 5 to create a new NGINX server block file (e.g., /etc/nginx/sites-available/site2.org.conf). Make sure to update the server_name directive to site2.org www.site2.org and the root directive to /var/www/site2.org/public_html. Remember to use the correct fastcgi_pass socket path. Enable the new site (sudo ln -s …), test, and restart NGINX using the commands provided above.
    3. DNS: Repeat Step 6, pointing the DNS records for site2.org (and www.site2.org) to your server’s IP address.
    4. WordPress Install: Repeat Step 7, navigating to http://site2.org (once DNS propagates) and using the database credentials created specifically for site2 during the web setup.

    NGINX uses the Host header from the incoming HTTP request (which contains the domain name the user typed) to match against the server_name directives in your enabled configuration files. This is how it routes traffic to the correct website’s document root and configuration block.

    Final Thoughts & Your Next Steps

    You’ve now installed and configured the LEMP stack to host multiple WordPress sites on Ubuntu using NGINX.

    While your sites are technically up and running, getting them truly production-ready requires additional steps:

    1. Handling Direct IP / Unmatched Domain Visits: What should happen if someone tries to access your server via its IP address directly, or uses a domain name you haven’t configured in an NGINX server block? You should configure a default NGINX block to catch these requests, perhaps redirecting them to your primary website’s homepage or showing a specific landing page.
    2. Optimizing Performance:
      • Image Processing: Installing the imagick PHP extension can significantly improve how WordPress handles image manipulation and optimization, leading to faster load times.
      • Caching: Enabling caching can significantly speed up your website. This can involve several layers: NGINX caching for static assets, PHP opcode caching (like OPcache), and WordPress-level caching plugins (e.g., W3 Total Cache, WP Super Cache).
    3. Securing Your Sites with SSL: In today’s web, HTTPS is non-negotiable. You must configure SSL/TLS certificates for all your domains to encrypt traffic, protect user data, improve SEO, and build trust.
    4. Implementing Automated Backups: What happens if something goes wrong? You must configure regular, automated backups of your website files (/var/www/) and databases.
    5. Adopting a Safe Workflow with Staging: Making changes directly on a live site is risky. Setting up a staging environment allows you to safely test updates (WordPress core, themes, plugins) or new features before deploying them to the public-facing site.

    As you can see, moving from a basic setup to fully managed, secure, and optimized hosting involves considerable ongoing effort. Manually configuring default server behavior, tuning performance, managing SSL certificates for multiple domains, scheduling reliable backups, and setting up staging environments are complex and time-consuming and leave significant room for error, especially as you add more sites.

    This is exactly why we built RunCloud.

    You’ve seen how much time and effort it takes to manually set up and manage multiple WordPress sites on a single server.

    RunCloud does the heavy lifting for you.

    • Deploy WordPress sites in minutes, not hours.
    • Automate SSL, backups, and server configs.
    • Monitor performance and security from a single dashboard.
    • Manage PHP, databases, and firewalls without touching the terminal.
    • Create staging environments with one click.

    Start building faster with RunCloud.

  • How to Use FTP to Upload Files to WordPress Without Password [Step By Step]

    How to Use FTP to Upload Files to WordPress Without Password [Step By Step]

    Have you ever needed to upload a massive plugin that WordPress couldn’t handle? Or dive deep into your website’s files to fix a mysterious error?

    While WordPress is user-friendly, sometimes you need more direct control.

    That’s where FTP (File Transfer Protocol), or more accurately, its secure sibling SFTP (Secure File Transfer Protocol), comes in.

    This article is your comprehensive guide to understanding and using FTP with WordPress. We’ll cover everything from the basics of FTP to uploading files, troubleshooting how to connect securely, navigate your WordPress directory structure, uploading files, troubleshooting common FTP issues, and even how server management platforms such as RunCloud integrate with FTP.

    Whether you’re a beginner blogger or a seasoned developer, mastering FTP can unlock a new level of control over your WordPress website. Stop relying solely on the WordPress dashboard – let’s learn how to take the reins!

    What is FTP?

    FTP is a standard network protocol used to transfer files between two computers on a computer network. It’s a set of rules that computers follow to copy files from one machine to another. While it’s been a fundamental part of the Internet for decades, standard FTP is inherently insecure.

    How Does FTP Work?

    FTP operates on a client-server model. The client (e.g., an FTP software like FileZilla) initiates a connection to the server (e.g., your web hosting server). FTP uses two separate channels for communication:

    1. Control Channel (Port 21 – for plain FTP): This channel is used for sending commands and responses between the client and server. These commands include “login”, “list files”, “change directory”, “upload file”, “download file”, etc. The control channel establishes the connection and manages the session.
    2. Data Channel (Various Ports): This channel is used for the actual transfer of file data.
    3. With SFTP (SSH File Transfer Protocol), the process is different. SFTP is a subsystem of SSH (Secure Shell). It uses a single secure channel (usually port 22) for both commands and data transfer. All communication is encrypted, making it vastly more secure than standard FTP.

    📖 Suggested read: FTP vs. SFTP – What’s The Difference & Why It Matters

    How to Use FTP to Upload Files to WordPress via SSH Key: Step-by-Step Guide

    In this guide, we will walk you through using FTP (specifically, the secure version, SFTP) to upload files to your WordPress website. While WordPress offers a built-in file uploader for media and plugins, FTP provides more control and is essential for certain tasks, like uploading large files, modifying theme or plugin files directly, or troubleshooting.

    Step 1: Choose an FTP Client

    An FTP client is a software application that allows you to connect to a remote server and transfer files. Many free and paid options are available, but for security and ease of use, we strongly recommend choosing one that supports SFTP (SSH File Transfer Protocol).

    We recommend you take a look at our previous blog post titled “The Best 5 FTP Client for Windows and Mac” – but if you’re in a hurry, here are some popular and reliable choices:

    • FileZilla (Free, Cross-Platform): A widely used, well-regarded, free, open-source FTP client. It’s available for Windows, macOS, and Linux.
    • WinSCP (Free, Windows): Another popular free and open-source client, specifically for Windows.
    • Cyberduck (Free/Paid, Windows & macOS): A versatile client that supports FTP and SFTP and cloud storage services like Amazon S3 and Google Cloud Storage. It has a simple, drag-and-drop interface.
    • Transmit (Paid, macOS): A powerful and feature-rich FTP client for macOS, known for its speed and reliability.

    We’ll assume you’ve chosen FileZilla for this guide, but the general steps will be similar for other clients.

    📖 Suggested read: ​How to Use SFTP with FileZilla to Securely Transfer Files on RunCloud

    Step 2: Connect with FTP Credentials from Your Hosting Provider

    Before you can connect, you’ll need your SFTP credentials. These are not the same as your WordPress admin credentials. Your hosting provider (or server management platform) will provide these details. You’ll typically need the following:

    • Host (or Server Address): This is usually a domain name (e.g., example.com) or an IP address (e.g., 192.168.1.1).
    • Username: This is your SFTP username, often specific to your web hosting account or a user you created on your server.
    • SSH Key: A secret key (like a password) associated with your SFTP username.
    • Port: This is usually 22 for SFTP. Never use port 21 (which is for unencrypted FTP) unless you have a very specific and secure reason.

    Finding Your Credentials: The exact steps for finding your credentials will vary for different cloud providers. However, if you’re using RunCloud, this process is quick and painless. Navigate to your server, then to “Web Applications”. Select your WordPress installation, and note down the IP address, username, and root path (highlighted in the image below).

    After this, ensure that the SFTP user you noted in the previous step has SSH access to your server by navigating to the SSH menu of the server section. If the username is missing from the list, follow RunCloud documentation to learn more about generating and storing SSH keys in the RunCloud vault.

    After this, navigate to your server’s “Security” section and ensure that TCP traffic is allowed on the port being used for SSH. It uses port 22 by default, but server administrators often change it to something unique.

    Once you have gathered all the necessary information, you can open your FTP software and create a connection. In Filezilla, you can do this by clicking on “File > Site Manager”.

    In the Site Manager menu, fill in the following information:

    • Protocol: SFTP
    • Hostname: IP address that you noted earlier
    • Port: If you are not using the default port (22), then you need to enter your port number here
    • Logon Type: Key file
    • User: Enter the username that you noted earlier
    • Key File: Browse the files on your computer and select the private SSH key for your server

    After entering the above information, you can connect to the server. But we encourage you to go one step further and switch to the Advanced tab.

    On this tab, you can set the default local directory (the folder where WordPress is installed on your computer) and the default remote directory (the path you noted earlier).

    📖 Suggested read: How to Check if TCP Port is Open, Closed, or in Use on Linux?

    Finally, you can click “Connect” to initiate the connection with your server. The first time you connect to a server via SFTP, your client will likely display a warning about an unknown host key. This is a security measure to prevent man-in-the-middle attacks. Verify the key’s fingerprint against the one provided by your hosting provider (if available). If it matches, you can safely accept the key and proceed.

    Step 3: Navigate to Your WordPress Directory Structure

    Once connected, you’ll typically see two panes in your FTP client:

    • Left Pane (Local Site): This shows the files and folders on your local computer.
    • Right Pane (Remote Site): This shows the files and folders on your web server.

    You need to navigate to the correct directory on your server where your WordPress files are located. The exact path can vary depending on your hosting setup, but if you follow the steps described above, you will be in your WordPress directory.

    ⚠️ Important: Do not modify core WordPress files (in wp-admin and wp-includes) unless you know what you’re doing. Most file uploads will be within the wp-content directory.

    Step 4: Uploading Files to WordPress

    Now that you’re in the correct directory, uploading files is straightforward:

    1. Locate the file(s) on your local computer (left pane).
    2. Navigate to the destination directory on the server (right pane). For example, if you’re uploading a new theme, navigate to wp-content/themes/.
    3. Drag and Drop: Drag the file(s) or folder(s) from the left pane (local) to the right pane (remote). Alternatively, right-click the file(s) and choose “Upload”.
    4. File Transfer Queue: FileZilla will show the progress of the upload in a queue at the bottom of the window.

    Things to keep in mind:

    • Overwriting Files: If a file with the same name already exists in the destination directory, the FTP client will usually ask you if you want to overwrite it. Be cautious when overwriting files, especially if you’re unsure what they are.
    • File Permissions: Sometimes, you might need to adjust file permissions after uploading. This controls who can read, write, and execute files. Incorrect permissions can cause issues with your website. Your hosting provider or RunCloud documentation can provide guidance on appropriate file permissions. Generally, folders are 755, and files are 644.

    Step 5: Verifying Successful Uploads

    After the upload is complete, it’s a good idea to verify that the files were transferred correctly:

    1. Check the FTP Client: FileZilla (and most other clients) will indicate successful transfers in the queue. Look for any error messages.
    2. Test on Your Website: If you uploaded a plugin or theme, go to your WordPress admin dashboard and check if it appears in the Plugins or Themes section. Activate it and test its functionality. If you upload media files, check the Media Library.
    3. Check File Permissions (if necessary): If you’re experiencing issues, use your FTP client or RunCloud’s file manager to check and adjust file permissions as needed.

    By following these steps, you can confidently use FTP (SFTP) to upload files to your WordPress website. This gives you greater control over your site’s files and enables you to perform tasks that might not be possible through the WordPress admin interface alone.

    📖 Suggested read: How to Fix WordPress Stuck in Maintenance Mode? [100% WORKING]

    Troubleshooting Common FTP Issues

    Even with careful setup, you might encounter issues when using FTP to connect to your WordPress server. This section covers some of the most common problems and provides solutions to get you back on track.

    Connection Errors

    Connection errors are often the first hurdle. Here’s a breakdown of common causes and how to fix them:

    “Connection refused” or “Could not connect to server”

    This usually indicates a problem with the server address, port, or firewall. To solve this issue, try the following steps:

    • Verify Credentials: Double-check the Host/Server Address, Username, Password, and Port. Ensure you’re using port 22 for SFTP (and not 21 for insecure FTP). Even a small typo can prevent connection. Copy and paste the credentials directly from your hosting provider’s control panel or RunCloud dashboard to avoid errors.
    • Check the Server Status: Is your server up and running? Your hosting provider’s status page or RunCloud’s server overview will show you if there are any known outages.
    • Firewall Issues: A firewall on your computer, router, or server might be blocking the connection.
      • Local Firewall: Temporarily disable your computer’s firewall (e.g., Windows Firewall, macOS Firewall) to see if it’s the culprit. If it is, you must add an exception for your FTP client (e.g., FileZilla) to allow connections on port 22.
      • Router Firewall: Check your router’s configuration to ensure it’s not blocking outgoing connections on port 22. You might need to forward port 22 to your computer’s internal IP address.
      • Server Firewall: If you’re managing your server (e.g., with RunCloud), check the server’s firewall rules. Ensure that port 22 is open for incoming connections. RunCloud provides a firewall management interface that simplifies this.
    • Incorrect Protocol: Make sure you’re using SFTP, not plain FTP. Your FTP client should have an option to select the protocol.

    “Authentication failed”

    This means your username or password (or both) is incorrect.

    • Double-Check Credentials: Carefully re-enter your username and password. Pay attention to capitalization, as usernames and passwords are often case-sensitive.
    • Reset Password: If you’re unsure of your password, reset it through your hosting provider’s control panel.
    • SSH Key Authentication (Advanced): If you use SSH key authentication instead of a password, ensure your private key is correctly configured in your FTP client, and the corresponding public key is authorized on the server.

    📖 Suggested read: 3 Ways to Fix Too Many Authentication Failures SSH Root? [SOLVED]

    File Permissions Problems

    Incorrect file permissions can prevent your WordPress website from functioning correctly. When uploading files, you might see errors such as “Permission denied,” or your website might display errors or behave unexpectedly.

    Linux (and Unix-like) systems use file permissions to control who can read, write, and execute files and directories. A standard permission set is 755 (owner: read/write/execute, group: read/execute, others: read/execute) for directories and 644 (owner: read/write, group: read, others: read) for files.

    “Permission denied” when uploading

    If you see this error, then you likely don’t have write permission to the target directory. Use your FTP client to change the directory’s permissions.

    Changing Permissions in FileZilla:

    1. Right-click on the file or directory.
    2. Choose “File permissions…”
    3. Enter the numeric value (e.g., 755) or check the appropriate boxes for read, write, and execute.
    4. Optionally, check “Recurse into subdirectories” to apply the changes to all files and folders within the directory.

    Alternatively, RunCloud provides a one-click option named “Fix Permissions” that will fix all permissions issues. Follow the instructions described in the RunCloud documentation to learn how to resolve file access issues on your server.

    Timeouts and Other Common Issues

    Connection Timeouts

    If your connection is slow or unstable, the FTP client might time out before a transfer completes. You can try the following approaches to fix this:

    • Increase Timeout Settings: Most FTP clients have settings to adjust the connection timeout. Increase the timeout value (e.g., to 60 seconds or more).
    • Use a Wired Connection: For a more stable connection, use a wired Ethernet connection instead of Wi-Fi.

    Transfer Failures

    Sometimes, files might fail to transfer completely; ensure you have enough disk space on both your local computer and the server. RunCloud provides a built-in disk usage monitoring solution to make this easy.

    Wrapping Up: Who Should Use FTP for Their WordPress Websites?

    Throughout this guide, we’ve discussed the details of using FTP and, more importantly, its secure counterpart, SFTP, with WordPress.

    The need for direct FTP access is generally low for basic WordPress users (bloggers and small business owners) who primarily focus on content creation and use the standard WordPress interface for tasks like plugin installation and media uploads. The built-in WordPress tools, combined with a user-friendly server management platform like RunCloud, handle the vast majority of day-to-day operations.

    RunCloud, for instance, offers a comprehensive file manager directly within its web-based dashboard. This file manager allows you to browse your WordPress directories, perform basic text file edits, and manage file permissions, all without needing a separate FTP client.

    However, the need for FTP (SFTP) increases as your WordPress usage becomes more sophisticated. Intermediate users, such as freelancers or agencies managing multiple WordPress sites, often need to customize themes and plugins (requiring direct code edits), troubleshoot issues by examining server logs, or upload larger files that might be cumbersome through the WordPress interface.

    In these scenarios, SFTP provides the necessary direct access and control. RunCloud seamlessly integrates with SFTP, offering easy SFTP user management.

    RunCloud provides the perfect balance of ease of use and advanced functionality. Sign up for RunCloud today.

    FAQs on Using FTP with WordPress

    What is the difference between FTP and SFTP?

    FTP transmits data in plain text, making it highly vulnerable to interception. SFTP (Secure File Transfer Protocol) encrypts all communication, including your username, password, and file data, ensuring secure transfers. Always use SFTP; it’s like the difference between a postcard and a sealed letter.

    Do I need FTP to install WordPress plugins?

    Generally, you don’t need FTP to install plugins, as WordPress has a built-in plugin installer through the admin dashboard. However, FTP (specifically SFTP) can be useful for troubleshooting, manually uploading large plugins, or when the built-in installer fails. RunCloud’s file manager offers a web-based alternative to FTP for many tasks, but direct server access via SFTP is still available.

    Can I use FTP on shared hosting?

    Yes, you can usually use FTP (SFTP is strongly recommended) on shared hosting accounts. Your hosting provider will typically provide you with SFTP credentials to access your web space. However, shared hosting environments may have limitations on connection speeds or concurrent connections.

    What are the security risks of using FTP?

    The primary risk of using plain FTP is the unencrypted transmission of your credentials and data, which exposes them to potential eavesdropping. This can lead to a compromised website, stolen data, or malicious code injection. Always prioritize SFTP to mitigate these significant security risks.

    How do I find my FTP credentials?

    Your web hosting provider provides your FTP (SFTP) credentials, often found in your hosting control panel (like cPanel, Plesk, or a custom panel). For RunCloud-managed servers, you can create SFTP users and manage their access through the RunCloud dashboard, granting specific directory permissions. You will typically need a hostname (or IP address), username, password, and sometimes a port number (22 for SFTP, 21 for FTP – but again, avoid plain FTP).

    Is FTP still relevant in 2025?

    While web-based file managers and other tools are becoming more common, FTP (specifically SFTP) remains relevant for developers and power users. SFTP provides a robust and secure way to directly manage files on a server, which is crucial for tasks like debugging, custom development, and large file transfers. It’s a fundamental tool for server management, even with modern alternatives.

    What do I do if my FTP connection keeps dropping?

    Network instability, firewall issues, or server-side restrictions can cause frequent FTP connection drops. Try using a wired connection instead of Wi-Fi, check your firewall settings to ensure SFTP (port 22) is allowed, and contact your hosting provider or check RunCloud’s server logs for potential issues. Sometimes, adjusting the timeout settings in your FTP client can also help.

    How can I speed up my FTP transfers?

    To improve FTP (SFTP) transfer speeds, ensure you have a stable internet connection and use a wired connection if possible. You can also try using an FTP client that supports multiple concurrent connections (if your server allows it) and compressing files before transferring them. Consider the geographical location of your server; transferring files to a server closer to you will generally be faster.

  • How to Edit robots.txt in WordPress (With & Without Plugin)

    How to Edit robots.txt in WordPress (With & Without Plugin)

    Not having a strong web presence is like not existing at all. Your website is your storefront, your portfolio, and your voice.

    Controlling how search engine crawlers discover and interact with it is crucial for its success.

    In this guide, we will discuss the robots.txt file, a critical tool for managing your WordPress robots.txt file and optimizing your site for SEO. We’ll cover everything from the basics of robots.txt rules and directives (like Disallow and Allow) to editing your file using popular SEO plugins or even directly via FTP or cPanel.

    But that’s not all! We’re going beyond traditional search engines.

    In the age of AI, we’ll show you how to manage your website’s presence in tools like ChatGPT and Claude using specific robots.txt user-agent configurations.

    You will also learn to control whether your content is used to train these powerful AI models, giving you unprecedented control over your digital footprint. This feature has become increasingly important with the advancement of AI, so understanding your robots.txt file and web robots in general is more powerful than ever.

    By the end of this guide, you’ll be a robots.txt expert!

    What is robots.txt?

    The robots.txt file is a plain text file in your website’s root directory (e.g., yourwebsite.com/robots.txt). It is a set of instructions for search engine crawlers (also known as bots or spiders) that tells them which parts of your site they shouldn’t access. It’s a tool for controlling how search engines interact with your website, but it’s not a security mechanism. It is a public file that any human or bot can see.

    📖 Suggested read: 15 Best Performance Testing Tools to Improve Your Site

    Purpose of robots.txt

    The primary purpose of robots.txt is to manage crawler traffic, not to hide pages from search results entirely. While it strongly suggests which areas to avoid, it doesn’t guarantee exclusion from search indexes. Here’s a breakdown of its key functions:

    • Preventing Crawling of Duplicate Content: Websites often have multiple URLs that lead to the same content (e.g., with and without “www” or with different URL parameters). robots.txt can help you indicate which version you prefer search engines to crawl and avoid duplicate content penalties.
    • Blocking Access to Sensitive Directories: You might have areas of your website that are not intended for public consumption, such as your admin panel (/wp-admin/ on WordPress), staging environments, or directories containing internal files. robots.txt can tell crawlers to steer clear of these. However, remember that this is a suggestion, not an enforced restriction; for true security, use proper authentication and authorization methods.
    • Conserving Crawl Budget: Large websites, especially e-commerce sites, can have thousands or even millions of pages. Search engines have a limited “crawl budget” – the amount of time and resources they’ll dedicate to crawling a particular site. You can ensure that crawlers prioritize indexing your most valuable content by strategically disallowing less important or dynamically generated pages (like certain search result filters).
    • Specifying the Location of Sitemaps: robots.txt can include a directive pointing search engines to your XML sitemap(s). Sitemaps are lists of all the important URLs on your site, helping search engines discover and index your content more efficiently.

    📖 Suggested read: 10 Best WordPress Management Tools To Easily Manage Multiple Websites

    How Search Engines Use robots.txt

    When a search engine crawler (like Googlebot) visits a website, it typically checks for the robots.txt file first. It parses the file and looks for instructions specifically targeted at it (via the User-agent directive).

    1. User-agent: This line specifies which crawler the following rules apply to. User-agent: * means the rules apply to all crawlers. You can also target specific crawlers, like User-agent: Googlebot.
    2. Comments: Lines starting with # are considered comments and will be ignored by web crawlers.
    3. Disallow: This is the core directive. It tells the crawler not to access the specified URL path. For example, Disallow: /private/ would instruct crawlers to avoid the /private/ directory and everything within it.
    4. Allow: This directive is used to override a Disallow rule. It’s helpful if you want to block an entire directory but allow access to a specific file or subfolder within it. For instance:
    User-agent: *
Disallow: /images/
Allow: /images/logo.png

    The above code snippet blocks access to the /images/ directory, except for the logo.png file. You should note that robots.txt is based on a cooperative system. Reputable search engines (like Google, Bing, etc.) generally respect the instructions in robots.txt. However, malicious bots or scrapers might ignore them completely.

    Therefore, robots.txt should not be relied upon for security; use proper authentication and .htaccess rules for sensitive areas. Also, a disallowed page may still appear in search results if it is linked from other pages.

    📖 Suggested read: How To Install WordPress With RunCloud | Step-By-Step Guide

    Importance of robots.txt For AI Crawlers

    While robots.txt has always been important for managing traditional search engine crawlers, its importance has grown significantly with the rise of AI-powered crawlers. These AI crawlers, used by companies like OpenAI, are designed to gather vast amounts of data from the web, often to train large language models (LLMs) and other AI systems. This introduces new considerations for website owners regarding data usage, privacy, and control.

    Why is robots.txt More Important Now?

    • Data Usage Control: AI models require massive datasets for training. Your website’s content, if crawled, could potentially be used to train these models. robots.txt allows you to express your preference regarding this usage. You can choose to allow AI crawlers to access your content, disallow them entirely, or selectively control access to specific parts of your site.
    • Performance and Bandwidth: AI crawlers can be very aggressive and potentially overload your server. robots.txt can help you manage this by limiting their access or specifying crawl delays (though not all crawlers respect crawl-delay directives).
    • Ethical Considerations: There are ongoing discussions and debates about the ethics of using publicly available data to train commercial AI models. robots.txt allows website owners to participate in this discussion by making their preferences known.
    • Search Indexing: Some AI crawlers enhance search experiences within specific AI products. Controlling access to these can directly impact whether your content is discoverable through these AI-powered search interfaces.

    How to Edit the robots.txt in WordPress

    Two primary ways to edit your robots.txt file in WordPress are using a plugin (generally recommended for ease of use and safety) or editing the file directly (which requires more technical knowledge).

    Method 1: Editing robots.txt with a Plugin

    This is the recommended method for most users, especially beginners. Many SEO plugins offer built-in robots.txt editors, which provide a user-friendly interface and reduce the risk of syntax errors.

    1. Install and Activate an SEO Plugin: You can use popular plugins such as Yoast SEO, Rank Math, All in One SEO Pack, SEOPress, etc. These plugins offer a wide range of SEO features, including robots.txt management.
    2. Locate the robots.txt Editor: The exact location of the editor varies depending on the plugin. Refer to the official documentation of your WordPress plugin to follow along:
    3. Edit the File: The plugin will typically provide a text area where you can view and edit the contents of your robots.txt file. Make your desired changes and exclude any unnecessary paths from crawling.
    4. Save Changes: Click the “Save Changes” or similar button to apply your modifications.
    5. Test your Changes: Use the Google search console’s robots.txt tester to ensure your edits work correctly.

    Advantages of using a plugin:

    • User-Friendly Interface: Simplifies and streamlines the editing process.
    • Syntax Validation: Many plugins will check for basic syntax errors, reducing the risk of accidentally blocking important parts of your site.
    • Integrated with SEO Tools: Often provides seamless integration with other SEO features within the plugin.
    • Reversion Options: Some plugins offer version history or backup options, allowing you to revert to previous versions if needed.

    Method 2: Editing robots.txt without a Plugin

    If you don’t want to use an additional plugin, you can directly access and modify the robots.txt file on your server. However, this requires more technical expertise and, if not done carefully, carries a higher risk of errors.

    1. Access Your Server: You’ll need to connect to your server using one of the following methods:
      • RunCloud File Manager: RunCloud provides a built-in file manager for creating and modifying text files on your server.
      • FTP (File Transfer Protocol): Connect to your server using an FTP client such as FileZilla. Your web hosting provider usually provides your FTP credentials (hostname, username, and password).
      • cPanel File Manager: Most web hosting providers offer cPanel, which includes a web-based File Manager. Log in to your cPanel account and navigate to the File Manager.
      • SSH (Secure Shell): Advanced users can use SSH to obtain command-line access to the server. This requires SSH credentials and familiarity with command-line tools.
    1. Locate the robots.txt File: Navigate to the root directory of your WordPress installation. This is typically the directory where your wp-config.php file is located. If it doesn’t exist, you can create a new plain text file named robots.txt.
    2. Edit the File:
      • RunCloud File Manager: Locate the file and click on it; this will open a text editor in a new browser window.
      • FTP: Download the robots.txt file to your computer and edit it using a plain text editor such as Notepad++, Sublime Text, or VS Code. You can’t use a word processor like Microsoft Word. After editing the file, save it and upload the modified file back to the server, overwriting the existing file.
      • cPanel File Manager: Right-click on the robots.txt file and select “Edit” or “Code Edit” (depending on your cPanel version). Make your changes directly in the web-based editor.
      • SSH: Use the nano or vim command-line text editors to edit your robot.txt file.
    Editing robots.txt in runcloud
    1. Save Changes: Ensure you save the changes you’ve made to the file. If using FTP, ensure the updated file is uploaded and overwrites the old one.
    2. Test Your Changes: After editing your file directly, it is essential to test it. Use Google Search Console’s robots.txt Tester tool to verify that your changes are working as intended and that you haven’t accidentally blocked important content.

    While editing the robots.txt file directly without a plugin can be more technically involved, it offers some distinct advantages for advanced users and those who prefer greater control over their website’s settings.

    📖 Suggested read: How Google Interprets the robots.txt Specification

    This approach ensures that all the necessary features and tools are built directly into the core system. You have complete autonomy over the file’s content and structure without depending on external plugins or add-ons. This eliminates compatibility issues, potential security risks, and the need for additional software installations.

    However, it does have a few disadvantages:

    • Higher Risk of Errors: Requires careful attention to syntax; mistakes can have significant negative consequences.
    • Less User-Friendly: Requires technical knowledge of FTP, cPanel, or SSH.
    • No versioning: If you make a mistake, it will be difficult to revert.

    Unless you are comfortable with server-side file management, a plugin is strongly recommended for editing your robots.txt file in WordPress. If you do choose to edit directly, always test your changes thoroughly using Google Search Console’s robots.txt Tester.

    📖 Suggested read: How to Fix WordPress Revisions Not Showing [SOLVED]

    If you aren’t comfortable with command line tools but still want to edit your configuration files manually, then you should note that RunCloud users can manage and edit their robots.txt through a clean, intuitive interface, offering a safer alternative to direct FTP or SSH access while maintaining control.

    📖 Suggested read: 3 Free Ways To Migrate WordPress From Shared Hosting To Cloud Server

    Managing AI Crawlers with robots.txt

    This section will focus on managing AI crawlers using robots.txt, specifically for OpenAI crawlers. By understanding these crawlers and their user agents, you can control their access to your website’s content.

    OpenAI provides clear documentation on its crawlers, allowing you to make informed decisions about how you want them to interact with your site.

    • GPTBot: This is OpenAI’s primary crawler for training its generative AI foundation models (like those powering GPT-3, GPT-4, etc.). Disallowing GPTBot signals that you do not want your website’s content used for training these models.
    User-agent: GPTBot
Disallow: /

    This example blocks GPTBot from crawling your entire site.

    • OAI-SearchBot: This crawler specifically displays websites in search results within ChatGPT’s search features. Allowing OAI-SearchBot can help your site appear in these results.
    User-agent: OAI-SearchBot
Allow: /

    This allows OAI-SearchBot to crawl your site. You might combine this with a “disallow” command for GPTBot to appear in search results but prevent model training.

    • ChatGPT-User: It is not used to crawl the web automatically. It is a proxy through which a user’s request is sent. It is not used for general training purposes.
    User-agent: ChatGPT-User
Allow: /

    You can combine rules for different crawlers in a single robots.txt file. For example:

    User-agent: *
Disallow: /wp-admin/
Disallow: /private/
User-agent: GPTBot
Disallow: /
User-agent: OAI-SearchBot
Allow: /

    The above example will:

    1. Blocks all crawlers (including traditional search engines) from /wp-admin/ and /private/.
    2. Blocks GPTBot from the entire site (preventing training data collection).
    3. Allows OAI-SearchBot to crawl the entire site (enabling appearance in ChatGPT search).

    While we provided an overview of OpenAI’s crawlers and user agents, we recommend reading AI / LLM User Agents: Blocking Guide to learn more.

    📖 Suggested read: How to Easily Create a WordPress Staging Site in RunCloud

    After Action Report: Mastering Your robots.txt File

    Throughout this guide, we’ve shown you why robots.txt is a small but mighty file that manages how search engines and, increasingly, AI crawlers interact with your website. We discussed its core purposes: managing crawl traffic, conserving crawl budget, and specifying sitemap locations. We also explained that robots.txt is a suggestion, not a security mechanism.

    Controlling your site’s interaction with crawlers is essential for a healthy web presence. You want search engines to index your valuable content efficiently, avoid duplicate content issues, and protect sensitive areas. With the advent of AI crawlers, you also need to consider how your content might be used for training AI models, and robots.txt gives you a voice in that process.

    But managing files directly on your server, especially for tasks like editing robots.txt, can be intimidating. Traditional methods such as FTP clients and cPanel’s File Manager can feel clunky and risk errors if you’re not experienced.

    This is where RunCloud shines.

    RunCloud’s intuitive dashboard provides a built-in File Manager that simplifies server-side file management. No more juggling FTP clients or navigating complex cPanel interfaces!

    • Direct Access: Access your website’s root directory and locate your robots.txt file.
    • Built-in Text Editor: RunCloud’s File Manager includes a powerful yet easy-to-use text editor directly within the dashboard. You can make changes to your robots.txt file, save them, and then be done – all without leaving your browser.
    • Secure and Streamlined: RunCloud’s interface provides a secure and streamlined way to manage server files, minimizing the risk of accidental errors.
    • One-Click Staging: Create a staging environment to experiment with before pushing changes to the live server.

    Ready for Effortless WordPress Management? Choose RunCloud.

    RunCloud isn’t just about simplifying robots.txt management. It’s a complete WordPress hosting platform designed for speed, security, and ease of use. From deploying new sites with a single click to managing server configurations, backups, and security settings, RunCloud empowers you to take control of your WordPress hosting without headaches.

    Here’s why RunCloud is the best choice for your WordPress site:

    • Blazing Fast Performance: Optimized server configurations and caching mechanisms ensure your site loads incredibly quickly, improving user experience and SEO.
    • Robust Security: Built-in security features, including firewalls and regular security updates, protect your site from threats.
    • Effortless Management: An intuitive dashboard makes server management a breeze, even for non-technical users.
    • Scalability: Easily scale your server resources as your website grows.
    • Expert Support: RunCloud’s support team can assist you with any questions or issues.

    Start your free trial today and see how easy WordPress hosting can be.

    FAQs on robots.txt in WordPress

    What is the difference between robots.txt and meta tags?

    Robots.txt is a site-wide file instructing search engine crawlers which directories to avoid. At the same time, meta tags are placed within individual page HTML and control how that specific page is indexed and displayed. Meta tags offer finer-grained control.

    Can I block specific pages with robots.txt?

    In your robots.txt file, you can use the Disallow: directive followed by the specific page’s URL path. For example, Disallow: /private-page/ will block that URL.

    How do I test my robots.txt file?

    Use Google Search Console’s robots.txt Tester tool. This tool validates your syntax and shows if any URLs you intend to block are accessible.

    Is it safe to edit robots.txt?

    Editing robots.txt can impact your site’s search visibility, so proceed cautiously; mistakes can block important content. Platforms such as RunCloud make managing and editing your robots.txt easier and safer through a user-friendly interface.

    What happens if I disallow all in robots.txt?

    Using User-agent: * and Disallow: / in your robots.txt file will instruct all search engines not to crawl any part of your website, effectively removing it from search results.

    Can plugins affect my robots.txt file?

    Yes, some WordPress SEO plugins can create or modify your robots.txt file. Review plugin settings carefully to avoid conflicts or unintended disallow rules.

    How often should I update my robots.txt?

    Update your robots.txt file whenever you make significant changes to your website’s structure or want to adjust which sections are accessible to search engines. Regular reviews are recommended, but not frequent updates.

    What is the correct syntax for robots.txt?

    The basic syntax uses User-agent to specify the crawler (e.g., User-agent: * for all) and Disallow to specify paths to block (e.g., Disallow: /wp-admin/). Allow can override Disallow for specific files or folders within a disallowed directory.

  • Full vs Incremental vs Differential Backup: Backup Types & Differences

    Full vs Incremental vs Differential Backup: Backup Types & Differences

    Are you confused between different backup types, wondering which strategy offers the best protection for your valuable data? Deciding between incremental and differential backup, or even where a full vs. incremental vs. differential backup fits into your plan, can be confusing.

    Understanding the differences between data backup strategies is essential for implementing backup best practices.

    In this article, we’ll explore the advantages and disadvantages of incremental backups and compare them against different backup and recovery methods.

    Whether you’re evaluating cloud backup options, seeking backup solutions for businesses, or simply trying to determine which is better, differential or incremental backup for your specific needs, this guide will clarify these complex concepts and help you make informed choices about your incremental data storage.

    Let’s get started!

    What are Backups?

    Backups are one of the most important components of any system administration strategy. We actively create copies of our critical data from individual files and databases to complete server images, and store them in a secure, separate location. This proactive measure ensures we can recover our systems and information following data loss events, such as hardware failures, accidental deletions, or malicious attacks.

    However, most people think just making a copy of data is enough to protect it.

    A well-planned backup strategy is not just about having copies of data but about having a reliable path to recovery, which also means testing the restores. If you cannot restore a backup, it is useless.

    What is a Full Backup?

    A full backup is a comprehensive copy of all selected data. This includes every file, database record, configuration setting, and other relevant data within a specified system or application. Think of it as taking a complete snapshot of your system at a given time.

    System administrators initiate full backups to ensure they have a complete, independent version of the data readily available for restoration. This type of backup does not rely on any previous backup, making it self-contained and simple to restore from. This is often the most important backup in your entire system.

    RunCloud’s Full Backup Options for Web Apps

    RunCloud provides a user-friendly interface for initiating full backups of web applications.

    In the RunCloud dashboard, you can navigate to the specific web application, and in the “Backup” section, you’ll find options for triggering on-demand backups. These backups can save all of the app’s components, including the web application files, the database (if one is associated), and any related NGINX configurations. RunCloud allows you to specify the backup destination, including local server storage or an off-site location.

    Moreover, you can create schedules for automated full backups by setting the day of the week and the time to run them without intervention. The easy integration with external storage providers such as Amazon S3, Google Cloud Storage, and DigitalOcean Spaces allows for convenient off-site storage of full backups.

    Suggested read: 3 Free Ways To Migrate WordPress From Shared Hosting To Cloud Server

    Pros of Full Backup

    Full backups offer several significant advantages. First, they guarantee the simplest restoration process. Since we have a complete data snapshot within a single backup set, we don’t need to worry about locating previous backups or reconstructing data from multiple sources. We simply restore the full backup, and the system is back to its state when the backup was taken.

    The complete nature of full backups also reduces the risk of inconsistencies when recovering, providing a high degree of confidence that the restored system is functionally identical to the backup state. In addition, full backups can be independently moved and copied to different locations without any other files needed. This self-contained nature facilitates offsite storage for disaster recovery purposes.

    Cons of Full Backup

    While full backups are indispensable, they also have drawbacks. The most notable con is the substantial amount of storage space they consume. Since every file is copied each time, the full backup size can rapidly grow, especially with large databases or web applications with extensive media content. This also directly leads to the second major drawback: backup time.

    Backing up entire systems takes significantly longer than incremental backups, which just track changes. Longer backup times can mean longer backup windows, potentially interfering with production workloads and increasing resource consumption on the server.

    For example, when full backups are performed too frequently, they may overwhelm the network and require more time for restoration in an emergency. Therefore, we must be mindful of optimizing the schedule and location for the most effective use of full backups.

    Suggested read: How Long Does a DigitalOcean Snapshot Take?

    What is an Incremental Backup?

    An incremental backup is an advanced type of backup strategy that focuses on capturing only the changes made since the most recent backup, regardless of whether that was a full or incremental backup. This method differs significantly from a full backup, which copies everything each time. We use incremental backups to quickly and efficiently capture the data alterations made to our systems and applications after an initial baseline is established through a full backup.

    This incremental approach allows for significantly faster backup times and reduces storage consumption as we do not copy the same unchanged data repeatedly. The main idea is to keep our backup window short and minimize resources during the backup process.

    RunCloud’s Incremental Backup Options for Web Apps

    RunCloud streamlines the process of scheduling and managing incremental backups for web applications.

    In the RunCloud dashboard, you can configure the backup settings for a specific web application. The “Backup Frequency” dropdown menu lets us choose how often we want to initiate incremental backups, typically on a daily or hourly schedule.

    RunCloud also displays the “Next Scheduled Backup At” time, allowing precise backup planning and timing.

    The “Backup File Retention” field dictates how long we store each incremental backup, which is important for planning storage usage. RunCloud automatically keeps track of the last full backup and builds subsequent incremental backups.

    Suggested read: How to Copy Files in Linux and Overwrite without Confirmation

    Pros of Incremental Backup

    Incremental backups offer several compelling advantages, particularly for busy web applications. First and foremost, they are far more resource-efficient than full backups in terms of time and space. Because we are only copying changed data, the backup operation completes much faster, placing less load on the server, which means less impact on live web applications.

    This results in a much shorter backup window, which is critical for maintaining system availability. In addition, the smaller size of incremental backups translates directly into reduced storage requirements, saving valuable disk space and associated costs. This makes incremental backups ideally suited for daily or even more frequent backups and allows you to use more backups for smaller RPOs (Recovery Point Objectives).

    Suggested read: How to Easily Clone a Web Application in RunCloud

    Cons of Incremental Backup

    While incremental backups offer great efficiency, they come with some potential downsides. The primary disadvantage lies in the complexity of the restoration process. To restore a system from an incremental backup, you typically must first restore the initial full backup and then apply each subsequent incremental backup in the correct sequence. This recovery process can be more time-consuming and intricate than restoring from a single full backup.

    We must also be aware that if one incremental backup is lost or corrupted, all subsequent backups may become unusable. Therefore, regular verification of the backup integrity and reliability is important. Additionally, the restore process can be harder to troubleshoot in the event of corrupted or lost files in incremental sets. We must weigh these considerations carefully when planning a complete backup strategy and choose the best approach for balancing speed and convenience.

    Suggested read: The 7 Best WordPress Staging Plugins to Create a Test Site

    What is a Differential Backup?

    A differential backup, like an incremental backup, focuses on saving changes, but it does so in a different way. Instead of recording changes since the last backup (regardless of type), a differential backup captures all the changes made since the last full backup. This means that each subsequent differential backup will contain all modifications since the initial full backup.

    For example, if you have a full backup on Monday, the differential backup on Tuesday will include changes since Monday, the differential backup on Wednesday will also include changes since Monday, and so on. We use differential backups as a middle ground between the size efficiency of incremental backups, and the restoration simplicity of full backups. These are generally larger than incremental backups, but they simplify the restore process since we need only one full and the latest differential set.

    Pros of Differential Backup

    Differential backups offer a balance between efficiency and ease of recovery. They are less space-intensive and faster to create than full backups since they don’t always copy all the data. However, unlike incremental backups, we only need two backup sets to complete a restore: the initial full backup and the most recent differential backup.

    This makes the restoration process simpler and faster than using a long chain of incremental backups. Also, because differential backups are based on the last full backup, the set of differential backups is not dependent on each other, creating a more resilient backup approach. This can be especially useful when we require a restore in a time-sensitive manner.

    Cons of Differential Backup

    While offering several benefits, differential backups have some drawbacks. One key disadvantage is that each differential backup grows in size until the next full backup is completed. This can result in differential backups significantly larger than the first differential backup, making them slower to complete as the week progresses.

    Differential backups occupy more disk space than incremental backups because they contain the accumulated changes since the last full backup. This can lead to higher storage costs and longer backup windows. In addition, while the restore process is simpler than incremental, it is still more complex than a full backup alone. We must restore the initial full backup before applying the latest differential backup.

    Difference Between Full vs. Incremental vs. Differential Backup: Which One Should You Choose?

    FeatureFull BackupIncremental BackupDifferential Backup
    Backup SizeLargestSmallestMedium
    Backup SpeedSlowestFastestMedium
    Restore ComplexitySimplestMost Complex (requires multiple restore sets)Medium (requires one full and latest diff)
    Storage UsageHighestLowestMedium (grows with each backup until full backup)
    FrequencyLeast Frequent (e.g., Weekly, Monthly)Most Frequent (e.g., Hourly, Daily)Medium Frequency (e.g., Daily)
    DependencyIndependent, self-containedDependent on Previous full & Incremental setsDependent on the Last Full Backup

    Which Backup is Better for You?

    There is no one size fits all, and each organization or user should adjust as per their needs and requirements. But here are our recommendations:

    • High-Traffic E-commerce Websites:
      • Best Choice: A combination of weekly full backups with daily differential backups.
      • Reasoning: This allows for a balance of faster backups for frequent recovery points and a simpler restore process.
    • Small Blogs or Static Websites:
      • Best Choice: Weekly full backups with daily incremental backups.
      • Reasoning: These websites tend to have fewer daily changes, making incremental backups efficient and easy to manage.
    • Large Databases with High Transaction Volume:
      • Best Choice: Full backups less frequently, with differential and transaction log backups for better recovery points.
      • Reasoning: Large data stores benefit from less frequent full backups and more frequent differential and transaction log backups, which are efficient and can be restored more easily than multiple incremental backups.
    • Budget-Conscious Users:
      • Best Choice: Full backups are less frequently combined with incremental backups as they are the most storage efficient.
      • Reasoning: This approach minimizes storage costs while still having backups to recover from.

    Final Thoughts

    Throughout this guide, we’ve explored different types of backups and discussed the intricacies of full, incremental, and differential strategies. We’ve compared their strengths and weaknesses and shared the knowledge needed to choose the right approach for your specific needs.

    But it’s worth knowing how to put this knowledge into action with RunCloud.

    RunCloud simplifies the entire backup process by offering an intuitive interface for scheduling and managing all types of backups for your web applications.

    Below is a glimpse into RunCloud’s backup dashboard. RunCloud enables you to configure both, full as well as incremental backups for individual web applications and databases with a few clicks.

    It’s easy to schedule backups daily, hourly, weekly, or monthly. You can also define a retention policy that will manage storage for backups. Furthermore, you can store them on local or remote storage with providers such as Amazon S3, Google Cloud Storage, DigitalOcean Spaces, or even your own S3-compliant bucket.

    With RunCloud, you can be confident that your data is protected, accessible, and readily available when you need it, as RunCloud handles all the complex tasks behind the scenes to ensure your backups are taken securely, automatically, and reliably.

    Start using RunCloud today.

    FAQs on Backups

    How often should you do a full backup vs an incremental?

    You should perform full backups weekly as a baseline and incremental backups daily, at minimum, to save frequent changes on your website. RunCloud allows you to easily schedule both types of backups directly from its dashboard.

    What are the pros and cons of full database backups?

    A full database backup offers the simplest restoration path since you have all the data simultaneously. However, full backups can consume considerable storage space and time, particularly for large databases. You can set up “Backup Retention” in RunCloud’s backup management dashboard to streamline this process for optimized efficiency.

    What is a mirror backup?

    A mirror backup is a replica of your data, kept on a separate storage device and immediately available. This type of backup gives near real-time redundancy and minimizes downtime during failures.

    What is the main reason for using incremental backups?

    We use incremental backups to drastically reduce backup times and storage usage. They only save the changes since the last backup. RunCloud supports efficient incremental backups that save valuable server resources. This is critical for high-traffic web applications needing frequent backups.

    What are the four types of backups?

    Full, incremental, differential, and mirror backups are common types of backups. Each of them serves distinct recovery needs.

    What is the 4-3-2 backup rule?

    The 4-3-2 backup rule means you should have four copies of your data across three different media, two of which should be off-site. RunCloud provides storage capabilities to store your backups in different locations (including multiple cloud providers), ensuring a resilient and layered backup strategy.

    What is the 3-2-1-0 backup rule?

    The 3-2-1-0 backup rule means having at least three copies of your data on two different media, with one copy stored offsite. Additionally, you should periodically verify your backups and ensure that they have zero errors.

    Which backup is most efficient?

    Incremental backups are most efficient in speed and storage as they only back up what changed since the last backup. RunCloud simplifies managing incremental backups with ease and offers the optimal balance between speed and storage utilization.

  • How to Remove WordPress Default Image Sizes? (EASY GUIDE)

    How to Remove WordPress Default Image Sizes? (EASY GUIDE)

    Is your WordPress site bloated with unnecessary image sizes, slowing down your performance and hogging precious server space?

    WordPress automatically creates multiple default image sizes when you upload images. These default WordPress image sizes can quickly become a burden if you have a lot of media files on your server.

    This guide will teach you how to remove default image sizes using code snippets in your functions.php file and convenient plugins.

    What are WordPress’s Default Image Sizes?

    WordPress automatically generates several sizes of each image you upload to your media library by default. This allows the WordPress engine to use a custom image with appropriate image quality to cater to various display scenarios across your website. Different use cases often have vastly different image quality requirements. For example, you can get away with serving users low-quality thumbnail images on mobile devices, but if you are displaying a photo album on a large screen, then you would most likely want to use a higher-resolution image.

    WordPress automatically creates default size formats for different scenarios, which act as pre-defined variations of the original image. This approach allows WordPress to serve the most appropriate version based on the context, such as thumbnails, featured images, or larger displays within the content.

    Suggested read: How To Install ImageMagick PHP Extension (Imagick)

    While this system is designed to be helpful, it can sometimes create unnecessary image files, especially if your theme or website design doesn’t use all of these default sizes. This problem is exacerbated if you have a great many images on your website.

    List of Default Image Sizes in WordPress:

    In your WordPress dashboard, navigate to “Settings” > “Media” to view the current media settings configured on your WordPress website.

    media image size in WordPress
    • Thumbnail: Typically, a square image (default is 150×150 pixels) is intended for use in galleries, widgets, and other small display areas.
    • Medium: A mid-sized image (default maximum width and height are 300 pixels) is used in content areas where a larger thumbnail is needed.
    • Large: A larger image size (default maximum width and height are 1024 pixels) is suitable for displaying images within articles or pages requiring more detail.
    • Full Size: The dimensions of the original uploaded image. This is not technically a “default size” in the same sense as the others, as WordPress doesn’t resize the original upload, but it’s always available.

    In addition to the above-mentioned image sizes, themes and plugins can register their own custom image sizes, which can further increase the number of images generated when uploading.

    In the above screenshot, we can see multiple copies of the same image stored in the wp-content folder, each with a different resolution.

    Suggested read: What Are Docker Images And How To Use Them

    Why Remove Default Image Sizes?

    While the automatic creation of multiple image sizes is helpful for most people, there are several compelling reasons to remove or disable some of the default sizes in WordPress.

    The primary reasons are to reduce server storage consumption and improve website performance. Each image uploaded results in multiple saved versions, which can quickly fill up valuable disk space, especially for sites with an extensive media library or frequent image uploads. This excessive storage usage can impact server performance and increase hosting costs, especially with providers that charge based on storage usage.

    Additionally, generating unnecessary image sizes can negatively affect website loading times. Even though WordPress only serves the appropriate-sized image, the server still has to process and create all the various sizes during the upload process, which can consume valuable server resources. Less efficient hosting setups exacerbate this slowdown.

    Moreover, if your theme or design doesn’t use all of these default sizes, you’re essentially creating files that are never used, adding unnecessary weight to your website and potentially impacting user experience.

    By removing unused default image sizes, you can conserve storage space, improve website speed, and enhance overall performance, directly leading to a better experience for visitors and website administrators.

    Suggested read: 10 Best WordPress Management Tools To Easily Manage Multiple Websites

    How to Remove Default Image Sizes in WordPress

    There are primarily two methods for removing default image sizes in WordPress: using plugin settings (if available) or code snippets within your theme’s functions.php file. The code snippet method offers more granular control but requires a basic understanding of PHP and should be approached with caution.

    From WP Admin Settings (Plugin Method)

    The simplest way to remove default image sizes is through a plugin. Many plugins offer this functionality directly within their settings panel; if you’re unsure which plugin to pick, we recommend reading a deep dive into image optimization plugins written by security experts at Patchstack.

    We will use the EWWW Image Optimizer for this tutorial to show you how to do this. Follow the instructions below to change the default image generation behavior of WordPress:

    1. Install and Activate the Plugin: Search for the “EWWW Image Optimizer” plugin and install it through your WordPress admin dashboard.
    2. Access Plugin Settings: In the WordPress admin panel, navigate to the plugin’s settings page and select “Save storage space” during initial installation.

    Suggested read: WordPress.com vs. WordPress.org – The Differences & Which To Choose

    1. Configure Plugin: On the next screen, you will be asked to configure the basic settings for this plugin. Leave these settings to their default value and click “Save Settings”.
    1. Disable Unwanted Sizes: After configuring the plugin, navigate to the “Resize” tab in the plugin’s interface. On this screen, simply uncheck the boxes next to the sizes you wish to disable.

    Suggested read: 3 Free Ways To Migrate WordPress From Shared Hosting To Cloud Server

    1. Save Changes: Save the changes to apply the new settings. From this point forward, WordPress will no longer generate the disabled image sizes upon uploading new images.

    Using Code Snippets (functions.php Method)

    This method involves adding code directly to your theme’s functions.php file.

    We strongly recommend using a child theme to prevent these changes from being overwritten during theme updates. Also, incorrect code can break your site, so proceed cautiously and always back up your functions.php file.

    1. Access your functions.php file: Access this file through your WordPress admin panel by going to Appearance > Theme File Editor. Alternatively, you can access the file directly using an FTP client or “File Manager” from your RunCloud dashboard.
    1. Add code to remove image sizes: To remove specific default image sizes, add the following code snippets to your functions.php file:
    function remove_default_image_sizes( $sizes ) {
    unset( $sizes['thumbnail'] );   // Remove thumbnail size
    unset( $sizes['medium'] );      // Remove medium size
    unset( $sizes['large'] );       // Remove large size
    return $sizes;
}
add_filter( 'intermediate_image_sizes_advanced', 'remove_default_image_sizes' );
    1. Save the functions.php file: After adding the code, save the changes to your functions.php file. This will prevent WordPress from generating the specified image sizes for future uploads. In the following screenshot, we can see that WordPress only created one copy of the image (as we configured) – no additional copies of the image were created.

    Suggested read: The Complete WordPress Speed Optimization Guide

    Best Practices After Removing Default Image Sizes

    After removing default image sizes, following these best practices is recommended to ensure your website displays correctly and remains optimized.

    1. Regenerating Thumbnails: Removing default image sizes only affects future image uploads. Existing images will still have the previously generated sizes. You must regenerate thumbnails to clean up your media library and reclaim storage space.
    2. Checking for Broken Images: After removing image sizes and regenerating thumbnails, it’s recommended to thoroughly check your website for broken images.
    3. Manually Review Pages: Visit your website’s pages and posts, paying close attention to areas where images are displayed, such as galleries, featured images, and within content.
    4. Use a Broken Link Checker: Consider using a broken link checker plugin or online tool to scan your website for broken image links. These tools can identify images that are no longer accessible due to the removal of their corresponding sizes.
    5. Address Broken Images: If you find broken images, replace them with correctly sized versions or adjust your theme’s code to use the appropriate image sizes. WordPress may automatically try to use a similar image size in some cases, so you may not notice broken images unless the appropriate sizes have been completely removed.

    Suggested read: The Best WordPress Caching Plugins To Speed Up Your Site (2025)

    Final Thoughts

    Optimizing your WordPress image handling is a powerful way to improve your website’s performance and user experience. Understanding the default image sizes can significantly reduce server load, conserve storage space, and deliver a faster, more responsive website to your visitors.

    Managing and optimizing a WordPress website can feel overwhelming, but that’s where RunCloud comes in.

    We offer a powerful, intuitive platform to simplify WordPress hosting and unlock peak performance. Forget about complex server configurations and technical headaches. RunCloud empowers you with easy-to-use tools to deploy, manage, and scale your WordPress sites on the cloud infrastructure of your choice.

    We handle the server-side optimizations so you can focus on what matters most: creating amazing content and growing your audience.

    With RunCloud, you get:

    • Blazing-Fast Performance: Optimized server stacks, built-in caching, and easy Cloudflare integration.
    • Simplified Server Management: Our intuitive control panel allows you to easily manage your servers and WordPress sites.
    • Automatic Backups: Rest easy, knowing your website is safe and secure with automated backups.
    • Enhanced Security: Robust security features protect your website from threats, including firewalls and malware scanning.

    Sign up for RunCloud today!

    FAQs on Removing WordPress Default Image Sizes

    Why should I remove default image sizes?

    WordPress generates multiple image sizes by default, bloating your server space and slowing down your website. Removing unused sizes streamlines your media library, leading to faster loading times.

    Will removing default sizes affect my existing images?

    Removing default image sizes only prevents future uploads from generating those specific sizes. Your already uploaded images will remain untouched.

    How can I restore default image sizes if needed?

    You can restore default image sizes by re-enabling the corresponding code in your functions.php file (if you used that method) or deactivating/reactivating the plugin that removed them.

    What plugins can help with image size management?

    Several plugins, like “ThumbPress” or “Disable Generate Thumbnails”, offer user-friendly interfaces for managing and disabling default WordPress image sizes.

    Is it safe to modify the functions.php file?

    Modifying the functions.php file is generally safe if done correctly and carefully. Always back up your functions.php file or use a child theme before making changes. Incorrect code can break your site, so proceed with caution.

    How do I know which image sizes to keep?

    Analyze your theme’s code and website’s layout to identify which image sizes are used in your design. Only keep the image sizes actively displayed on your pages; this will ensure the best performance when delivering images to users.

    What is the impact on SEO when removing image sizes?

    Removing unnecessary image sizes can positively impact SEO by improving your website’s page speed, a key ranking factor for search engines. Faster loading times enhance user experience and reduce bounce rates, potentially boosting your search engine rankings.

  • How To Use Fail2ban With WordPress And Cloudflare Proxy

    How To Use Fail2ban With WordPress And Cloudflare Proxy

    According to financesonline.com, more than 80% of website breaches through hacking involved either brute force, or the use of lost or stolen credentials.

    If you’re running a website, it’s an almost certainty that your website is constantly being bombarded with login attempts. Unauthorized access is a matter of when, not if.

    To ensure your website is secure, and fully protected from this kind of attempted hack, it’s vital to start using a solution such as Fail2ban.

    Fail2ban is a software tool that automatically blocks suspicious IP addresses and prevents them from connecting to your server.

    In this article, we will explain exactly how to make sure that your website is fully protected the right way by showing you how to install and configure IP blocking for your WordPress website using Fail2ban.

    What Is Fail2ban?

    Fail2ban is an open-source software product that monitors log files for suspicious activity. It can be configured to take the action needed to prevent further attacks. This method is widely used to protect web servers, applications, and other network services from brute-force attacks and DDOS attacks.

    Fail2ban is configured by default on RunCloud for SSH logins. If you try to log in to your server via SSH with incorrect credentials, your own IP address will be temporarily banned and you will get the following error:

    ssh: connect to host example.com port 22: Connection timed out

    By configuring a few settings, this protection can also be applied to your WordPress login form.

    Configuring Fail2ban for WordPress

    Start by logging in to your server via SSH – make sure that you have superuser access.

    Locate Log Files

    On NGINX servers, RunCloud stores the log files in /home/runcloud/logs/apache2/ and /home/runcloud/logs/nginx/ – along with the name of each web application. Use the following command to see all available log files of Apache2:

    ll /home/runcloud/logs/apache2/

    In the above example we can see that there are two web applications running on the server, and each of those applications generate both an access log and an error log.

    If you are using RunCloud Docker servers, then you should note that the log processing for RunCloud Docker server is slightly different, even though it uses the RunCloud NGINX environment under the hood. On RunCloud Docker, you can find the NGINX log files in the /home/runcloud/logs/nginx/ directory.

    On OpenLiteSpeed servers, these logs are stored at /home/runcloud/logs. Use the following command to view the logs stored on your server:

    ls -lah /home/runcloud/logs

    Let’s say we want to configure the Fail2ban for the “app-schulist” application.

    We will begin by verifying whether the /home/runcloud/logs/apache2/app-schulist_access.log file is the correct log file to watch for failed login attempts. To do this, run the following command in your terminal to get notified about failed login attempts, (don’t forget to replace “app-schulist” with the name of your application):

    tail -f /home/runcloud/logs/apache2/app-schulist_access.log | grep "POST /wp-login.php"

    After running the command, go to your WordPress dashboard and try logging in with invalid credentials. You should see a log message in your terminal for each failed login attempt.

    terminal screenshot of logs

    Similarly, on RunCloud Docker, you can execute the following command to see recent login requests on your website, (don’t forget to replace “app-lut-gye” with the name of your application):

    tail /home/runcloud/logs/nginx/app-lut-gye_access.log | grep "POST /wp-login.php"

    In the above example, we can see that logs show one POST request was made to the /wp-login.php endpoint of the given website.

    If you are using OpenLiteSpeed servers, just change the path of the log file in the above command. It should look something like following example:

    tail -f /home/runcloud/logs/app-keeling_access.log | grep "POST /wp-login.php"

    Once you have verified the log file, press Ctrl + C in your terminal to stop monitoring for new log entries. Make sure to take a note of the location of this log file.

    Configuring Fail2ban Jail for NGINX and OpenLiteSpeed

    Fail2ban comes with a default configuration file that comes with sensible defaults. It is recommended to leave the default configuration files untouched. If you want to make any changes, you should create another configuration file that overrides the default configuration.

    Run the following command with root privileges in your terminal to create a new file and open it in a text editor:

    cp /etc/fail2ban/jail.{conf,local}
nano /etc/fail2ban/jail.local

    Once you have opened the file, scroll down to the “jails” section using the arrow keys on your keyboard, and then paste the following code to create a new entry. (Once again, make sure to replace the name of the log file with the name that you noted in the last step.)

    [wordpress-auths]
    enabled = true
    port = http,https
    filter = wordpress-auth
    logpath = /home/runcloud/logs/apache2/app-schulist_access.log

    If you have more than one WordPress website on your server, you can append more entries to the logpath variable (as shown above). This will ensure that all of the specified log files will be monitored for the given criteria.

    If you don’t want to constantly add or remove the log path in the configuration file, you can replace the name of the application with * as shown below. This will ensure that all the log files in the given folder (and hence all the application on your server) are being monitored.

    However, you will need to reload Fail2ban after you deploy a new application on your server. You can do this easily, directly from the RunCloud dashboard, by creating a cron job with the appropriate command and running it manually when required.

    If you want to have different settings for each web app, you can create a separate jail for each web application as shown below. Just make sure to specify the correct log files – and give each entry its own unique name (written in green).

    Fail2ban Config file

    After adding the necessary content, press Ctrl + O to save the file and press “Enter” to confirm it. Then press Ctrl + X to exit the text editor.

    Configuring Fail2ban Jail on Docker

    A standard Fail2Ban configuration is insufficient when you deploy Fail2Ban to protect services running inside Docker containers. You will discover that Fail2Ban doesn’t effectively block malicious traffic, even if your jail settings appear correct. That’s because Docker’s networking architecture requires a specific configuration tweak within Fail2Ban.

    By default, Fail2Ban inserts its blocking rules into the INPUT chain of iptables. However, Docker maintains its own set of iptables rules, and the traffic destined for containers bypasses the standard INPUT chain. Therefore, Fail2Ban’s rules, placed in the INPUT chain, are ignored when protecting Dockerized applications.

    To solve this issue, modify your settings to use the DOCKER-USER chain.

    This special chain allows for user-defined rules to be applied before Docker’s internal rules take effect. You can do this by adding chain = DOCKER-USER to your jail configuration.

    The above settings work for default RunCloud servers, but some servers might require you to explicitly define the banaction and backend directives to avoid unforeseen edge cases. To fix this, you should add the snippet banaction = iptables-multiport into your configuration file. This configuration allows you to block multiple ports with a single iptables rule.

    Next, you should add the backend = polling code snippet to configure how Fail2ban periodically polls the log files (i.e., check them at regular intervals) to see if new lines have been added. This is the simplest and most broadly compatible backend. After modifying the configuration, your jail configuration should look something like this:

    [wordpress-auths]
enabled = true
filter = wordpress-auth
logpath = /home/runcloud/logs/nginx/*_access.log
chain = DOCKER-USER
backend = polling
banaction = iptables-multiport
maxretry = 3

    Creating a Fail2ban Filter

    Once you have created a jail, you’ll need to create the corresponding filter that tells Fail2ban which clients to ban in case of a malicious login attempt. Run the following command to create a new filter named wordpress-auth:

    nano /etc/fail2ban/filter.d/wordpress-auth.conf

    Then paste the following text snippet to filter the failed login attempts on NGINX and Docker servers:

    [Definition]
    failregex = ^<HOST> .* "POST /wp-login.php HTTP.* 200
    fail2ban jail file

    For OpenLiteSpeed servers, the regex pattern is slightly different due to a difference in the log format.

    [Definition]
failregex = .+ <HOST> .+POST \/wp-login\.php .*200

    Once again, press Ctrl + O to save the file and press “Enter” to confirm it. Then press Ctrl + X to exit the text editor.

    Testing The Fail2ban Filter (Optional)

    If you are making changes to the production environment, it’s advisable to test out the settings before applying the new ones. You can use the following command to check if a filter is working correctly:

    fail2ban-regex <path to log file> <path to filter>

    For example, the full command would look something like this:

    fail2ban-regex /home/runcloud/logs/apache2/app-schulist_access.log /etc/fail2ban/filter.d/wordpress-auth.conf

    In the above message, “Failregex: 8 total” shows that 8 entries in our log file matched with the filter that we provided. This means that our Regex filter is working correctly. If you want to see which log entries are being matched, you can include --print-all-matched flag before the path of the log file. For example:

    fail2ban-regex --print-all-matched ./app-keeling_access.log /etc/fail2ban/filter.d/wordpress-auth.conf

    In the above example, we can see that our regex pattern matched 22 entries in the given log file, and then listed out each entry which would have triggered a violation.

    Apply the Changes to Fail2ban

    To apply the new changes, you’ll need to restart the Fail2ban service. You can restart the service and check its status by running the following commands:

    systemctl restart fail2ban
systemctl status fail2ban

    In the above example, we didn’t encounter any errors, and Fail2ban was able to restart successfully. If you do face any errors, run the following command to troubleshoot the issue:

    fail2ban-client -x start

    Check Running Jails

    Once you have restarted the service, you can check if your changes were applied correctly. Run the following command to see all of the jails currently configured on your server:

    fail2ban-client status

    Check Banned IPs

    To check where the malicious IP addresses are being banned, try repeatedly logging in to your WordPress dashboard with incorrect credentials.

    By default, if you make five unsuccessful login attempts within ten minutes, your IP address will be blocked for ten minutes. This setting can be configured in the /etc/fail2ban/jail.local file.

    To get detailed information about a particular jail, use the following command, (make sure to replace “wordpress-auths” with the name of your jail):

    fail2ban-client status wordpress-auths

    If you have multiple websites running on your server, the malicious actor will not be able to access any of them due to being listed as a banned IP address. This includes even those sites that are not being monitored by Fail2ban.

    However, if you are using the Cloudflare proxy, this won’t work. Let’s see why.

    Using Fail2ban With Cloudflare

    When you are using Cloudflare proxy to serve your web requests, the IP address used to connect to your server belongs to Cloudflare. Therefore, when you block the IP address after repeated failed login attempts, it blocks Cloudflare’s own IP address – which results in the following error:

    Blocking Cloudflare’s IP address makes it think that the website has crashed – and all visitors from the blocked region will get a 520 error.

    This is obviously unacceptable as blocking one IP address can make your website inaccessible to all users in a country. To fix this we will need to block the malicious traffic before it reaches Cloudflare.

    Restoring Real Visitor IP Addresses with Cloudflare and RunCloud

    Without the real IP, Fail2ban would end up blocking Cloudflare, effectively taking your site offline! To fix this, we need to configure NGINX (your web server) to “restore” the original visitor’s IP address from the information Cloudflare sends. RunCloud makes this incredibly easy with a pre-defined configuration:

    1. Navigate to NGINX Settings: Within your RunCloud dashboard, go to the “Web Application” page for the specific website you’re configuring. Then, find the “NGINX Config” section.
    2. Create a New Configuration: Click on “Create NGINX Configuration”.
    3. Choose the Pre-defined Config: From the “Predefined Config (Optional)” dropdown menu, select “Cloudflare – Restore visitor IP“. This option is specifically designed for this purpose.
    4. Configuration Details (No Changes Needed): RunCloud will automatically fetch the list of IPv4 and IPv6 addresses from Cloudflare’s website and populate the necessary settings.
    5. Save. Save the NGINX configuration.

    Important: You do not need to modify the configuration file itself. The pre-defined configuration is already set up to correctly extract the real IP address from the relevant headers that Cloudflare includes in its requests.

    By following these steps, NGINX will now correctly identify the visitor’s real IP address. Now you can use this information with Fail2ban (and other IP-based security tools) to block offending IP addresses, even behind Cloudflare’s proxy.

    Using Cloudflare Actions to Ban IPs

    To do this we will create a list of bad users who have too many failed login attempts, and then give this list to Cloudflare so that it can block the traffic.

    Go to your Cloudflare Dashboard and generate your API token.

    Once you have opened the API token menu, scroll down to the “Global API Key” menu and view the token. Run the following command in your terminal to open the configuration file:

    nano /etc/fail2ban/action.d/cloudflare.conf

    Scroll down to the bottom of the file using your keyboard arrows, and paste your API key as shown above.

    Next, enter the email address you used to register your Cloudflare account, and then save and exit the file.

    Having done that, you’ll need to edit the /etc/fail2ban/jail.local file to make sure that it uses our newly created action. Scroll down to the jail corresponding to the website that uses the Cloudflare proxy to serve traffic, and add the following line to it:

    action = cloudflare
        iptables-allports

    Save and exit the file. After saving, restart the Fail2ban client to apply the changes. You can run the following command to restart the service, ban a dummy IP address, and check its status. Just make sure to replace “wordpress-auths” with the name of your jail:

    systemctl restart fail2ban
fail2ban-client -v set wordpress-auths banip 22.22.22.22
fail2ban-client status wordpress-auths

    Suggested read: How to Unban IP address in Fail2ban

    Conclusion

    Using Fail2ban with WordPress can greatly enhance the security of your website by protecting it against brute force attacks and other malicious activity. By following the steps outlined in this article, you can easily set up Fail2ban on your WordPress site and start enjoying the benefits of increased security.

    If you’re tired of managing your own servers – you might want to check out RunCloud (yep, that’s us!). RunCloud is built for developers that want to focus on shipping great work, not on managing their infrastructure.

    Discover what a painless server configuration feels like, allowing you to avoid having to spend hours figuring it out. Get started with RunCloud today, and get up and running in minutes.