Category: Linux

Server Cache vs. Browser Cache vs. Site Cache: What’s the Difference?

Slow websites lose visitors. If your store or site takes more than a couple of seconds to load, people leave – and they don’t come back.

That’s where caching comes in.

In this guide, we’ll break down the three main types of website caching:

Server cache
Browser cache
Site (or page) cache

You’ll learn what each one does, how they work together, and why they matter for speed and stability. We’ll also show how tools like RunCloud Hub for WordPress make it easier to manage caching without diving into server configs.

Let’s get into it.

What is Caching?

When a server handles a request, it often needs to process multiple database queries and calculations before responding. This works fine for occasional access, but with repeated requests, it wastes time and server resources by doing the same work repeatedly.

Caching speeds up performance by storing copies of frequently used data in fast-access memory. Instead of regenerating the same content on every request, the server or browser checks the cache first and serves the stored version if available.

On websites, this cached data can include anything from images and stylesheets to entire web pages or database query results.

📖 Suggested read: NGINX Caching for WordPress – Complete Guide & Tutorial

What is Server Cache?

Server cache refers to various caching mechanisms implemented directly on the web server or dedicated caching servers in front of the origin server. This type of caching reduces the server’s processing load by storing the results of computationally expensive operations or frequently requested content.

For instance, if generating a dynamic web page requires multiple database queries and complex calculations, the server can cache the final HTML output of that page.

When another user requests the same page, the server can deliver the pre-generated cached version almost instantly, without re-executing all the backend processes.

Other examples of server caching include opcode caching (storing precompiled script code), object caching (storing frequently used data objects like database query results), or CDN caching (where geographically distributed servers cache static assets closer to users). This significantly improves the server’s capacity to handle more traffic and delivers content faster.

With RunCloud, you can enable server-side caching quickly by installing RunCloud Hub, which includes powerful options like FastCGI and object caching for WordPress.

Read more about caching in our blog post titled How to Easily Optimize Your WordPress Website With RunCloud Hub.

What is Browser Cache?

Browser caching helps speed up return visits to a site by storing common files, like logos, styles, and scripts, directly in the user’s browser. Instead of downloading them again every time, the browser loads them from local storage.

This process dramatically speeds up page loading times for subsequent visits because fetching files from local storage is much faster than retrieving them online. It also reduces bandwidth consumption for both the user and the web server.

Website administrators can influence browser caching behavior by setting appropriate HTTP headers (like Cache-Control and Expires) on their server responses, telling browsers how long they should keep specific files cached.

📖 Suggested read: Everything You Need to Know About WordPress Object Caching

What is Site Cache (Page Cache)?

Site cache, often called page cache, is a type of server-side caching that stores fully rendered HTML pages. When a user requests a page, instead of the server dynamically generating it by querying databases, processing templates, and running scripts every single time, it can serve a static HTML copy directly from the cache. This approach is particularly beneficial for content that doesn’t change frequently for every user, such as blog posts, product pages, or informational pages.

For example, if a popular news article is requested, the server might generate it once, store the complete HTML page in its cache, and then serve that same static file to thousands of subsequent visitors. This bypasses almost all server-side processing, leading to incredibly fast load times and significantly reducing server resource usage.

📖 Suggested read: How to Use Redis Full-Page Caching to Speed Up WordPress

Server Cache vs. Browser Cache vs. Site Cache: Key Differences

Here’s how the three main types of cache compare, based on what they store, where they’re kept, and how they help your site perform better:

Feature	Browser Cache	Server Cache	Site Cache (Page Cache)
Storage Location	On the individual user’s computer (within their web browser)	On the web server itself or on intermediary caching servers (e.g., CDNs, reverse proxies)	On the web server
What is Stored	Static assets (images, CSS, JavaScript files, fonts)	Frequently requested data, database query results, pre-compiled script code, object data, page fragments	Fully rendered HTML pages (what the user sees in the browser)
Primary Benefit	Speeds up subsequent page loads for the specific user by loading assets locally; reduces bandwidth for repeat visits	Reduces the processing load on the origin server; accelerates responses by serving pre-computed or frequently accessed data	Delivers pre-built pages almost instantaneously; bypasses most server-side processing (database queries, PHP execution) for the cached page
Who Primarily Benefits	The individual returning user	All users accessing the site	All users requesting a cached page

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

Which Cache Type is Best for WordPress?

For WordPress sites, page caching (also called site caching) usually gives the biggest performance boost. WordPress dynamically builds each page by running PHP scripts and querying the database, even for content that doesn’t change. Page caching skips all that by storing a fully rendered HTML version of the page and serving it instantly.

This alone can cut load times dramatically.

Browser caching is another must-have. It stores static assets, like logos, stylesheets, and scripts, directly in the visitor’s browser. That means repeat visits feel faster, and your server uses less bandwidth.

For high-traffic or more dynamic sites, you can go further by enabling object caching – a type of server cache that stores the results of frequent database queries in memory using tools like Redis or Memcached. This reduces the load on your database and speeds up dynamic page generation.

When used together, these caching layers improve speed, reduce server resource use, and keep your site stable under load.

📖 Suggested read: LiteSpeed Cache WordPress Plugin Configuration Tutorial

When Should You Use Each Type of Cache?

Use browser caching on all websites to store static assets – logos, stylesheets, JavaScript, and fonts – that rarely change. This significantly speeds up page loads for returning visitors and reduces server bandwidth.
Server cache (in various forms) is essential for any dynamic website to reduce server load and improve user response times.
Use page cache (a type of site cache) for frequently accessed pages that are identical or very similar for most users, such as blog posts, informational pages, or product category pages.
For highly dynamic elements or user-specific content (like a shopping cart or personalized dashboard), more granular server caching, like object caching (for database query results) or fragment caching (for parts of a page), is more appropriate to avoid serving stale or incorrect personalized data.

📖 Suggested read: 9 Redis Alternatives Worth Keeping an Eye On

Final Thoughts

Caching helps your site handle more traffic without increasing server resources. Each type of cache has a specific role, and together, they create a faster, more efficient user experience.

For WordPress users, caching setup can feel complex.

RunCloud Hub simplifies it by handling server-side caching (like FastCGI) automatically, with smart cache purging whenever content is updated.

When a visitor requests a page, if a cached version exists at the server level, it’s served directly by NGINX before WordPress loads or processes PHP and database queries. This bypasses the most resource-intensive parts of WordPress page generation, resulting in dramatically faster load times for your visitors.

RunCloud streamlines the setup and management of these powerful caching mechanisms and allows you to focus on creating great content while we optimize performance. Furthermore, RunCloud intelligently interacts with WordPress to know when content is updated, so it can purge the old cache and serve fresh content, ensuring accuracy.

Caching doesn’t have to be technical. With RunCloud Hub, you can enable server, page, and object caching in just a few clicks – no manual config needed.

If you want your site to load faster, handle more traffic, and use fewer resources, start using RunCloud today.

FAQs on Caching

What is the difference between caching and compression?

Caching stores copies of frequently accessed data (e.g., web pages, images) to serve them quickly on subsequent requests, reducing server load and latency. Compression, on the other hand, reduces the file size of data before it’s transmitted, making downloads faster by using less bandwidth.

Does caching improve SEO rankings?

While caching isn’t a direct ranking factor, it significantly improves website speed and user experience, which are crucial for SEO. Faster load times can lead to lower bounce rates and better engagement, directly impacting search engine rankings.

How do I know if my cache is working?

You can use your browser’s developer tools (Network tab) to inspect HTTP response headers like Cache-Control, Expires, or X-Cache status, which tells if a resource was served from cache. Alternatively, online cache-checking tools or observing significantly faster load times on a second page visit can also confirm its operation.

What happens if I disable caching?

Disabling caching means every user request will fetch fresh data directly from your origin server, significantly increasing page load times and server resource consumption. Increased processing and bandwidth usage can lead to a slower user experience and potentially higher hosting costs.

June 27, 2025

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.
June 12, 2025
7 Best Control Panels for VPS Management (Free & Paid)
Using a VPS to host your websites provides both control and seamless scalability. However, many people find it difficult to work with command-line systems.

Tasks like configuring web servers, database setups, installing SSL certificates, patching vulnerabilities, and updating software stacks suddenly become challenging.

This is where the best VPS control panels become invaluable.

These tools provide a graphical interface to handle all those critical server tasks, which makes VPS hosting accessible and efficient for everyone from solo developers to growing businesses.

In this guide, we’ll explore some of the market’s most popular server control panels, looking at options for every budget. We’ll dive into what makes a great panel, compare popular choices such as cPanel, Plesk, CyberPanel, and CloudPanel, and ultimately show you why we believe RunCloud is leading the pack.

Let’s get started!

What Makes a “Good” VPS Control Panel?

Before we explore and compare different web panels, let’s first understand what makes a “good” VPS control panel:
- Easy to Use (Good UI/UX): The panel should be simple to understand and navigate, even if you’re not a server expert. You shouldn’t need to spend ages learning how to do basic tasks.
- Fast Performance: It should help your websites load quickly by using server resources efficiently, and support modern web technologies like NGINX and the latest PHP versions.
- Strong Security: A good panel offers easy ways to manage firewalls, install SSL certificates (for HTTPS), and protect against common attacks.
- Simple App Management: Installing popular applications like WordPress or phpMyAdmin should be easy with just a few clicks.
- Helpful Server Tools: You need tools to monitor your server’s performance, set up automatic backups, schedule tasks (cron jobs), and manage your databases – all without any hassle.
- Good Support & Clear Guides: When you run into trouble or have questions, you need to be able to find clear instructions or get help from a reliable support team.
- Fair Price & Good Value: Whether free or paid, you want to feel like you’re getting good features and benefits for the cost (or your time, if it’s free).
A Quick Look at Popular VPS Control Panels

Let’s see some of the well-known VPS control panels available today for managing servers and deploying web applications.

cPanel

cPanel has been around for a long time (nearly thirty years), and for good reason. It has provided a wide array of tools for managing websites and servers, making it a popular choice, especially for traditional web hosting companies that manage many client accounts. It offers a familiar interface for users who need to handle everything from email accounts to database management.

However, this comprehensive nature comes with a few considerations. cPanel can sometimes use a significant amount of your server’s resources, potentially impacting performance, and its licensing fees can make it a more expensive option compared to some modern alternatives. While it aims to simplify server tasks, the sheer number of features can feel overwhelming for users new to server management or those who prefer a more streamlined approach.

Additionally, if you are using WHM (WebHost Manager), you’ll typically need to handle the initial server setup yourself, and getting the most out of cPanel often requires a certain level of server knowledge.

This contrasts with solutions such as RunCloud, which are designed to simplify server setup from the start and offer a more focused, modern experience, particularly for developers and performance-conscious users.

Plesk

Plesk is well-regarded for its ability to simplify what’s often called “WebOps”. This makes it easier for IT administrators and web professionals to manage their servers and websites.

Plesk works smoothly with various operating systems, including popular Linux versions such as Ubuntu and AlmaLinux, as well as Windows Server. This flexibility makes it an attractive option for those with specific OS needs or managing diverse server environments. It also supports different web servers like Apache and NGINX, giving users choices in setting up their sites.

Plesk provides a user-friendly web interface for managing your web server. From here, you can set up new websites, manage email accounts, and even control how much server power (like CPU and RAM) each site can use.

It also includes security tools to help you defend against common online threats and offers extensions for things like WordPress management and SSL certificate installation.

While Plesk offers a good set of features and is a viable choice for those who need Windows support or a traditional panel experience, it still operates by being installed directly onto your server.

This approach differs from modern SaaS platforms such as RunCloud, which only installs a small agent on your server to manage it. This results in a lighter footprint on your server’s resources and a more streamlined dashboard, which allows you to deploy or delete server instances with only a few clicks.

CyberPanel

CyberPanel is a control panel that has gained attention for its promise of high performance. One of CyberPanel’s biggest draws is its integration with LiteSpeed web server technology, both the open-source OpenLiteSpeed and the commercial LiteSpeed Enterprise. This focus on LiteSpeed, along with features like built-in caching (LSCache for WordPress is a notable one), is central to its claims of making websites run much faster.

It also offers everyday conveniences, including one-click installers for popular applications like WordPress and Joomla, and free SSL certificates. As an open-source project, it has a thriving community, and many users appreciate the support they can get, especially for a free tool.

While having a free trial and offering potential speed benefits with LiteSpeed is very appealing, it’s worth noting that, like other panels you install directly on your server, managing everything effectively might still require some technical know-how.

Although many open-source projects are powerful, they can sometimes have a steeper learning curve for specific advanced configurations or might not always offer the same polished user experience across all features compared to commercially developed SaaS platforms.

CyberPanel can undoubtedly manage your server and websites. However, if you prefer a solution that handles more of the server management heavy-lifting from a separate, streamlined interface, you should consider RunCloud. It supports OpenLiteSpeed servers and native NGINX, hybrid NGINX (NGINX + Apache), and containerized Docker applications.

CloudPanel

CloudPanel is a modern control panel with a clean user interface. It’s designed with developers in mind and offers support for popular technology stacks like PHP, Node.js, and Python. If you’re looking for a lightweight solution that doesn’t try to be everything to everyone, CloudPanel might catch your eye.

It provides essential site management tools such as database management (MySQL/MariaDB), easy Let’s Encrypt SSL certificate integration, cron job scheduling, and a built-in file manager – all presented in a straightforward way.

We picked CloudPanel for this post because it focuses on simplicity and automation. It aims to streamline the process of setting up new sites and deploying applications, and even offers a command-line interface (CLI) for users who want to automate these tasks. The dashboard provides a quick overview of server health, showing important stats including CPU, memory, and disk usage.

CloudPanel is a good option if you are looking for a simple interface to interact with your web server. However, if you want to manage multiple servers across different cloud providers and grant restricted access to your team members, RunCloud offers far more flexibility and management capability.

Hestia Control Panel

HestiaCP is an open-source control panel recommended by users looking for a free, self-managed solution. HestiaCP offers a solid range of features for managing web domains, including support for multiple domains, easy app installations (like WordPress, Joomla, and Laravel), and NGINX caching options to help speed up websites.

It allows users to manage their own DNS servers, which can be helpful for those who want more control over their domain name configurations. Additionally, it has built-in mail server capabilities that allow you to host your own email accounts, complete with TLS encryption and support for popular webmail clients like Roundcube. This can be a cost-saver for those who don’t want to pay for a separate business email provider.

While HestiaCP provides a comprehensive set of free tools and is quite configurable, you must install and maintain it directly on your server. This means you’re responsible for server updates and troubleshooting.

Also worth bearing in mind is that if you want an option to create and manage different workspaces from a single dashboard to manage server resources for multiple clients, then HestiaCP might not be right for you.

VestaCP

VestaCP is another great control panel released under open-source licenses. It offers all of its core functionality for free. However, many of its advanced features are available as add-ons or plugins that are sold separately.

You can use VestaCP to manage your domain names and easily set up DNS records. It integrates with Let’s Encrypt to provide free SSL/TLS certificates, essential for secure websites today. It also handles database management, allows you to manage your website files directly, and schedule tasks using cron jobs.

In addition to basic site management, VestaCP includes server administration features. You can manage user accounts with different permission levels, configure backups to protect your data, and monitor your server’s resource usage, such as CPU, memory, and disk space, to monitor performance. It also includes a firewall to help secure your server, with plans for additional security such as a Web Application Firewall (WAF) in future versions.

While VestaCP offers a broad suite of tools at no cost, it’s important to remember that it does not have a dedicated support team. Since it is open-source software, you will not get a dedicated support assistant to look into your problems, and instead, you’ll have to rely on community forums to resolve your issues.

Additionally, you can also expect slow updates and sparse documentation. When a vulnerability is discovered, it might not get patched for days, which makes it a huge security risk if you plan to host a website that needs to follow specific regulations and protect customer data.

RunCloud

RunCloud is the premier choice for modern cloud server management. What sets RunCloud apart is its intelligent architecture.

Unlike traditional control panels that install directly onto your server and consume its precious resources, RunCloud securely connects to and manages your server remotely.

This is a better approach as your server’s power is dedicated solely to your applications, not to running a heavy panel.

Plus, you gain a single, elegant dashboard to oversee all your servers, which is incredibly efficient. This modern design is complemented by an exceptionally user-friendly and sleek interface, which makes complex server tasks feel intuitive, whether you’re a seasoned developer or just starting with a VPS.

In addition, RunCloud is engineered for top-tier performance and robust security. It provides an NGINX stack optimized for speed right from the start, supports various advanced caching mechanisms like Redis and Memcached, and allows you to switch PHP versions effortlessly.

RunCloud comes with sensible security features that are enabled out of the box. For example, it contains:
- A one-click Let’s Encrypt SSL certificate that auto-renews
- Integrated firewall management
- Proactive server hardening.
Developers and agencies should pay special attention to features such as Git deployment, atomic (zero-downtime) updates, and dedicated staging environments.

These features make it easier to deploy new WordPress sites with one click, and manage databases, cron jobs, server health, and even team collaboration – all of which are streamlined and efficient.

Key Features of RunCloud:
- SaaS-Based Architecture: Manages your server remotely, keeping it lean and fast.
- Optimized Performance: Native NGINX, advanced caching (Redis, Memcached), and the latest PHP versions.
- One-Click WordPress Deployment: RunCloud simplifies deploying new WordPress sites, installs necessary plugins, and configures DNS records – all with a single click.
- WordPress Staging Environments: Before going live, you can safely test changes on WordPress sites. RunCloud provides free test domains for this purpose, so you don’t need to worry about DNS configuration either.
- Modern Security: Automated Let’s Encrypt SSL, firewall management (Fail2Ban), server hardening.
- Server Health Monitoring & Alerts: RunCloud keeps you informed about your server’s resource usage.
- Reliable Backup Solutions: Automated and on-demand off-server backups.
- Team Collaboration Features: Manage server and web application access for your team.
- Developer-Centric Tools: Git deployment, atomic updates, WP-CLI, Composer, Docker support.
- RunCloud API: For custom automation and integrations.
Why Paying for RunCloud is a Smart Investment for Your Business

While many VPS control panels offer a free tier to get you started, RunCloud can transform your server management and, by extension, your business. RunCloud allows you to manage more servers, access advanced features such as staging environments and backup options, use team collaboration tools, and receive priority support.

But perhaps the real value lies in the immense amount of time you save.

Think about the hours spent on command lines, configuring security, manually updating software, or troubleshooting performance issues. RunCloud automates and simplifies these tasks to an incredible degree.

Instead of being bogged down with server administration, you can focus on developing new products, serving your clients, marketing your services, and innovating. When considering the cost of your time or the potential expense of hiring a dedicated server administrator, a RunCloud subscription is exceptionally good value.

Conclusion: Use RunCloud to Manage your VPS

Choosing the right VPS control panel can feel like a major decision, and as we’ve seen, several capable options exist. While other panels have their merits and serve specific needs, RunCloud truly stands out by offering an exceptional balance of ease of use, raw power, blazing-fast performance, and a suite of genuinely modern features.

What makes RunCloud particularly compelling is its universal appeal. If you’re a beginner just dipping your toes into the world of VPS hosting, RunCloud’s intuitive user interface and generous free tier make it incredibly welcoming, removing the fear factor from server management. You can get started, deploy your first WordPress site, and learn the ropes all without feeling overwhelmed.

But for seasoned developers, agencies, and businesses, RunCloud scales beautifully. Its developer-centric tools, like Git deployment, staging environments, API, and team features, allow you to efficiently build, deploy, and manage complex applications.

Ultimately, RunCloud simplifies the complexities of server administration so you can focus on what you do best: building amazing things online.

Ready to experience the RunCloud difference firsthand? Sign up for your free account today.

Have questions or need a little guidance getting started?
Dive into our comprehensive documentation or talk to us directly in our friendly community.
June 7, 2025
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.
- 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).
- 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:
- 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.
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.
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.
May 23, 2025
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.

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.
May 6, 2025

The Best Docker Alternatives for Containerization in 2025

Docker has changed software development and application deployment through containerization. Its intuitive command-line interface, tools such as Docker Desktop, and the vast Docker Hub ecosystem have all made creating, sharing images, and running containerized applications incredibly accessible.

But many people don’t realise that the Docker engine isn’t the only containerization technology available.

This post will discuss some of the best alternatives to Docker and compare powerful options that adhere to the Open Container Initiative (OCI) standards.

Whether you’re concerned about security, optimizing for Kubernetes clusters, managing container images across different container registries, or simply seeking improvements in your container management strategy, by the end of this article, you will be able to find the best containerization platform for your specific needs.

Let’s get started!

What is Containerization?

Containerization is a new way to deploy applications on a remote server. Traditionally, we’ve been copying the application’s source code and executing it on the remote server.

However, containerization technology allows us to bundle an application’s code and all its necessary dependencies, libraries, configuration files, and binaries, into a single, isolated unit called a container. This container image is a self-sufficient package that can run consistently across different computing environments, from a developer’s laptop to production servers in the cloud or on-premises data centers.

In Linux, containerization uses operating system-level virtualization features, such as namespaces and control groups (cgroups). Unlike traditional virtual machines (VMs) that require a full guest operating system for each instance, containers share the host system’s OS kernel. This makes containers very lightweight, faster to start, and less resource-intensive than VMs. This allows developers to deploy multiple containers on a single VM for higher density and more efficient use of underlying hardware resources.

📖 Suggested read: 20 Essential Docker Commands You Should Know

Best Docker Alternatives for Containerization

Docker is by far the most popular container runtime available. So much so that many people use the terms ‘Docker’ and ‘containers’ interchangeably – but it isn’t the only containerization technology.

Let’s take a look at alternative container runtimes that you can use instead of Docker:

S No.	Name	Visit Website
1	Podman	https://podman.io/
2	Linux Containers	https://linuxcontainers.org/
3	Red Hat OpenShift	https://www.redhat.com/en/technologies/cloud-computing/openshift
4	Apptainer/Singularity	https://apptainer.org/
5	Containerd	https://containerd.io/
6	Cri-o	https://cri-o.io/
7	Mirantis Container Runtime	https://www.mirantis.com/software/mirantis-container-runtime/

Podman

Podman is a helpful tool for anyone working with software containers. It lets you easily find, download, run, build, and share containers using straightforward commands like search, pull, run, build, and push. One special thing about Podman is its ability to group related containers into ‘pods’, which makes it easier to manage applications where different parts need to work closely, similar to how bigger systems like Kubernetes operate.

If you prefer using a visual interface instead of typing commands, you can use the Podman Desktop application on Windows, macOS, and Linux. This app gives you a single screen to manage your containers, even if they were created with other tools such as Docker.

Podman Desktop makes building new container images simple, as well as getting images from online repositories, grouping containers into pods, and checking logs. It even helps you prepare and move your container applications to run on Kubernetes.

📖 Suggested read: How to Create a Docker Image for Your Application

Linux Containers

Linux Containers, often abbreviated as LXC, are one of the longest-standing options built directly on the Linux kernel and include features such as namespaces and groups. LXC aims to create environments close to a standard Linux installation but without a separate kernel. This differs slightly from Docker, which typically focuses on packaging a single application and its dependencies.

LXC is geared more towards running a ‘system container’ – a lightweight virtual machine that can run multiple services or a full init system inside. This ‘system container’ approach might not be a drop-in replacement for your Docker workflow and may require you to configure how you deploy applications.

LXC uses powerful Linux features and offers management tools and libraries (like liblxc). It mimics a full OS environment, which might be more than most people need for simple application isolation. LXC could be great if you needed to replicate a traditional server setup within a container, but if you are just looking to run your apps, it might introduce unnecessary complexity.

📖 Suggested read: Docker Security: Best Practices to Secure a Docker Container

Red Hat OpenShift

Red Hat OpenShift is much more than just a container runtime. It is a full-fledged application platform built on Kubernetes designed to handle the entire lifecycle of applications, from development and building to deployment and management at scale, even across different cloud environments or on your own servers.

If you just want to build and run containers, this might not be the right tool for you. Red Hat OpenShift is designed to provide a consistent environment with integrated tools for building, automating deployments (like CI/CD pipelines), and managing applications, not just basic container orchestration.

The platform offers different ways to use it, either as a managed service on clouds like AWS or Azure, where Red Hat handles the underlying infrastructure, or as a self-managed service for more control. It also has built-in security, developer tools, and the ability to manage virtual machines alongside containers.

While Red Hat OpenShift is a powerful tool, especially for larger teams or complex applications that need this robust management and security, it is also more complex than just using Docker. Therefore, you must weigh whether the comprehensive features justify the potential learning curve and operational overhead for your needs.

📖 Suggested read: How to Install WordPress on Docker in 2025 [Step-By-Step Guide]

Apptainer

Apptainer, which used to be called Singularity, is another tool for packaging and running software inside containers, similar to how Docker works. It’s open-source software, now part of the Linux Foundation, and designed to be straightforward, quick, and safe. Apptainer is particularly popular in environments where many people share the same computer systems, like university computing clusters or research labs, and for running software that needs a lot of computing power.

It primarily focuses on performance-intensive applications commonly found in High-Performance Computing (HPC), scientific research, and AI/ML workloads. It is designed for environments where maximizing computational performance, managing complex software stacks, ensuring reproducibility, and handling specialized hardware like GPUs is very important.

Apptainer is different in handling containers and interacting with the computer it’s running on. It packs everything into a single file, making the container easy to copy, move between computers, or share with others. Apptainer also lets the software inside the container easily use special hardware on the host machine, like powerful graphics cards (GPUs) or fast network connections, which is important for scientific computing.

Its security approach is also quite simple: by default, you have the same permissions inside the container as you do outside, which helps prevent users from accidentally gaining extra privileges on the system.

📖 Suggested read: What Are Docker Logs And How To Use Them

Containerd

Containerd is a core container runtime focused on managing the complete container lifecycle. This includes tasks like image transfer and storage, container execution and supervision, low-level storage, and network attachments.

It might surprise you that Docker uses containerd under the hood (or components derived from it), meaning containerd isn’t necessarily a replacement for the entire Docker developer experience, but rather the engine component that does the heavy lifting.

However, it is much lower-level than the Docker run command, as it exposes the distinct stages of container creation and execution. Rather than providing developers with a simple, all-in-one command-line interface, it’s designed more for integration into larger systems or for users who need fine-grained control.

It has well-established documentation, API, and client libraries, particularly for the Go client for programmatic control. You can easily use this client to connect to the daemon, pull images, create OCI specs, manage snapshots (container filesystems), and much more.

While containerd is a crucial piece of the container ecosystem and the standard runtime interface (CRI) implementation for Kubernetes, it doesn’t directly replace the user-facing Docker command-line tool and its associated build/compose functionalities out of the box. Instead, it replaces the runtime part that Docker traditionally managed.

If you are looking for just the runtime component, containerd is the go-to option. However, replicating the full Docker developer workflow requires other tools (such as nerdctl for a Docker-compatible CLI or build tools like BuildKit).

📖 Suggested read: Bringing Containerization to RunCloud’s Cloud Architecture

Cri-o

If you are working with Kubernetes, you might already be familiar with CRI-O. It is a lightweight Kubernetes Container Runtime Interface (CRI) implementation. This means its primary purpose isn’t to be a general-purpose container engine like Docker, but rather to provide exactly what Kubernetes needs to manage container lifecycles (pods) efficiently and reliably, using standard OCI-compliant runtimes like runc underneath.

CRI-O acts as the bridge between the Kubernetes kubelet and the low-level container operations. It handles pulling images from any OCI-compliant registry, managing container storage, generating the OCI runtime spec, launching the actual runtime (like runc), setting up networking via CNI, and using conmon for monitoring. Concentrating only on these Kubernetes-essential tasks, it aims to be more stable and resource-efficient within a cluster than a more feature-rich daemon like Docker’s.

If you are thinking of replacing Docker, you can use CRI-O to replace the runtime component on the Kubernetes nodes. However, you should note that it doesn’t offer a direct replacement for the Docker command-line interface or tools such as Docker Compose for local development workflows.

Mirantis Container Runtime

Mirantis Container Runtime (MCR) is similar to ‘Docker Engine – Enterprise’. It is designed to be compatible with the core Docker API and commands you might already know. The main goal of MCR is to provide this familiar Docker Engine functionality, but specifically tailored for enterprise needs, along with commercial support (like 24×7 options) and enhanced security features, which might be necessary if your organization has stricter requirements than those that standard open-source Docker offers.

MCR heavily emphasizes security aspects often required by large organizations or regulated industries. For example, it uses FIPS 140-2 validated cryptography, has secure default configurations, and offers capabilities like enforcing the use of digitally signed images to secure the software supply chain.

It has broad capability as it supports both Linux and Windows containers. It can run in standalone mode, as part of a Kubernetes deployment, or in Docker Swarm clusters. This means you can use it in various infrastructure setups without demanding a complete overhaul of orchestration strategies.

Wrapping Up

Choosing the right container runtime is a critical decision that depends heavily on your team’s needs, your infrastructure, and the type of applications you’re building. While Docker has been the default choice for years, it’s clear that the container landscape in 2025 offers powerful alternatives such as Podman, LXC, containerd, CRI-O, and OpenShift, each with unique strengths.

If you manage large Kubernetes clusters, CRI-O or containerd might make sense. If you need a daemon-less solution with strong security principles, Podman is a compelling option. And if you operate in highly regulated enterprise environments, Mirantis Container Runtime brings Docker compatibility with hardened security features.

However, while choosing the right containerization platform is critical, managing your servers and deployments effectively is equally important – and that’s where RunCloud comes in.

RunCloud simplifies server management for developers and teams working with containerized or traditional PHP-based applications. Whether you’re using Docker, containerd, or another runtime under the hood, RunCloud helps you:

Deploy web applications faster
Set up automated backups
Manage server security with best practices baked in
Monitor performance from a unified dashboard
Scale projects effortlessly as your infrastructure grows

Instead of worrying about the underlying complexities of servers and deployments, you can focus entirely on building and shipping better software.

If you’re ready to streamline your application deployments and server management, no matter what container runtime you use, sign up for RunCloud today.

Thousands of developers and businesses already trust RunCloud to manage their mission-critical projects. Discover a simpler, faster, more scalable way to run your applications.

FAQs on Docker Alternatives for Containerization

Is Podman better than Docker?

Podman isn’t inherently ‘better’, but it offers advantages such as a daemonless architecture for enhanced security and rootless container execution. Docker has a more mature ecosystem and wider initial adoption, which makes it a strong choice for many workflows.

Do I need Kubernetes if I use Docker?

No, you don’t automatically need Kubernetes just for using Docker, as Docker excels at managing containers on a single host. Kubernetes becomes necessary to orchestrate, scale, and manage containerized applications across multiple hosts or clusters.

Is LXC faster than Docker?

LXC can exhibit slightly better performance in certain benchmarks due to operating at a lower level, closer to the kernel, often termed ‘system containers’. However, for typical application container workloads managed by Docker, the performance difference is usually negligible and less critical than Docker’s developer-focused tooling. The choice often depends on whether you must run full OS-like environments (LXC) or isolated applications (Docker).

What is the best containerization platform?

There is no single ‘best’ containerization platform; the ideal choice depends on your specific use case, team expertise, and requirements. Docker remains extremely popular for its ease of use and rich ecosystem, while Podman is favored for security-focused or daemonless environments.

What is the difference between Docker and Kubernetes?

Docker primarily focuses on building, shipping, and running individual containerized applications, often on a single machine. On the other hand, Kubernetes is a container orchestration platform designed to automate the deployment, scaling, and management of containerized applications across clusters of machines. Simply put, Docker creates the containers, and Kubernetes manages them at scale in production environments.

Are Docker alternatives suitable for high-traffic applications?

Docker alternatives like Podman, containerd, and CRI-O are suitable and commonly used for high-traffic, production-grade applications. The ability to handle high traffic effectively relies heavily on the orchestration layer (like Kubernetes) and the application architecture.

What is the difference between containerization and virtualization?

Virtualization creates virtual machines (VMs), each running a complete operating system instance with its own kernel on top of a hypervisor. Containerization packages an application and its dependencies, isolating them at the process level while sharing the host OS kernel. Therefore, containers are much lighter, faster to start, and consume fewer resources than VMs.

April 29, 2025

How to Identify and Kill Queries with MySQL Command-Line Tool
Is your application slow? Are users complaining about lag? This slowdown might be because your MySQL server is struggling under the weight of a long-running or problematic database query.

When your WordPress site or web application relies heavily on its database (and most do!), a single poorly performing query can have a massive impact.

Although many third-party tools are available to help with specific problems, in this article, we will use the built-in MySQL command-line tool, which offers a direct, powerful, and quick way to diagnose these issues.

We’ll guide you through using the command line to:
1. View currently running processes using SHOW PROCESSLIST.
2. Identify the specific slow query or problematic process ID.
3. Safely terminate (KILL) the query when required.
Let’s get started!

Prerequisites

Before you can manage MySQL queries, you’ll need to ensure that you have the necessary access and permissions on your server. You’ll need the following:
1. Shell access to your server
2. MySQL user account with specific privileges. For administrative tasks like this, it is common to use the MySQL root user as it has all the necessary privileges.
How to Kill MySQL Queries via Command Line

Step 1: Connecting to Your MySQL Server via Command Line

You can access the MySQL command-line interface via SSH once you’ve connected to your server. The most common way to connect locally is using the MySQL root user. Open your SSH terminal and execute the following command:
```
mysql -u root -p   
```
Let’s break this down:
- mysql: Invokes the MySQL command-line client program.
- -u root: Specifies that you want to log in as the MySQL user named root. Replace root if you are using a different administrative MySQL user.
- -p: Tells the client to prompt you for the password. It’s more secure than typing the password directly in the command line.
📖 Suggested read: How to Change/Reset MySQL Root Password on Ubuntu Linux?

After running this command, you’ll be prompted to enter a password. Paste or type the MySQL root password you retrieved from your RunCloud dashboard. You’ll be greeted with the MySQL monitor prompt (mysql>) if the credentials are correct.

Step 2: Viewing Running Processes in MySQL

Now that you’re connected to your MySQL server via the command line, you can run the SHOW PROCESSLIST command to get a snapshot of all the active connections (threads) to your database server and what they are doing at that precise moment. Simply type the following at the mysql> prompt and press ‘Enter’:
```
SHOW PROCESSLIST;
```
While this command is useful, it truncates the actual SQL query being executed in the ‘Info’ column. For more effective troubleshooting, especially when dealing with complex or long queries, it’s highly recommended to use the extended version:
```
SHOW FULL PROCESSLIST;
```
The FULL keyword allows you to see the complete SQL statement, which is necessary for diagnosis.

The output of either command presents a table with several columns, and understanding these columns is key to identifying problematic queries:
- Id: This is the unique identifier for the connection thread. You will need this number later if you decide to terminate a query or connection using the KILL command.
- User: Shows the MySQL username associated with the connection thread. This helps you trace the query back to a specific application user or system process.
- Host: Displays the hostname or IP address (and port) from which the connection originates. This is useful for identifying queries coming from specific application servers, cron jobs, or even unexpected locations.
- DB: This column indicates the thread’s current default database. If no database is selected, it will be NULL.
- Command: Describes the type of command the thread is currently executing. For example, the query command means that the thread is actively executing an SQL statement.
- Time: This is one of the most important columns for performance troubleshooting. It tells us the amount of time (in seconds) that the thread has spent in its current state. For ‘Query’ states, a high ‘Time’ value is a strong indicator of a long-running, potentially problematic query.
- State: This column provides more granular details about what the thread is doing within its current command. Some states are benign (starting, checking permissions), but others often point towards bottlenecks or issues:
  - System lock: The query is waiting to acquire a lock on a table or row currently held by another thread. This is a common cause of application hangs.
  - Sending data: The thread is processing and sending results back to the client. If this state persists for a long time, it might indicate a query returning a huge result set or network latency.
  - Writing to net: Similar to sending data, indicates network transfer activity.
- Info: This column displays the actual SQL statement being executed by the thread.
📖 Suggested read: SQLite vs MySQL vs PostgreSQL (Detailed Comparison)

If you are using RunCloud, you can use the Slow Script Monitoring functionality from your RunCloud dashboard to identify slow database operations over time. This method is ideal for less technical users as it doesn’t require connecting to your server via SSH or performing any other command-line operations.

An alternative method offers more flexibility for users comfortable with SQL.

MySQL provides the PROCESSLIST table within the information_schema database. You can query this table directly using standard SQL SELECT statements to create powerful filters.

For instance, to find all actively running queries (Query command) that have been executing for more than 60 seconds, and order them by the longest running first, you could use:
```
SELECT id, info FROM information_schema.PROCESSLIST
WHERE COMMAND = 'Query' AND TIME > 60
ORDER BY TIME DESC;
```
This approach can be very helpful on busy servers where the output of SHOW PROCESSLIST is overwhelming. You can pinpoint the threads causing performance degradation or blocking by carefully examining the process list output. Similarly, you can filter visually by ‘User’ or ‘Host’ if you suspect a particular application or job is causing trouble.

📖 Suggested read: How to Connect a MySQL Database to PHP (A Developer’s Guide)

Step 3: Analyzing the Query (Optional but Recommended)

Before killing a slow or seemingly stuck MySQL query, it’s important to investigate the underlying cause first to ensure it doesn’t happen again. You can begin by copying the complete query text from the ‘Info’ column associated with the problematic process.

Once you have this query text, the next critical step is understanding its execution plan. In a separate MySQL session, execute EXPLAIN <query_text>; to get an overview of your SQL command. Replace the <query_text> with the SQL statement you retrieved.

This EXPLAIN command provides insights into how MySQL intends to execute the query. This can reveal potential bottlenecks, such as full table scans, which would indicate potentially missing indexes on columns used in WHERE or JOIN clauses, inefficient join types, or an unexpectedly high number of rows being examined.

Fixing the underlying issue leads to long-term performance gains. For example, let’s assume optimizing a frequent query saves just 20% of its CPU time. That could mean your current server can handle significantly more traffic, or you might even be able to downsize to a smaller, cheaper AWS instance, which would directly save money while providing a faster experience for your users.

📖 Suggested read: MariaDB vs MySQL – A Detailed Comparison & How You Should Choose

Step 4: Killing the Query or Connection (KILL)

Once you’ve identified a suspicious query using the command described above, you can use the kill command to terminate the thread and manually restore server performance.

⚠️ Warning: Always double-check that you are using the correct process ID obtained from SHOW PROCESSLIST before executing any KILL command. Terminating the wrong process can lead to unexpected application errors or data inconsistencies.

KILL QUERY <process_id>;

This is generally the preferred first attempt. This command tries to terminate only the specific statement that the thread is currently executing, leaving the connection itself open. This is less disruptive to the connecting application.

For example, if process ID 12345 is running a slow query, you would run:
```
KILL QUERY 12345;
```
Remember that KILL QUERY might not take effect instantly if the thread is performing an operation that cannot be safely interrupted (like writing to disk). In such cases, it will wait until the thread reaches a point where it can be safely terminated.

KILL CONNECTION <process_id>;

If the KILL QUERY command doesn’t work or if you need to terminate the entire connection associated with the thread, you can forcefully terminate the connection. This terminates the statement and drops the client connection.
```
KILL CONNECTION 12345;
```
In the following example, we can see that the database forcefully terminated the connection from the client. Therefore, you should always use this command with caution as it can lead to unexpected errors.

Step 5: Verifying the Kill

After issuing a KILL QUERY or KILL CONNECTION command, you must confirm that it worked.

The most straightforward way to do this is to run SHOW PROCESSLIST; again immediately. If the kill was successful, the process ID you targeted should no longer be in the list.

Occasionally, you might see the thread you attempted to kill still listed, but with ‘Killed’ appearing in the Command column. This usually means MySQL has registered the kill request but hasn’t terminated the thread yet. This can happen if the thread is engaged in an operation that cannot be interrupted instantly, such as waiting for disk I/O or performing cleanup tasks.

The thread will disappear shortly after showing the ‘Killed’ state. However, if you used KILL QUERY and the thread persists, it might indicate the query itself is resistant to termination in its current state. In such scenarios, you can use the more forceful KILL CONNECTION command to terminate the connection and release its resources.

Important Considerations and Best Practices for Killing MySQL Queries

While the MySQL command-line tool provides a direct way to manage running queries, using the KILL command should always be done thoughtfully and with an understanding of the potential repercussions.
- Kill with Caution: Terminating queries, especially KILL CONNECTION, isn’t always clean. Be aware of the potential consequences:
  - Transaction Rollbacks: If you kill a thread executing Data Manipulation Language (DML) statements like INSERT, UPDATE, or DELETE within a transaction (particularly with InnoDB), the entire transaction will typically be rolled back to ensure data consistency. This might be desirable, but it’s important to understand it will happen.
  - Application Errors: Applications are often not designed to handle unexpected database connection drops. Killing a connection might result in application-level errors, incomplete operations, or confusing states for end-users.
  - Resource Cleanup: While modern storage engines such as InnoDB are good at cleaning up, forcefully killing threads can sometimes, albeit rarely, leave behind temporary tables or orphaned locks that might require manual cleanup later.
- Don’t Kill System Threads: Exercise extreme caution when viewing the process list. You might see threads run by internal system users (e.g., system user, event_scheduler) or replication users (often named repl or similar). Avoid killing these threads unless you have a deep understanding of MySQL internals and are sure it’s necessary and safe, as doing so can disrupt essential background processes, break replication, or even lead to server instability.
- Focus on Root Cause Analysis: Killing a query is almost always a temporary band-aid, not a permanent solution. The most important step after resolving an immediate performance crisis is to investigate why the query was slow or problematic in the first place. Was it due to missing indexes? Poorly written SQL? Inefficient application logic? A bad schema design? It is always recommended that the application code be analyzed to identify and fix the underlying issue. Otherwise, the problem is likely to recur.
- Proactive Prevention with max_execution_time: You can consider setting the max_execution_time system variable. This allows you to define a timeout (in milliseconds). The server will automatically abort queries exceeding this time limit, preventing runaway read queries from consuming excessive resources.
Final Thoughts

Identifying and killing problematic queries manually using MySQL’s command-line tool is an essential skill for any serious developer or server administrator. Knowing how to spot performance bottlenecks quickly can save your application from crashes, downtime, and user frustration.

But even with the right techniques, managing servers directly through the terminal takes time, demands technical expertise, and leaves too much room for human error.

That’s where RunCloud can transform your workflow.

RunCloud provides a simple, powerful platform that handles the heavy lifting of server management for you. Instead of spending hours troubleshooting MySQL issues through command-line sessions, you can:
- Monitor server performance and database health visually through an intuitive dashboard
- Use built-in Slow Script Monitoring to proactively catch issues before they affect users
- Automate backups, deployments, and SSH alerts – all without touching the command line
- Easily manage MySQL databases, users, and permissions without memorizing commands
Thousands of developers and businesses already trust RunCloud to manage their mission-critical servers – and for good reason. It saves time, reduces stress, and gives you peace of mind that your applications are running at their best.

Ready to experience better server management? Sign up for RunCloud today.

Stop putting out fires. Start focusing on building, growing, and delivering better results – with RunCloud by your side.

Frequently Asked Questions About Managing MySQL Queries

Managing a MySQL server often raises important questions, especially when diagnosing slow queries or optimizing database performance. Below, we answer the most common questions developers and administrators ask about viewing, analyzing, and safely killing MySQL queries.

How can I list only queries that are running longer than a certain time in MySQL?

You can filter the information_schema.PROCESSLIST table directly. For example: SELECT id, user, time, info FROM information_schema.PROCESSLIST WHERE command = 'Query' AND time > 60; This shows queries that have been active for more than 60 seconds, making it easier to detect slow or stuck queries.

Is it better to kill a query manually or let MySQL’s timeout settings handle it?

In emergencies, manually killing a slow query is faster. However, using server settings like max_execution_time provides automatic safeguards to prevent long-running queries from becoming a recurring problem without human intervention.

How often should I monitor running MySQL queries?

In production environments, continuous automated monitoring is ideal. RunCloud’s Slow Script Monitoring can alert you to persistent slow queries without constant manual checks. Manual investigation should be triggered whenever performance drops or after major deployment changes.

Can killing queries help fix “Too many connections” MySQL errors?

Yes, selectively killing idle or stuck queries can immediately free up connections. However, this is a temporary fix. For long-term stability, you should also optimize your database configuration and connection pooling.

Will killing a query cause data loss or corruption?

Killing a query mid-execution won’t typically cause corruption if you use transactional storage engines like InnoDB. However, it may cause the current transaction to roll back, potentially undoing changes made during that session. Always investigate and resolve the underlying issue afterward.

What’s the safest way to kill a problematic query?

Use KILL QUERY <process_id>; first, as it only attempts to stop the active SQL statement without closing the entire database connection. If that fails or the thread is unresponsive, escalate to KILL CONNECTION <process_id>; to terminate the session.

How can I prevent long-running queries in the future?

Analyze your slow queries using EXPLAIN plans and optimize indexing, query structure, or application code. Additionally, set reasonable limits like max_execution_time and actively monitor performance metrics using tools such as RunCloud’s dashboard.

Ready to simplify server management and focus on what matters most? Sign up for RunCloud and see why thousands of developers and businesses trust it for fast, secure, and reliable server operations.
April 21, 2025
How to Build a CI/CD Pipeline with GitHub Actions and Docker
Are you tired of manually building, testing, and deploying your applications?

Modern Continuous Integration (CI) and Continuous Deployment (CD) approaches can automatically trigger a deployment pipeline to build your Docker image, run tests, push it to a container registry like GHCR or Docker Hub, and deploy it to your server.

The best part is that you can complete all of this in less than a minute after pushing code to your GitHub repository.

By combining Docker with the automation capabilities of GitHub Actions, you can create a fast and effective DevOps pipeline. Docker ensures your application runs the same way everywhere by packaging it with its dependencies in a portable Docker container based on instructions in your Dockerfile. GitHub Actions then automates the build and push steps, securely manages secrets like access tokens, and handles the final deployment to your infrastructure.

In this guide, we’ll walk you through configuring your GitHub Actions workflow step-by-step, from publishing a container to deploying it on your server without third-party tools or subscriptions.

By the end of this tutorial, you will be able to configure a deployment pipeline that updates your live server in under a minute after you push changes to it.

Let’s get started!

What are GitHub Actions?

GitHub Actions is a powerful automation tool built directly into the GitHub platform. It listens for specific events happening in your repository, like someone pushing new code, creating a pull request, or even on a set schedule, and then automatically performs tasks you’ve defined. These tasks form a workflow, which is essentially a sequence of steps designed to achieve a specific goal. You can use this functionality to create a Continuous Integration (CI) and Continuous Deployment (CD) pipeline.

This means you can automate the entire process of building your software, running tests to ensure quality, and even deploying it to servers (perhaps managed through tools such as RunCloud) without manual intervention.

Key Features of GitHub Actions

GitHub Actions has several useful features that make it a compelling choice for automation. Firstly, its event-driven nature allows workflows to trigger automatically in response to a wide variety of GitHub events. Secondly, matrix builds let you efficiently test your code across different environments simultaneously; you can define combinations of operating systems (like Linux, macOS, and Windows), software versions (like different Node.js or Python versions), or other variables, and GitHub Actions will run a job for each combination.

Furthermore, GitHub provides hosted runners, which are virtual machines managed by GitHub that can execute your workflow jobs without requiring you to manage any infrastructure. If you have very specific needs, then you can also consider using self-hosted runners on your own servers or cloud infrastructure.

All the actions and workflows on GitHub can be reused. You can even configure pre-built steps created by the community (available in the GitHub Marketplace) and save significant development time. Lastly, GitHub Actions includes integrated secrets management for securely handling sensitive information like API keys and passwords. It provides live logs for monitoring workflow progress in real time and the ability to store artifacts like build outputs or test reports.

📖 Suggested read: What is Docker And How Does it Work

Steps to Deploy Docker Container with GitHub Actions for CI/CD

Let’s walk through the steps to automate building your application’s Docker image, pushing it to a registry, and then deploying it to your server every time you push changes to your repository.

Prerequisites:
- GitHub Repository: You need a GitHub repository containing all your application code. Make sure you have committed and pushed your latest code changes to GitHub.
- Dockerfile: You must have a Dockerfile in the root of your repository. This file contains the step-by-step instructions Docker uses to build an image of your application. The specific commands inside the Dockerfile depend heavily on your application’s language, framework, and dependencies (e.g., installing packages, copying code, setting entry points), so we assume you have already created a functional Dockerfile.
Step 1: Connect to Linux Server via SSH

First, ensure you can connect to the target Linux server where your Docker container will run. You’ll need SSH access for this.
```
ssh your_server_user@your_server_ip
```
In the above command, replace your_server_user with your username and your_server_ip with the server’s IP address. If you manage your server with RunCloud, you can use the simplified SSH key management to store SSH keys. We recommend reading the RunCloud documentation to learn how to easily create and manage SSH keys for secure server access.

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

Step 2: Verify Docker Installation on the Server

Once connected to your server via SSH, you need to confirm that Docker is installed and running correctly. The Docker Command Line Interface (CLI) is required to pull images and run containers. You can test this by running the standard Docker test image:
```
docker run hello-world
```
If Docker is installed and working, you will see a message starting with “Hello from Docker!”. This message indicates that your installation appears to be working correctly.

If the command fails or Docker is not found, you must install Docker Engine on your Linux server before proceeding. Follow the official Docker installation documentation specific to your server’s Linux distribution (e.g., Ubuntu, RHEL).

📖 Suggested read: How To Create a Docker Image For Your Application

Step 3: Add GitHub Action Secrets for SSH Access

To allow your GitHub Actions workflow to securely log in to your server and execute deployment commands, you must store your server’s connection details as encrypted secrets in your GitHub repository. You should never hardcode sensitive information directly into your workflow file – we recommend using GitHub’s built-in secret management system for this.

Navigate to your GitHub repository > Settings > Secrets and variables > Actions. Click “New repository secret” for each of the following:
1. SERVER_IP: The public IP address of your Linux server.
2. SERVER_PORT: The SSH port for your server (usually 22, but might be different if customized).
3. SERVER_USER: The username you use to log in to your server via SSH. We strongly recommend creating a new user account specifically for this deployment step and giving it appropriate permissions for better security.
4. SERVER_PRIVATE_SSH_KEY: The entire content of the private SSH key file that corresponds to a public key authorized on your server. Your private SSH key should look something like this:
```
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
...
UV7ErwUhELMZFrAAAAE3RhdHRpY29kZXJAc3Rhcmx1c3QBAgMEBQYH
-----END OPENSSH PRIVATE KEY-----
```
Using secrets prevents exposing your server credentials in your codebase. The workflow will reference these secrets securely during execution. We strongly recommend creating a dedicated SSH key pair specifically for automation.

Again, consulting the RunCloud documentation can be very helpful in generating and managing SSH keys securely, especially regarding best practices for SSH security.

📖 Suggested read: Understanding Docker Services | RunCloud Docs

Step 4: Configure GitHub Actions Workflow

Now, define the CI/CD pipeline using a GitHub Actions workflow file. This file tells GitHub what steps to perform when triggered (e.g., on a push to your main branch).

Create a YAML file named docker-publish.yml inside your repository’s .github/workflows/ directory. You can create this directory and file directly via the GitHub web interface or in your local repository using a text editor, and then commit and push the changes.

Paste the following code into .github/workflows/docker-publish.yml:
```
name: Publish & Deploy Docker container

# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.


on:
  push:
    # Adjust branch name if needed (e.g., master, production)
    branches: [ "main" ]
    # Publish semver tags as releases.
    tags: [ 'v*.*.*' ]
env:
  # Use docker.io for Docker Hub if empty
  REGISTRY: ghcr.io
  # github.repository as <account>/<repo>
  IMAGE_NAME: ${{ github.repository }}
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      # This is used to complete the identity challenge
      # with sigstore/fulcio when running outside of PRs.
      id-token: write


    steps:
      - name: Checkout repository
        uses: actions/checkout@v4


      # Install the cosign tool except on PR
      # https://github.com/sigstore/cosign-installer
      - name: Install cosign
        if: github.event_name != 'pull_request'
        uses: sigstore/cosign-installer@59acb6260d9c0ba8f4a2f9d9b48431a222b68e20 #v3.5.0
        with:
          cosign-release: 'v2.2.4'


      # Set up BuildKit Docker container builder to be able to build
      # multi-platform images and export cache
      # https://github.com/docker/setup-buildx-action
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@f95db51fddba0c2d1ec667646a06c2ce06100226 # v3.0.0


      # Login against a Docker registry except on PR
      # https://github.com/docker/login-action
      - name: Log into registry ${{ env.REGISTRY }}
        if: github.event_name != 'pull_request'
        uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d # v3.0.0
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}


      # Extract metadata (tags, labels) for Docker
      # https://github.com/docker/metadata-action
      - name: Extract Docker metadata
        id: meta
        uses: docker/metadata-action@96383f45573cb7f253c731d3b3ab81c87ef81934 # v5.0.0
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}


      # Build and push Docker image with Buildx (don't push on PR)
      # https://github.com/docker/build-push-action
      - name: Build and push Docker image
        id: build-and-push
        uses: docker/build-push-action@0565240e2d4ab88bba5387d719585280857ece09 # v5.0.0
        with:
          context: .
          push: ${{ github.event_name != 'pull_request' }}
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max


      # Sign the resulting Docker image digest except on PRs.
      # This will only write to the public Rekor transparency log when the Docker
      # repository is public to avoid leaking data.  If you would like to publish
      # transparency data even for private images, pass --force to cosign below.
      # https://github.com/sigstore/cosign
      - name: Sign the published Docker image
        if: ${{ github.event_name != 'pull_request' }}
        env:
          # https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-an-intermediate-environment-variable
          TAGS: ${{ steps.meta.outputs.tags }}
          DIGEST: ${{ steps.build-and-push.outputs.digest }}
        # This step uses the identity token to provision an ephemeral certificate
        # against the sigstore community Fulcio instance.
        run: echo "${TAGS}" | xargs -I {} cosign sign --yes {}@${DIGEST}


  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: SSH and Deploy to Server
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_IP }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SERVER_PRIVATE_SSH_KEY }}
          port: ${{ secrets.SERVER_PORT }}
          script: |
            echo ${{ secrets.GITHUB_TOKEN }} | docker login ${{ env.REGISTRY }} -u ${{ github.actor }} --password-stdin
            echo "--- Pulling latest Docker image ---"
            docker pull ghcr.io/tatticoder/terraform-get-time:main
            echo "--- Stopping existing container (if running) ---"
            docker stop my_container 
            echo "--- Removing existing container ---"
            docker rm my_container 
            echo "--- Starting new container ---"
           # Adjust ports (-p host:container) 
           # Add any necessary environment variables (-e)
            docker run -d --name my_container -p 3000:80 ghcr.io/tatticoder/terraform-get-time:main
```
Let’s understand the important sections of the above code snippet:
- name: Sets the display name for your workflow in the GitHub Actions tab.
- on: push: branches: [ main ]: This triggers the workflow every time code is pushed to the main branch. You can change main to your default or production branch name (e.g., master).
- Build Job: This section handles the process of creating and publishing the Docker container.
  - Checkout code: Uses the standard actions/checkout action to get your repository code onto the runner.
  - Log in to GHCR: Uses docker/login-action to authenticate with GitHub Container Registry using the automatically generated GITHUB_TOKEN.
  - Build and push: Uses docker/build-push-action.
    
    context: .: Tells Docker to use the repository root as the build context (where the Dockerfile is) and publish the resulting container to GHCR.
- Deploy via SSH Job: This job uses the popular SSH Remote Commands action to connect to your server using the secrets you configured and execute commands.
  - host, username, key, port: These fields use the secrets you created in Step 3.
  - script: This block contains the shell commands which will be executed on your target server.
    
    ❗Very Important – please read the following points very carefully:
    
    The first command logs into GHCR on the server. Pulling public GHCR images might not require login. For private images, you can just use the provided command without any modifications.
    
    The subsequent command pulls the latest tagged image from GHCR. Make sure to edit this command and replace ghcr.io/tatticoder/terraform-get-time:main with the name of your container image and its corresponding tag.
    
    The subsequent command stops and removes any container with the name ‘my_container’ to avoid conflicts. Make sure to temporarily remove these commands to prevent the workflow from failing if the container doesn’t exist yet.
    
    The final command runs a new container in detached mode (-d) using the pulled image. Make sure to replace the image’s name with the one you want to use and configure any additional parameters as per your requirements.
⚠️ Warning: The deployment script uses docker stop and docker rm before docker run. This means there will be a brief moment of downtime while the container is replaced. For zero-downtime deployments, more advanced strategies like blue-green deployments or using orchestration tools like Kubernetes are needed, which are beyond this basic setup.

To minimize the impact of downtime, you can consider deploying once a day on weekdays outside of peak hours. This schedule can be configured easily using the GitHub action itself.

📖 Suggested read: Docker Security: Best Practices to Secure a Docker Container

Step 5: Commit Workflow and Trigger Deployment

Finally, save the docker-publish.yml file. If you created it locally, commit it and push it to your GitHub repository using the following commands:
```
git add .github/workflows/docker-publish.yml
git commit -m "Add GitHub Actions workflow for Docker build and deploy"
git push 
```
Once you push this commit (or any future code changes) to the specified branch (main in this example), GitHub Actions will automatically detect the workflow file and start executing the defined steps.

You can monitor the progress by going to the “Actions” tab in your GitHub repository. If all steps succeed, your code will be built into a Docker image, pushed to GHCR, and then pulled and run as a container on your designated Linux server.

Once you have published your Dockerfile to GHCR, you will see a new tab in the bottom right of your GitHub dashboard. You can click on the name of your package to view your recently published packages.

Step 6: Remove Unused Docker Resources (Optional)

When you use a CI/CD pipeline, you will quickly end up with a large number of old obsolete containers on your server. These containers are often not needed and can slowly fill your disk space. If you are running low on disk space, then you can add an optional cleanup step to your deployment script to prevent your server’s disk space from filling up with old, unused Docker images, containers, and ‘build cache’.

The following command will automatically remove any Docker resources (like stopped containers and images not associated with a running container) that haven’t been used in the last 24 hours without requiring confirmation. Running this periodically helps maintain server health and efficiently reclaim storage:
```
docker system prune --filter "until=24h" --force
```
If your deployment process takes a long time, consider optimizing the build stage of your container by using a caching layer within Docker to cache dependencies.

Wrapping Up: Who Should Use Docker with GitHub Actions for CI/CD?

Whether you’re a solo developer or part of a large team, automating builds and deployments saves invaluable time and reduces the potential for human error inherent in manual processes.

While GitHub Actions handles the automation of building your Docker images and triggering deployment scripts, manually configuring, securing, monitoring, and updating servers can be complex and time-consuming.

RunCloud provides a clean, efficient way to manage servers without the usual hassle. From provisioning and security hardening to database setup and app deployment, it streamlines the tasks that slow developers down. You stay in control of your infrastructure, but without getting buried in configuration files or command-line firefighting.

That means more time building, testing, and shipping better software.

Ready to take the work out of server management? Start with RunCloud today.

FAQs on Docker with GitHub Actions for CI/CD

What are the advantages of using Docker for CI/CD?

Docker ensures consistent environments from development through production. It provides process isolation and ensures that builds and tests don’t interfere with each other or the host system dependencies.

How do I secure my Docker images in GitHub Actions?

Start by scanning your images for vulnerabilities using container scanning tools directly within your GitHub Actions workflow. To reduce the attack surface, use minimal, trusted base images and avoid installing unnecessary packages. Always configure containers to run as non-root users and manage secrets securely using GitHub Secrets, never embedding them in the image layers.

Can I use Docker Compose with GitHub Actions?

Yes, Docker Compose can be effectively used within GitHub Actions workflows to manage multi-container setups. You simply need to ensure Docker Compose is installed on the runner, then use standard docker-compose commands to build images or spin up services like databases for integration testing.

What is the best way to manage secrets in GitHub Actions?

The most secure and recommended method is using GitHub Actions encrypted secrets, which are configured at the repository or organization level. These secrets can then be safely accessed within your workflow as environment variables or passed to specific actions needing credentials. Never hardcode sensitive information directly in your workflow files or application code checked into version control.

Is Docker necessary for CI/CD?

While not strictly mandatory, Docker offers substantial benefits that make it a highly popular choice for modern CI/CD pipelines. While alternative options are available, Docker provides reproducible and isolated build/test environments that are useful for reliable continuous integration and delivery.

How does Docker improve CI/CD pipelines?

Docker drastically improves CI/CD pipelines by guaranteeing environment consistency across all stages, from developer laptops to production servers. Its containerization isolates dependencies, preventing conflicts and simplifying the configuration of build agents.

Can I use self-hosted runners with Docker in GitHub Actions?

You can absolutely use self-hosted runners with Docker in GitHub Actions. This approach gives you complete control over the build environment and resources.

What is the difference between Docker and Kubernetes for CI/CD?

Docker is primarily used within the CI/CD pipeline to build application images, run tests in isolated containerized environments, and consistently package dependencies. Kubernetes is a container orchestrator typically acting as the deployment target after the CI pipeline, responsible for managing the runtime, scaling, and health of containers in a cluster. Docker creates the portable application packages used in CI, while Kubernetes manages fleets of those packages in production or staging environments (CD).
April 11, 2025
How to Deploy Laravel with Docker on VPS in 2025 (Comprehensive Guide)
Deploying your Laravel application with Docker on a VPS might seem daunting at first – especially when you’re juggling server configurations, dependency management, and ensuring your app runs seamlessly in production. Even after building a well-optimized web application, replicating your local environment on a server can be a whole new challenge.

In this comprehensive guide, we’ll show you how to deploy Laravel with Docker on a VPS using Laravel Sail.

Sail simplifies the process by handling the Docker setup for you, making it a great option whether you’re new to Docker or looking for a streamlined approach.

You’ll learn how to download Laravel, spin up essential services such as the web server, PHP, and database, and run the necessary setup commands to get your application live.

Let’s dive in!

Why Use Docker for Laravel Deployment?

Deploying a Laravel application from your local development setup to a live production server is not easy. If you have deployed applications in the past, you’ll probably agree that the deployment process introduces numerous complexities, and it’s challenging to manage environment consistency.

Traditionally, server setup involved manually installing and configuring PHP, web servers such as NGINX or Apache, databases, caching services such as Redis or Memcached, and countless system libraries – all directly onto the server’s operating system.

This process is not only time-consuming but also prone to errors and inconsistencies. Subtle differences between development, staging, and production environments cause unexpected bugs and failures during application deployment.

Docker fundamentally solves this by enabling you to package your entire application into standardized, isolated units called Docker containers, including its specific dependencies and configurations.

Advantages of Dockerizing Laravel Applications

The primary advantage of containerizing your Laravel applications with Docker is that it allows you to have a consistent development and deployment experience for all developers. By packaging your application code along with the exact versions of PHP, extensions, web server (NGINX/Apache), system libraries, and other dependencies within a Docker image, you eliminate variations between developer machines, testing environments, and production servers.

This portability means a container built on one machine will run identically on any other machine with Docker installed, drastically reducing bugs related to environment differences.

In addition, Dockerization brings significant benefits in terms of isolation, scalability, and resource efficiency for Laravel projects. Each Docker container runs in its own isolated userspace, preventing conflicts between different applications or microservices running on the same host. It also enhances security by limiting the potential blast radius of vulnerabilities.

This isolation makes it easier to scale specific components of your application (e.g., PHP-FPM workers, queue workers) independently based on demand, often orchestrated via Docker Compose or more advanced container management tools such as Kubernetes.

Compared to traditional virtual machines, containers have significantly lower overhead as they share the host OS kernel. This leads to faster startup times, better resource utilization, and the ability to run more application instances on the same hardware, ultimately improving overall reliability and cost-effectiveness.

📖 Suggested read: What is Docker And How Does it Work

Step-by-Step Instructions For Deploying Your First Laravel App with Docker (Sail)

This section explains how to deploy your Laravel application on a generic cloud VPS using Docker.

If you are using RunCloud to manage your servers, then you can refer to our Laravel documentation to learn how to do this effectively.

Prerequisites

Before we begin installing Laravel, ensure your server environment is correctly prepared.
1. Server Access: You’ll need access to a Linux server (such as a VPS from providers such as DigitalOcean, Linode, Vultr, etc.) via SSH.
1. Sudo Privileges: You must be logged in as a user with sudo privileges or as the root user directly (though using a sudo user is generally recommended for security). Remember, commands run with sudo have elevated permissions, so execute them carefully.
2. Docker Installation and Service: Docker must be installed and running on your server. You can check if it is installed by running docker –version. If it’s not found, you’ll need to install it following the official Docker documentation for your Linux distribution.
Note: Many cloud providers offer server images with Docker pre-installed. Using one of these can save you the installation step.

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

Step 1: Download Your Laravel Application

We will use the official Laravel.build service to download a starter Laravel project configured for Sail. The command below downloads a script and executes it using bash.

Run this command, making sure you replace runcloud-laravel-app with the desired name for your application’s directory. This name will be used for the project folder.
```
curl -s https://laravel.build/runcloud-tutorial | sudo bash
```
Important Security Precaution: Piping (|) commands directly from curl to sudo bash executes the downloaded script with root privileges. While laravel.build is an official and trusted source, be cautious when running scripts from the internet this way. Read our blog post on Pipes vs Xargs to learn more on this topic.

📖 Suggested read: How To Create a Docker Image For Your Application

In the above command:
- curl -s: Downloads the script silently (no progress meter).
- https://laravel.build/runcloud-tutorial: This tells the service to generate a setup script for an app named runcloud-tutorial.
- | sudo bash: Pipes the downloaded script directly to the bash interpreter, executed with sudo (root) privileges. This creates the project directory and sets initial permissions.
Step 2: Navigate into Your Application Directory

Once the previous command completes, navigate into the newly created project directory. Remember to use the actual application name you chose:
```
cd runcloud-tutorial
```
You should now be inside your Laravel project’s root directory.

📖 Suggested read: Understanding Docker Services | RunCloud Docs

Step 3: Start the Docker Containers with Laravel Sail

Laravel Sail is an interface for managing your application’s Docker containers. We’ll use it to build and start the necessary services (web server, PHP, database, etc.).

Execute the following command to start Sail in “detached” mode (-d), meaning the containers will run in the background:
```
sudo ./vendor/bin/sail up -d
```
In the above command:
- sudo: We use sudo here because Sail needs root permissions to manage Docker networking and volumes.
- ./vendor/bin/sail: Executes the Sail script located in your project’s vendor directory.
- up: This command tells Docker (via Sail and Docker Compose) to create and start the containers defined in the docker-compose.yml file. The first time you run this, it will download the necessary Docker images (such as PHP, NGINX, MySQL), which can take several minutes (sometimes ten or more), depending on your internet connection.
- -d: Runs the containers in the background so your terminal prompt remains available.
📖 Suggested read: Docker Security: Best Practices to Secure a Docker Container

Step 5: Run Database Migrations

Once the containers (including the database container) are running, you’ll need to set up your application’s database schema. Laravel uses “migrations” for this.

Run the following command to execute the default Laravel migrations:
```
sudo ./vendor/bin/sail artisan migrate
```
In the above command:
- sudo ./vendor/bin/sail: Again, we use Sail to execute a command.
- artisan migrate: This tells Sail to run the PHP artisan migrate command inside the main application container (the one running PHP). This command creates the necessary tables in the database (like the users table, etc.).
You should see an output indicating that the migrations ran successfully.

Step 6: Access Your Application

Your Laravel application should now be running and accessible!
- On a Server: Open your web browser and navigate to your server’s public IP address: http://your_server_ip. Sail, by default, configures the web server container to listen on port 80.
- On Your Local Machine (if developing locally): If you performed these steps on your local computer instead of a server, you can usually access it via http://localhost.
If you cannot access the site via the server’s IP address, your server’s firewall might be blocking incoming connections on port 80 (HTTP). You will need to configure your firewall (e.g., ufw, firewalld, or your cloud provider’s firewall settings) to allow traffic on TCP port 80.

📖 Suggested read: How to Use Cloudflare Firewall Rules to Protect Your Web Application

Step 7: Troubleshooting Potential Permission Errors (If Needed)

Sometimes you might encounter file permission errors within your Laravel application, due to how Docker handles file volumes and user mapping between the host server and the container. This often happens because the web server process inside the container (running as the sail user) doesn’t have write permission to files owned by the root user on the host (created during the initial curl | sudo bash step).

If you suspect permission issues, you can fix them by changing the ownership of the project files inside the container to the sail user.

Enter the main application container as root:
```
sudo ./vendor/bin/sail root-shell
```
This gives you a root command prompt inside your Laravel application’s container.

Change ownership recursively: This command changes the owner and group of the html directory (as well as everything inside it) to sail:
```
chown -R sail:sail /var/www/html
```
Let’s understand each part of the above command.
- chown: Change owner command.
- -R: Recursive (apply to the directory and all files/directories within it).
- sail:sail: Set the user to sail and the group to sail.
- html: The target directory (which corresponds to your project root, mounted at /var/www/html).
Close the container shell:
```
exit
```
After running these commands, try accessing your application again, and refresh the web page.

Wrapping Up: Deploying Laravel with Docker on a VPS

While Sail simplifies the Docker aspect for a single Laravel project, managing the underlying server, handling security configurations, setting up monitoring, deploying multiple applications, and keeping everything updated still requires significant effort and Linux expertise. This is where platforms specifically designed for server management truly shine.

RunCloud makes it incredibly easy to develop, deploy, and maintain your web applications across one or many servers, all from a single, intuitive central dashboard.

It abstracts away the complexities of server administration, letting you focus on building great applications.

RunCloud works with standard Laravel applications, high-performance setups such as Laravel Octane, and popular CMS platforms such as WordPress. You can start using RunCloud and choose from various optimized server stacks directly through the RunCloud interface.

Ready to experience truly effortless server management and application deployment?

Sign up for RunCloud today and see the difference for yourself!

FAQs on Deploying Laravel with Docker on a VPS

What are the benefits of using Docker for Laravel deployment?

Docker packages your Laravel app and its dependencies into containers, ensuring consistent environments from development to production. This isolation prevents conflicts between application dependencies and simplifies portability across different servers or cloud providers.

How do I secure my Dockerized Laravel application?

You can secure your Dockerized Laravel app by following standard web security practices within your code, using minimal, trusted base images, and running containers as non-root users. RunCloud provides several security features out of the box and simplifies configuration management.

Can I use Docker Compose with Laravel?

Absolutely, Docker Compose is highly recommended, especially for local development and simpler multi-container production setups with Laravel. It allows you to define and manage all the related services your application needs (such as the web server, PHP-FPM, database, and cache) in a single YAML file. This makes it easy to spin up, connect, and manage the entire application stack with simple commands.

What is the best way to manage environment variables in Docker?

For security reasons, avoid hardcoding environment variables or committing .env files directly into your Docker image. Instead, pass environment variables into the container at runtime using Docker’s -e flag, Docker Compose environment, or env_file directives.

Is Docker necessary for deploying Laravel?

No, Docker isn’t strictly necessary; you can successfully deploy Laravel using a traditional approach by setting up a LAMP or LEMP stack directly on your VPS. However, Docker provides significant advantages in environment consistency, dependency management, and deployment predictability. Tools such as RunCloud make both traditional and Docker-based deployments significantly easier to manage.

What are the alternatives to Docker for deploying Laravel?

You can deploy your web applications using the traditional deployment directly onto a configured VPS. RunCloud makes this process extremely easy by providing a centralized dashboard for VPS management.

Can I use Kubernetes to manage Laravel deployments?

Yes, Kubernetes (K8s) is a powerful container orchestration system suitable for managing complex, large-scale Laravel applications requiring high availability, auto-scaling, and rolling updates. However, it introduces significant operational complexity compared to simpler Docker or Docker Compose setups. Managing deployments via a tool such as RunCloud provides sufficient capability for many projects without the K8s learning curve.

What is the difference between Docker and traditional VPS deployment?

Traditional VPS deployment required you to install and manage all software (OS, web server, PHP, database, dependencies) directly on the virtual server, sharing the host OS kernel and resources in a less isolated way. Docker uses containerization to package the application and its dependencies into isolated user-space environments that run consistently anywhere, sharing the host OS kernel but keeping libraries and binaries separate.
April 10, 2025
Self-Hosting Docker vs Cloud-Based Docker: Pros and Cons

Do you ever feel like getting your software to run reliably everywhere is almost as challenging as writing it in the first place? If so, then we strongly recommend learning all about Docker containerization.

Docker containerization is a technology that packages applications into neat, portable containers that can be run anywhere.

But once you’ve created containers, the next big question is – where they should live? Do you take command of your own hardware in a self-hosted setup, or leverage the vast power and convenience of the cloud?

This guide will also help you choose between self-hosting Docker and using cloud platforms.

Let’s get started!

What is Docker?

You know that classic developer joke, “But it works on my machine!” – funny because it’s often painfully true. Getting software to run correctly on different computers, with all their various settings and installed programs, has often been a massive headache. Docker is a way to fix this.

Docker is like a standardized shipping container, but for software. You package your application and everything it needs to run (like specific code libraries, tools, and settings) into a neat little box called a “container”. This container can run practically anywhere, on your laptop, a colleague’s computer, or a server in a data center, and it should always work exactly the same way.

Docker essentially isolates your application, so it doesn’t care what else is running on the host computer. It brings its own environment with it. This makes developing and deploying applications much faster and more reliable.

But it’s important to remember that Docker isn’t the only container runtime out there! Other great technologies, such as Podman and Containerd, do similar things, offering different features or approaches that some people prefer. So, while you’ll hear “Docker” a lot, think of it as the famous brand name for a type of technology (containers) with several players.

📖 Suggested read: What is Docker And How Does it Work

What is Self-Hosting Docker?

It means you take responsibility for running these containers on the hardware you manage. Instead of paying a cloud company such as AWS or Google Cloud to run your applications, you set up your own server (which could be an old PC in your closet, a powerful machine you bought specifically for this, or even a tiny Raspberry Pi) and use Docker (or one of its alternatives) to run the software containers on it.

You can think of it as choosing between renting an apartment (using a cloud provider) and owning your own house (self-hosting). When you self-host Docker applications, you set up the server, install the base operating system, install Docker itself, and then deploy and manage the application containers on that system.

This could be for running anything from a personal blog, a media server like Plex, a file-syncing service, a password manager, or even more complex business applications. You’re the landlord, the maintenance crew, and the resident all rolled into one.

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

What Are The Benefits of Self-Hosting Docker?

Why would anyone go through the trouble of setting up their own server to run Docker containers? Well, there are some pretty compelling reasons. The biggest one is often control.

When you self-host, you have complete control over your data and how the application is configured. Your data stays on your hardware, which can be a huge plus for privacy-conscious folks. You’re not subject to a cloud provider’s terms of service changes, price hikes, or potential service shutdowns.

Another major benefit can be cost savings, especially in the long run. While there’s an upfront cost for hardware, you avoid potentially hefty monthly subscription fees for cloud services, especially if you need to run many applications or require significant resources.

It’s also an incredible learning opportunity. Setting up and managing your own server and Docker environment teaches you a ton about Linux, networking, security, and how applications really work under the hood, which are valuable skills in today’s tech world. Plus, you get the satisfaction of building and managing your own little corner of the internet.

📖 Suggested read: How To Create a Docker Image For Your Application

What Are The Drawbacks of Self-Hosting Docker?

As you might have guessed already, self-hosting Docker isn’t easy, and it comes with its own set of chores. The biggest drawback of self-hosting is responsibility. You are solely responsible for everything: buying and maintaining the hardware, installing and updating the operating system and Docker, configuring network settings, ensuring security (this is a big one!), and performing regular backups.

If something breaks, there’s no support line to call, and it’s up to you to fix it. This requires a certain level of technical knowledge and a willingness to learn and troubleshoot.

There’s also the upfront cost of hardware, which can range from minimal for a Raspberry Pi to significant for a powerful server. You also need to consider ongoing costs like electricity. Furthermore, your home internet connection might not be ideal for hosting services, especially regarding upload speed or data caps.

Finally, it takes time, time to set up, time to maintain, and time to fix things when they inevitably go wrong. It’s definitely more involved than just clicking a button on a cloud provider’s website.

📖 Suggested read: When And Why To Use Docker — Full Guide

What is Cloud-Based Docker?

The flip side to running Docker containers on your own servers (self-hosting) is Cloud-Based Docker. This means you’re paying a cloud provider like Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, DigitalOcean, or others, to run your Docker containers for you on their massive, optimized infrastructure.

Instead of managing physical servers yourself, you interact with web dashboards or command-line tools to tell the provider what containers you want to run, how many resources they need, and how they should connect to the internet or other services.

Think back to the apartment versus house analogy. Cloud-based Docker is like renting a fully serviced apartment in a large complex. You don’t worry about the building’s foundation, the plumbing, or the electricity grid connection; the building management (the cloud provider) handles all that.

They offer various services specifically designed for running containers, ranging from simple “run this container for me” options to complex orchestration systems like Kubernetes (often provided as managed services like EKS, GKE, or AKS) that can manage large clusters of containers automatically. This option allows you to focus more on your application inside the container and less on the nuts and bolts that keep it physically running.

📖 Suggested read: Docker Security — Best Practices to Secure a Docker Container

What Are The Benefits of Cloud-Based Docker?

Choosing the cloud route for your Docker containers comes with some significant advantages. One of the biggest perks is scalability.

Need more power for a sudden traffic spike? With most cloud providers, you can scale up your resources (CPU, RAM, number of container instances) almost instantly with just a few clicks or commands – and scale back when demand drops.

Most cloud providers only bill for what you use, which can be very efficient. Reliability and uptime are also major selling points; these providers have teams of experts, redundant hardware, backup power, and high-speed network connections designed to keep things running smoothly, often backed by guarantees called Service Level Agreements (SLAs).

Additionally, cloud providers handle the underlying infrastructure management, and you don’t need to worry about hardware failures, operating system updates, or patching the Docker engine itself. This frees up your time to focus purely on developing and improving your application.

They also offer a rich ecosystem of integrated services, making it easy to add databases, load balancers, monitoring tools, automatic backups, and advanced security features to your containerized applications. Getting started can often be quicker and require less upfront investment than buying dedicated server hardware.

📖 Suggested read: 20 Essential Docker Commands You Should Know

What Are The Drawbacks of Cloud-Based Docker?

While the convenience is tempting, renting a cloud server has its downsides. The most obvious one is cost. While pay-as-you-go sounds great, cloud bills can quickly spiral out of control if you’re not careful about resource usage, especially at scale, or leave resources running unnecessarily.

Understanding the often complex pricing models of different providers requires careful attention. You might also experience “vendor lock-in”, where moving your setup from one cloud provider to another becomes difficult due to reliance on specific proprietary services or tools.

Another key drawback is reduced control. You don’t own the hardware and have limited say over the underlying infrastructure, network configuration specifics, or the provider’s maintenance schedules. Although cloud providers offer a lot of flexibility, some advanced users might also encounter limitations compared to having direct access to the bare metal.

Data privacy can also be a concern for some; your application data resides on the provider’s servers, subject to their terms, policies, and the legal jurisdiction they operate under. Lastly, while cloud platforms abstract away hardware management, navigating their vast array of services, interfaces, and configurations introduces its own layer of complexity that requires learning.

Wrapping Up: Who Should Use Self-Hosting Docker vs Cloud-Based Docker?

Choosing between self-hosting Docker and using a cloud-based provider depends on your needs, technical comfort level, budget, and priorities.

If you prioritize maximum control over your data, enjoy tinkering with technology, have particular privacy requirements, or are looking for the potentially lowest long-term cost (and don’t mind the upfront hardware investment and maintenance), then self-hosting Docker on your own server is likely a great fit.

On the other hand, if your priority is convenience, rapid scalability, high availability backed by SLAs, and minimizing the time spent on infrastructure management, then a cloud-based Docker solution (like those from AWS, Google Cloud, Azure, etc.) is probably the way to go. This path suits startups needing to move fast, businesses experiencing variable workloads, teams that prefer focusing solely on application development, and anyone who values the ease of integrated managed services like databases and load balancers. While potentially more expensive month-to-month, it offloads a significant operational burden.

Ultimately, the “best” choice is the one that aligns with your goals.

But what if you want the control and potential cost benefits of self-hosting without all the command-line complexity?

That’s where RunCloud comes in!

RunCloud dramatically simplifies managing your own servers and deploying applications, including Docker containers for managing different PHP runtimes.

Sign up for RunCloud today and discover how simple server management can be.

FAQs on Self-Hosting Docker vs Cloud-Based Docker

Is self-hosting Docker more secure than cloud-based Docker?

Security depends heavily on implementation, not just the hosting type; self-hosting Docker gives you full control over security measures, but you are entirely responsible for implementing and maintaining them correctly. Cloud providers invest heavily in security infrastructure and personnel, offering robust protection, but you rely on their systems and policies. Ultimately, a poorly secured self-hosted setup is less secure than a well-managed cloud environment, and vice versa.

What are the cost differences between self-hosting Docker and using a cloud-based solution?

Self-hosting Docker typically has higher upfront hardware costs but can lead to lower, predictable monthly expenses, mainly electricity and internet. Cloud-based Docker solutions usually have little to no upfront cost but involve recurring monthly fees based on resource consumption, which can escalate quickly as usage grows. Carefully analyze your expected resource needs and growth to determine the most cost-effective option.

Which is more scalable: self-hosted Docker or cloud-based Docker?

Cloud-based Docker solutions are inherently designed for easy and rapid scalability. You can adjust resources up or down almost instantly via dashboards or APIs. Scaling a self-hosted Docker environment requires manually adding more hardware (servers, RAM, storage), which takes time, planning, and physical intervention.

Can I easily switch from self-hosting Docker to a cloud-based solution?

Migrating Docker containers themselves is relatively straightforward since containers package dependencies, but the ease of switching depends on your overall architecture. If your self-hosted setup relies heavily on local network configurations or specific hardware integrations, moving to a cloud provider will require careful planning and reconfiguring networking, storage, and associated services.

What is the performance difference between self-hosting and cloud-based Docker?

Performance can vary greatly depending on the hardware (self-hosted) or chosen instance types (cloud) and network conditions. High-end self-hosted hardware might outperform entry-level cloud instances, while premium cloud instances offer performance levels that are hard to match along with optimized network backbones.

Is self-hosting Docker suitable for small businesses?

Self-hosting Docker can be suitable for small businesses, especially those with in-house technical expertise or those using management tools. It offers potential cost savings and greater data control. However, it requires a commitment to managing infrastructure, security, and updates, which can divert focus from core business activities.

What are the maintenance requirements for self-hosting Docker?

Self-hosting Docker demands ongoing maintenance, including updating the host operating system, patching the Docker engine itself, monitoring resource usage, managing hardware, and maintaining security configurations. You are also responsible for setting up and verifying backups and planning for hardware failures. Using server management platforms like RunCloud can automate some tasks, but the ultimate responsibility for the infrastructure’s health and security rests with the owner.

How does data backup work in self-hosting vs cloud-based Docker solutions?

With self-hosting Docker, you must design and implement your backup strategy, deciding what data (volumes, databases, config files) to back up, how often, and where to securely store the backups. Cloud providers typically offer integrated, often automated, backup solutions for storage volumes and databases associated with your containers.

April 8, 2025