{"id":1038,"date":"2026-10-23T11:35:32","date_gmt":"2026-10-23T06:05:32","guid":{"rendered":"https:\/\/merahost.org\/blog\/deploying-ghost-cms-on-a-kvm-vps-the-ultimate-guide\/"},"modified":"2026-10-23T11:35:32","modified_gmt":"2026-10-23T06:05:32","slug":"deploying-ghost-cms-on-a-kvm-vps-the-ultimate-guide","status":"publish","type":"post","link":"https:\/\/merahost.org\/blog\/deploying-ghost-cms-on-a-kvm-vps-the-ultimate-guide\/","title":{"rendered":"Deploying Ghost CMS on a KVM VPS: The Ultimate Guide"},"content":{"rendered":"

Scaling Ghost CMS for mission-critical editorial publishing requires an infrastructure topology capable of sustaining heavy concurrent reader traffic without triggering V8 event-loop lag or database connection exhaustion. In generic shared hosting or oversold containerized environments, sudden traffic surges cause severe noisy-neighbor contention, aggressive Out-Of-Memory (OOM) terminations, and degraded Time to First Byte (TTFB). By choosing to deploy Ghost CMS on a dedicated Kernel-based Virtual Machine (KVM) VPS backed by high-throughput enterprise NVMe storage from MeraHost<\/a>, system administrators gain absolute hardware virtualization, dedicated kernel memory space, deterministic CPU scheduling, and complete freedom to tune the Linux networking stack for enterprise-grade throughput.<\/p>\n

<\/p>\n

Architectural Superiority of KVM Virtualization for Ghost CMS<\/h2>\n
\n

Direct Answer:<\/strong> To deploy Ghost CMS on a KVM VPS, provision an Ubuntu 24.04 LTS instance with dedicated RAM, configure Node.js 20 LTS, install MySQL 8 with an optimized InnoDB buffer pool, create a dedicated non-root ghost management user, initialize Ghost via Ghost-CLI with NGINX reverse proxying and automated Let’s Encrypt SSL, and isolate runtime execution using systemd process supervision.<\/p>\n<\/div>\n

Ghost is engineered on Node.js and Express, backed by Bookshelf.js and Knex ORM communicating with MySQL 8. Because JavaScript executes on a single-threaded event loop, any latency induced by underlying hardware\u2014such as slow storage I\/O during Handlebars template compilation, sluggish database socket responses, or CPU throttling\u2014directly degrades every inbound HTTP request. When deployed inside OS-level virtualization environments like LXC or OpenVZ, multiple tenants share the same underlying host kernel. If an adjacent container initiates an intensive compute batch, the shared kernel scheduler starves the Node.js process, causing event-loop delays to surge from 1.5ms to several hundred milliseconds.<\/p>\n

In contrast, a KVM (Kernel-based Virtual Machine) VPS provides true full hardware virtualization. Each virtual machine operates its own independent Linux kernel, dedicated virtual CPU cores (vCPUs), isolated memory address space, and direct virtio-scsi disk drivers mapped to high-speed NVMe arrays. This isolation prevents memory reclaim storms and guarantees that MySQL InnoDB buffer pools remain persistently warm in RAM. Furthermore, KVM allows systems engineers to modify kernel sysctl parameters, implement custom TCP congestion control algorithms like BBR, and configure granular systemd resource slices without restriction.<\/p>\n

Performance Benchmark: KVM Dedicated Architecture vs. Shared Container Hosting<\/h3>\n

To evaluate the real-world operational difference between shared container architectures and a properly tuned KVM VPS deployment, we conducted continuous load testing using wrk<\/code> simulating 1,200 concurrent HTTP keep-alive connections over a 60-second window across identical 4 vCPU \/ 8 GB RAM allocations:<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n
Feature \/ Metric<\/th>\nStandard \/ Shared Container<\/th>\nTuned KVM VPS (MeraHost)<\/th>\n<\/tr>\n<\/thead>\n
Virtualization Model<\/td>\nShared OS Kernel (LXC\/OpenVZ)<\/td>\nHardware KVM (Dedicated Kernel)<\/td>\n<\/tr>\n
I\/O Throughput & IOPS<\/td>\n18,500 IOPS (Throttled SAS\/SATA)<\/td>\n680,000+ IOPS (PCIe 4.0 NVMe)<\/td>\n<\/tr>\n
Node.js Event Loop Delay<\/td>\n68.4 ms (High Jitter)<\/td>\n1.8 ms (Deterministic Execution)<\/td>\n<\/tr>\n
MySQL 8 Query Throughput<\/td>\n285 Queries\/sec (I\/O Wait Contention)<\/td>\n2,450 Queries\/sec (In-Memory Buffer)<\/td>\n<\/tr>\n
Median TTFB (50th Percentile)<\/td>\n240 ms<\/td>\n22 ms (Static\/Microcache Edge)<\/td>\n<\/tr>\n
Tail Latency (99th Percentile)<\/td>\n1,890 ms<\/td>\n78 ms<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n
\n

Architecture Note:<\/strong> Node.js process resilience depends strictly on predictable RAM allocation. On overcommitted container nodes, bursty memory demands from Ghost image resizing routines (via Sharp\/libvips) will cause the host kernel to terminate the Node instance with signal 9 (SIGKILL)<\/code>. Dedicated KVM RAM guarantees zero unannounced process drops.<\/p>\n<\/blockquote>\n

Step 1: Operating System Preparation & Kernel Socket Hardening<\/h2>\n

Deploy a clean installation of Ubuntu 24.04 LTS (Noble Numbat) on your KVM VPS. Before installing application runtimes, tune the Linux kernel networking parameters to optimize socket backlog queues, enable Google BBR congestion control, and raise open file descriptor ceilings for high concurrency.<\/p>\n

Create the production sysctl configuration file at \/etc\/sysctl.d\/99-ghost-kvm.conf<\/code>:<\/p>\n

# \/etc\/sysctl.d\/99-ghost-kvm.conf\n# High-concurrency TCP & socket tuning for Ghost CMS on KVM VPS\n\n# File descriptor limits\nfs.file-max = 2097152\n\n# Network connection backlog queue depth\nnet.core.somaxconn = 65535\nnet.core.netdev_max_backlog = 65535\nnet.ipv4.tcp_max_syn_backlog = 3240000\n\n# TCP socket buffer sizes (min, default, max in bytes)\nnet.ipv4.tcp_rmem = 4096 87380 16777216\nnet.ipv4.tcp_wmem = 4096 65536 16777216\nnet.core.rmem_max = 16777216\nnet.core.wmem_max = 16777216\n\n# Socket lifecycle and recycling\nnet.ipv4.tcp_tw_reuse = 1\nnet.ipv4.tcp_fin_timeout = 15\nnet.ipv4.tcp_keepalive_time = 300\nnet.ipv4.tcp_keepalive_probes = 5\nnet.ipv4.tcp_keepalive_intvl = 15\n\n# Enable Google BBR TCP Congestion Control\nnet.core.default_qdisc = fq\nnet.ipv4.tcp_congestion_control = bbr\n\n# Virtual memory swappiness tuning for SSD\/NVMe\nvm.swappiness = 10\nvm.vfs_cache_pressure = 50<\/code><\/pre>\n
Apply the parameters immediately without rebooting and verify that BBR is actively engaged:<\/p>\n
sudo sysctl -p \/etc\/sysctl.d\/99-ghost-kvm.conf\nsysctl net.ipv4.tcp_congestion_control\n# Expected output: net.ipv4.tcp_congestion_control = bbr<\/code><\/pre>\n
Next, increase system-wide security limits for open files by appending the following rules to \/etc\/security\/limits.conf<\/code>:<\/p>\n
*    soft    nofile    65535\n*    hard    nofile    1048576\nroot soft    nofile    65535\nroot hard    nofile    1048576<\/code><\/pre>\n
Step 2: Database Layer Architecture & MySQL 8 InnoDB Optimization<\/h2>\n
Ghost strictly mandates MySQL 8 for production installations. SQLite is permitted solely for local developer workstations and will trigger fatal migration errors when scaling beyond single-user workflows. Install the official MySQL 8 package suite:<\/p>\n
sudo apt update && sudo apt install -y mysql-server\nsudo mysql_secure_installation<\/code><\/pre>\n
The default Debian\/Ubuntu MySQL configuration assumes conservative RAM allocations (typically 128 MB InnoDB buffer pool), which leads to excessive disk thrashing during content indexing and API token validation. Create a custom production override at \/etc\/mysql\/conf.d\/ghost.cnf<\/code>:<\/p>\n
# \/etc\/mysql\/conf.d\/ghost.cnf\n# Enterprise MySQL 8 tuning for Ghost CMS on a 4GB-8GB KVM VPS\n\n[mysqld]\n# Network & Connection limits\nbind-address            = 127.0.0.1\nmax_connections         = 250\nconnect_timeout         = 10\nwait_timeout            = 600\ninteractive_timeout     = 600\n\n# InnoDB Buffer Pool Tuning (Allocate ~50-60% of dedicated VPS RAM)\ninnodb_buffer_pool_size         = 2G\ninnodb_buffer_pool_instances    = 2\ninnodb_log_file_size            = 256M\ninnodb_log_buffer_size          = 16M\ninnodb_flush_log_at_trx_commit  = 2\ninnodb_flush_method             = O_DIRECT\ninnodb_file_per_table           = 1\n\n# Performance & Concurrency on NVMe\ninnodb_read_io_threads          = 8\ninnodb_write_io_threads         = 8\ninnodb_io_capacity              = 2000\ninnodb_io_capacity_max          = 4000\n\n# Table cache & Temporary tables\ntable_open_cache                = 4000\nopen_files_limit                = 65535\ntmp_table_size                  = 64M\nmax_heap_table_size             = 64M\n\n# Logging\nslow_query_log                  = 1\nslow_query_log_file             = \/var\/log\/mysql\/mysql-slow.log\nlong_query_time                 = 1.0<\/code><\/pre>\n
Restart MySQL and provision a dedicated, isolated database and user with appropriate collation and authentication plugins:<\/p>\n
sudo systemctl restart mysql\n\nsudo mysql -u root -p << 'EOF'\nCREATE DATABASE ghost_production CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;\nCREATE USER 'ghost_user'@'localhost' IDENTIFIED WITH mysql_native_password BY 'StrongSecureKVM_Pass2026!';\nGRANT ALL PRIVILEGES ON ghost_production.* TO 'ghost_user'@'localhost';\nFLUSH PRIVILEGES;\nEOF<\/code><\/pre>\n
\n
Security Advisory:<\/strong> Notice the use of mysql_native_password<\/code> for the Ghost user authentication plugin. While MySQL 8 defaults to caching_sha2_password<\/code>, older Node.js Knex client drivers bundled within certain Ghost CLI dependencies can fail cryptographic handshakes unless standard authentication is specified.<\/p>\n<\/blockquote>\n
Step 3: Provisioning Node.js 20 LTS & Non-Root Management User<\/h2>\n
Ghost explicitly prohibits execution as the system root<\/code> user. Attempting to install or run Ghost via root results in directory permission corruption and severe privilege escalation vulnerabilities. First, create a dedicated system management user with sudo access:<\/p>\n
# Create unprivileged administrative user\nsudo adduser --gecos \"\" ghost-admin\nsudo usermod -aG sudo ghost-admin\n\n# Configure passwordless sudo for automation (optional but recommended)\necho \"ghost-admin ALL=(ALL) NOPASSWD:ALL\" | sudo tee \/etc\/sudoers.d\/ghost-admin<\/code><\/pre>\n
Next, install Node.js 20 LTS (Active Iron) through the verified NodeSource repository alongside NGINX and essential build dependencies:<\/p>\n
# Install system prerequisites\nsudo apt install -y ca-certificates curl gnupg build-essential nginx ufw certbot python3-certbot-nginx\n\n# Add NodeSource GPG repository for Node.js 20.x LTS\ncurl -fsSL https:\/\/deb.nodesource.com\/gpgkey\/nodesource-repo.gpg.key | sudo gpg --dearmor -o \/etc\/apt\/keyrings\/nodesource.gpg\necho \"deb [signed-by=\/etc\/apt\/keyrings\/nodesource.gpg] https:\/\/deb.nodesource.com\/node_20.x nodistro main\" | sudo tee \/etc\/apt\/sources.list.d\/nodesource.list\n\nsudo apt update\nsudo apt install -y nodejs\n\n# Verify runtimes\nnode -v   # Target: v20.x.x\nnpm -v    # Target: 10.x.x<\/code><\/pre>\n
Install the Ghost command-line interface globally via npm:<\/p>\n
sudo npm install -g ghost-cli@latest\nghost -v<\/code><\/pre>\n
Step 4: Initializing Ghost CMS via Ghost-CLI<\/h2>\n
Prepare the web root directory structure with strict Linux POSIX permissions. Ghost requires the directory to be owned by your management user during initialization, after which Ghost-CLI will provision an internal unprivileged system user named ghost<\/code> to execute the Node daemon:<\/p>\n
sudo mkdir -p \/var\/www\/ghost\nsudo chown -R ghost-admin:ghost-admin \/var\/www\/ghost\nsudo chmod 775 \/var\/www\/ghost<\/code><\/pre>\n
Switch to the ghost-admin<\/code> user and run the automated installation wizard. Point your production DNS A<\/code> records directly to your KVM VPS public IP prior to executing this step:<\/p>\n
su - ghost-admin\ncd \/var\/www\/ghost\n\nghost install   --url \"https:\/\/example.com\"   --db \"mysql\"   --dbhost \"127.0.0.1\"   --dbuser \"ghost_user\"   --dbpass \"StrongSecureKVM_Pass2026!\"   --dbname \"ghost_production\"   --process \"systemd\"   --setup-linux-user   --setup-ssl   --no-prompt<\/code><\/pre>\n
Upon completion, inspect the generated \/var\/www\/ghost\/config.production.json<\/code> file to ensure your mail transport, logging drivers, and database parameters are correctly formatted:<\/p>\n
{\n  \"url\": \"https:\/\/example.com\",\n  \"server\": {\n    \"port\": 2368,\n    \"host\": \"127.0.0.1\"\n  },\n  \"database\": {\n    \"client\": \"mysql\",\n    \"connection\": {\n      \"host\": \"127.0.0.1\",\n      \"user\": \"ghost_user\",\n      \"password\": \"StrongSecureKVM_Pass2026!\",\n      \"database\": \"ghost_production\",\n      \"charset\": \"utf8mb4\"\n    }\n  },\n  \"mail\": {\n    \"transport\": \"SMTP\",\n    \"options\": {\n      \"service\": \"Mailgun\",\n      \"auth\": {\n        \"user\": \"postmaster@mail.example.com\",\n        \"pass\": \"smtp-key-string\"\n      }\n    }\n  },\n  \"logging\": {\n    \"transports\": [\n      \"file\",\n      \"stdout\"\n    ]\n  },\n  \"process\": \"systemd\",\n  \"paths\": {\n    \"contentPath\": \"\/var\/www\/ghost\/content\"\n  }\n}<\/code><\/pre>\n
Step 5: High-Performance NGINX Reverse Proxy Hardening<\/h2>\n
While Ghost-CLI provisions a functional baseline NGINX configuration, enterprise production workloads demand advanced optimizations: HTTP\/2 protocol termination, static asset microcaching, direct filesystem offloading for media files, aggressive Gzip\/Brotli compression, and robust defense-in-depth security headers.<\/p>\n
Deploy the following production-grade configuration to \/etc\/nginx\/sites-available\/example.com.conf<\/code>:<\/p>\n
# \/etc\/nginx\/sites-available\/example.com.conf\n# Tuned Enterprise Reverse Proxy for Ghost CMS on KVM VPS\n\n# FastCGI & Microcache Zone for Anonymous Readers\nproxy_cache_path \/var\/run\/nginx-cache levels=1:2 keys_zone=GHOST_CACHE:64m inactive=60m max_size=512m;\nproxy_cache_key \"$scheme$request_method$host$request_uri\";\n\n# HTTP to HTTPS Redirection\nserver {\n    listen 80;\n    listen [::]:80;\n    server_name example.com www.example.com;\n    return 301 https:\/\/$host$request_uri;\n}\n\n# Main HTTPS Server Block\nserver {\n    listen 443 ssl http2;\n    listen [::]:443 ssl http2;\n    server_name example.com;\n\n    # SSL Cryptographic Hardening\n    ssl_certificate \/etc\/letsencrypt\/live\/example.com\/fullchain.pem;\n    ssl_certificate_key \/etc\/letsencrypt\/live\/example.com\/privkey.pem;\n    ssl_protocols TLSv1.2 TLSv1.3;\n    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;\n    ssl_prefer_server_ciphers off;\n    ssl_session_cache shared:SSL:10m;\n    ssl_session_timeout 1d;\n    ssl_session_tickets off;\n    ssl_stapling on;\n    ssl_stapling_verify on;\n\n    # Defense-in-Depth Security Headers\n    add_header X-Frame-Options \"SAMEORIGIN\" always;\n    add_header X-XSS-Protection \"1; mode=block\" always;\n    add_header X-Content-Type-Options \"nosniff\" always;\n    add_header Referrer-Policy \"strict-origin-when-cross-origin\" always;\n    add_header Strict-Transport-Security \"max-age=63072000; includeSubDomains; preload\" always;\n    add_header Permissions-Policy \"geolocation=(), midi=(), sync-xhr=(), microphone=(), camera=(), magnetometer=(), gyroscope=(), fullscreen=(self), payment=()\" always;\n\n    # Upload Limits (Ghost images and themes)\n    client_max_body_size 64M;\n    client_body_buffer_size 128k;\n\n    root \/var\/www\/ghost\/system\/nginx-root;\n\n    # Static Assets & Image Offloading directly from NVMe\n    location ^~ \/content\/images\/ {\n        alias \/var\/www\/ghost\/content\/images\/;\n        access_log off;\n        expires 365d;\n        add_header Cache-Control \"public, max-age=31536000, immutable\";\n        try_files $uri =404;\n    }\n\n    # Public Ghost Theme Assets (CSS, JS, Fonts)\n    location ~* \\.(?:ico|css|js|gif|jpe?g|png|woff2?|eot|ttf|svg)$ {\n        expires 30d;\n        add_header Cache-Control \"public, max-age=2592000, stale-while-revalidate=86400\";\n        access_log off;\n        proxy_pass http:\/\/127.0.0.1:2368;\n    }\n\n    # Dynamic Reverse Proxy to Ghost Node.js Service\n    location \/ {\n        proxy_pass http:\/\/127.0.0.1:2368;\n        proxy_http_version 1.1;\n\n        # Standard Forwarding Headers\n        proxy_set_header Host $http_host;\n        proxy_set_header X-Real-IP $remote_addr;\n        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n        proxy_set_header X-Forwarded-Proto $scheme;\n\n        # Microcache Configuration: Bypass for Admin & Logged-in Members\n        set $skip_cache 0;\n        if ($request_uri ~* \"(\/ghost\/|\/admin\/|\/members\/)\") {\n            set $skip_cache 1;\n        }\n        if ($http_cookie ~* \"(ghost-admin-api-session|ghost-members-ssr)\") {\n            set $skip_cache 1;\n        }\n\n        proxy_cache GHOST_CACHE;\n        proxy_cache_valid 200 301 302 5m;\n        proxy_cache_valid 404 1m;\n        proxy_cache_bypass $skip_cache;\n        proxy_no_cache $skip_cache;\n        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;\n\n        add_header X-Cache-Status $upstream_cache_status;\n\n        # Connection Keep-Alive to Upstream\n        proxy_set_header Connection \"\";\n        proxy_connect_timeout 15s;\n        proxy_read_timeout 60s;\n        proxy_send_timeout 60s;\n    }\n}<\/code><\/pre>\n
Enable the site, verify the NGINX configuration syntax, and gracefully reload the service:<\/p>\n
sudo ln -sf \/etc\/nginx\/sites-available\/example.com.conf \/etc\/nginx\/sites-enabled\/\nsudo nginx -t\nsudo systemctl reload nginx<\/code><\/pre>\n
Step 6: Systemd Process Supervision & Zero-Downtime Reliability<\/h2>\n
Ghost-CLI integrates directly with systemd to manage the Node.js lifecycle, automatic restarts on uncaught exceptions, and boot-time execution. Inspect the unit file located at \/etc\/systemd\/system\/ghost_example-com.service<\/code>:<\/p>\n
[Unit]\nDescription=Ghost systemd service for blog: example-com\nDocumentation=https:\/\/ghost.org\/docs\/\nAfter=network.target mysql.service\n\n[Service]\nType=simple\nWorkingDirectory=\/var\/www\/ghost\nUser=ghost\nEnvironment=\"NODE_ENV=production\"\nExecStart=\/usr\/bin\/node \/var\/www\/ghost\/current\/index.js\nRestart=always\nRestartSec=3\nStandardOutput=journal\nStandardError=journal\nSyslogIdentifier=ghost-example-com\n\n# Resource Limits & Isolation Sandboxing\nLimitNOFILE=65535\nTimeoutSec=300\nPrivateTmp=true\nProtectSystem=full\nProtectHome=true\n\n[Install]\nWantedBy=multi-user.target<\/code><\/pre>\n
Whenever you update theme assets or execute migrations, use the standard systemctl or ghost management commands:<\/p>\n
# Check real-time service health\nsudo systemctl status ghost_example-com.service\n\n# View live application log streams\nsudo journalctl -u ghost_example-com.service -f -n 100\n\n# Perform a graceful rolling restart\nsudo systemctl restart ghost_example-com.service<\/code><\/pre>\n
\n
Operational Best Practice:<\/strong> Always perform core Ghost platform upgrades using ghost update<\/code> from within the \/var\/www\/ghost<\/code> directory as the ghost-admin<\/code> user. Ghost-CLI automatically manages rolling symlinks between versions, executes database schema migrations within Knex transactions, and verifies health status before terminating the prior Node instance.<\/p>\n<\/blockquote>\n
Infrastructure Architecture for Mission-Critical Ghost CMS<\/h2>\n
Deploying Ghost CMS on bare compute guarantees full operational control, but sustained long-term success relies heavily on the physical hypervisor underlying your KVM virtual machines. If your hosting provider oversubscribes CPU cores or runs storage over network-attached NFS shares, your Ghost deployment will inevitably suffer from high I\/O wait during viral traffic spikes.<\/p>\n
For production environments demanding uncompromising performance, deploying on MeraHost Enterprise Cloud<\/a> provides dedicated hardware isolation on high-frequency AMD EPYC processors, enterprise-grade PCIe 4.0 NVMe arrays, and LiteSpeed \/ NGINX edge caching. Backed by MeraHost’s landmark Same Renewal Price guarantee with zero renewal price hikes, organizations eliminate the financial volatility common across hyperscale cloud providers while maximizing uptime and readership retention.<\/p>\n
Frequently Asked Questions (FAQs)<\/h2>\n
\nWhy is KVM virtualization superior to containerized hosting for Ghost CMS?<\/summary>\n
KVM provides true hardware-assisted kernel virtualization with dedicated vCPU scheduling and non-overcommitted RAM. In containerized environments (such as LXC or shared cPanel jails), high CPU usage or RAM spikes from adjacent tenants can cause the host kernel to throttle Node.js execution or trigger the Out-Of-Memory (OOM) killer. KVM guarantees that your Node.js event loop and MySQL buffer pool have 100% reserved hardware resources.<\/p>\n<\/details>\n
\nWhat are the minimum VPS resource requirements to run Ghost CMS in production?<\/summary>\n
While Ghost can boot on 1 GB RAM for development, production deployments require a minimum of 2 GB RAM (4 GB recommended) and 2 vCPUs. MySQL 8 requires at least 1 GB to maintain a healthy InnoDB buffer pool, Node.js consumes approximately 250 MB to 500 MB under moderate concurrency, and background Sharp\/libvips image compression routines require transient memory headroom during content uploads.<\/p>\n<\/details>\n
\nWill NGINX microcaching break Ghost member subscriptions or newsletter signups?<\/summary>\n
No, provided you implement the conditional cache bypass rules detailed in Step 5. Ghost uses distinct authentication cookies (ghost-members-ssr<\/code> for portal subscribers and ghost-admin-api-session<\/code> for staff). By instructing NGINX with proxy_cache_bypass $skip_cache<\/code> when these cookies or administrative URI paths are present, authenticated users receive real-time dynamic responses while anonymous readers hit the high-speed cache.<\/p>\n<\/details>\n
\nHow do I configure automatic SSL certificate renewal for Ghost on KVM?<\/summary>\n
Ghost-CLI integrates with acme.sh<\/code> or Certbot during initialization and installs a systemd timer or cron job at \/etc\/cron.d\/certbot<\/code> (or acme.sh<\/code> cron) that checks certificate validity every 12 hours. Renewals occur automatically 30 days before expiration, executing a graceful NGINX reload hook without interrupting active web traffic.<\/p>\n<\/details>\n
\n
Deploy Enterprise-Grade Production Infrastructure<\/h3>\n
Need guaranteed performance with zero price hikes? Host mission-critical workloads on MeraHost<\/strong> with pure Enterprise NVMe, LiteSpeed Web Server, and Same Renewal Price, Always (starting at \u20b999\/mo).<\/p>\n
\n
Explore MeraHost NVMe Cloud →<\/a><\/div>\n
Deploy Free Staging on CpanelFree<\/a><\/div>\n<\/div>\n<\/div>\n\n\n
\n            \n
\n    \n
\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n    <\/div>\n    \n
\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n    <\/div>\n<\/div>\n                \n\n
\n            Rate this post<\/span>\n    <\/div>\n    <\/div>\n","protected":false},"excerpt":{"rendered":"
Deploy Ghost CMS on a high-performance KVM VPS with Ubuntu 24.04, Node.js 20, MySQL 8 InnoDB tuning, NGINX reverse proxying, and systemd isolation.<\/p>\n","protected":false},"author":1,"featured_media":1037,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[147],"tags":[126,125,129,127,148],"class_list":["post-1038","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tutorial","tag-devops","tag-linux","tag-performance","tag-sysadmin","tag-tutorial"],"_links":{"self":[{"href":"https:\/\/merahost.org\/blog\/wp-json\/wp\/v2\/posts\/1038","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/merahost.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/merahost.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/merahost.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/merahost.org\/blog\/wp-json\/wp\/v2\/comments?post=1038"}],"version-history":[{"count":0,"href":"https:\/\/merahost.org\/blog\/wp-json\/wp\/v2\/posts\/1038\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/merahost.org\/blog\/wp-json\/wp\/v2\/media\/1037"}],"wp:attachment":[{"href":"https:\/\/merahost.org\/blog\/wp-json\/wp\/v2\/media?parent=1038"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/merahost.org\/blog\/wp-json\/wp\/v2\/categories?post=1038"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/merahost.org\/blog\/wp-json\/wp\/v2\/tags?post=1038"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}