Yes, WordPress can run well on a server with 1 GB of RAM, as long as you tune the whole stack instead of a single setting, and make sure most visitors are served from a page cache rather than by PHP. The changes below are ordered by impact: cache pages, cap PHP-FPM workers, size MariaDB to your real data, enable OPcache, trim plugins, and add swap as a safety net.<\/p>\n
The examples use Ubuntu 24.04 with Nginx, PHP 8.3 and MariaDB (MySQL works the same way; only paths and service names differ). Replace On a 1 GB server, RAM is shared by the operating system, Nginx, PHP-FPM workers, MariaDB and anything else you run, such as a mail daemon, a monitoring agent or a second site. Two components decide whether the server stays stable:<\/p>\n As a rough planning sketch, not a benchmark: reserve roughly 150 to 250 MB for the operating system and background services, 30 to 50 MB for Nginx, and 150 to 250 MB for MariaDB. That leaves somewhere around 350 to 500 MB for PHP-FPM. Your real figures will differ, which is why the first step is to measure.<\/p>\n Start with a snapshot of overall memory and the biggest consumers:<\/p>\n The This includes the small master process and counts shared memory more than once, so treat it as an upper estimate. For a fairer figure, install Then check whether the server is already under memory pressure. Watch the Write these numbers down. They are your baseline for judging every change that follows.<\/p>\n The single biggest improvement on a small server is not running PHP for anonymous visitors at all. Nginx FastCGI caching stores the finished HTML and serves it directly, so most requests never reach WordPress or the database.<\/p>\n First define the cache zone in the Then, in your site’s Create the directory, test the configuration and reload:<\/p>\n Verify it works by requesting the same page twice. The first response should say Two things to know. Requests with a query string bypass the cache in this setup, so links with tracking parameters are served dynamically. And new or edited content appears when the cached copy expires, or when you clear the cache directory. If you always see The pool configuration decides how many PHP workers can exist at once. Too many and the server runs out of memory; too few and requests queue. The three process managers behave differently:<\/p>\n8.3<\/code> with your PHP version and adjust paths for your distribution. Every step starts with measurement, because the right numbers depend on your plugins, theme and traffic, not on a universal template.<\/p>\nWhere the memory actually goes<\/h2>\n
\n
Step 1: Measure before you change anything<\/h2>\n
free -h\nps -eo pid,rss,cmd --sort=-rss | head -15<\/code><\/pre>\nrss<\/code> column is in kilobytes. To see how large your PHP-FPM workers really are, average them:<\/p>\nps -C php-fpm8.3 -o rss= | awk '{s+=$1; n++} END {printf \"processes: %d, average: %.0f MB\\n\", n, s\/n\/1024}'<\/code><\/pre>\nsmem<\/code> and read the proportional set size (PSS) column:<\/p>\nsudo apt install smem\nsudo smem -t -k -P php-fpm<\/code><\/pre>\nsi<\/code> and so<\/code> columns of vmstat<\/code>; values that stay above zero mean the system is actively swapping. Also look for out-of-memory kills:<\/p>\nvmstat 1 5\nsudo journalctl -k | grep -i \"out of memory\"<\/code><\/pre>\nStep 2: Serve pages from a cache so PHP barely runs<\/h2>\n
http<\/code> context, for example in \/etc\/nginx\/conf.d\/wp-cache.conf<\/code>:<\/p>\nfastcgi_cache_path \/var\/cache\/nginx\/wordpress levels=1:2 keys_zone=WPCACHE:10m max_size=256m inactive=60m use_temp_path=off;\nfastcgi_cache_key \"$scheme$request_method$host$request_uri\";<\/code><\/pre>\nserver<\/code> block, decide which requests must never be cached, and attach the cache to the PHP location:<\/p>\nset $skip_cache 0;\nif ($request_method = POST) { set $skip_cache 1; }\nif ($query_string != \"\") { set $skip_cache 1; }\nif ($request_uri ~* \"\/wp-admin\/|\/wp-login.php|\/xmlrpc.php|wp-.*\\.php|\/feed\/\") { set $skip_cache 1; }\nif ($http_cookie ~* \"comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in\") { set $skip_cache 1; }\n\nlocation ~ \\.php$ {\n include snippets\/fastcgi-php.conf;\n fastcgi_pass unix:\/run\/php\/php8.3-fpm.sock;\n fastcgi_cache WPCACHE;\n fastcgi_cache_valid 200 301 302 30m;\n fastcgi_cache_bypass $skip_cache;\n fastcgi_no_cache $skip_cache;\n fastcgi_cache_lock on;\n fastcgi_cache_use_stale error timeout updating http_500 http_503;\n add_header X-FastCGI-Cache $upstream_cache_status;\n}<\/code><\/pre>\nsudo mkdir -p \/var\/cache\/nginx\/wordpress\nsudo chown www-data:www-data \/var\/cache\/nginx\/wordpress\nsudo nginx -t && sudo systemctl reload nginx<\/code><\/pre>\nMISS<\/code> and the second HIT<\/code>:<\/p>\ncurl -sI https:\/\/example.com\/ | grep -i x-fastcgi-cache\ncurl -sI https:\/\/example.com\/ | grep -i x-fastcgi-cache<\/code><\/pre>\nBYPASS<\/code> or MISS<\/code>, look for a plugin that sends a Set-Cookie<\/code> or Cache-Control: no-cache<\/code> header on public pages. If you cannot change the Nginx configuration, a lightweight page-cache plugin is the fallback, but the server-level cache uses less memory.<\/p>\nStep 3: Right-size PHP-FPM<\/h2>\n