{"id":5135,"date":"2026-11-06T19:04:24","date_gmt":"2026-11-06T13:34:24","guid":{"rendered":"https:\/\/cpanelfree.com\/blog\/deploying-nodejs-and-nextjs-on-linux-vps-pm2-nginx-reverse-proxy-and-zero-downtime-reloads\/"},"modified":"2026-11-06T19:04:24","modified_gmt":"2026-11-06T13:34:24","slug":"deploying-nodejs-and-nextjs-on-linux-vps-pm2-nginx-reverse-proxy-and-zero-downtime-reloads","status":"publish","type":"post","link":"https:\/\/cpanelfree.com\/blog\/deploying-nodejs-and-nextjs-on-linux-vps-pm2-nginx-reverse-proxy-and-zero-downtime-reloads\/","title":{"rendered":"Deploying Node.js and Next.js on Linux VPS: PM2, Nginx Reverse Proxy, and Zero-Downtime Reloads"},"content":{"rendered":"

Deploying Node.js and Next.js applications in mission-critical production environments exposes a fundamental architectural tension: modern full-stack frameworks excel at dynamic server-side rendering (SSR), Incremental Static Regeneration (ISR), and API route execution, yet the underlying single-threaded V8 JavaScript runtime quickly stalls under high concurrency, uncaught promise rejections, or memory leaks without an enterprise-grade process orchestration layer. Simply executing npm start<\/code> directly on a public-facing network interface leaves your application vulnerable to dropped TCP sockets during deployments, unbuffered client request stalls, lack of automatic core clustering, and zero resilience against traffic spikes. Forward-thinking DevOps teams and systems architects prototype, benchmark, and validate their container-free staging stacks on high-performance free environments like CpanelFree<\/a> before deploying hardened production infrastructure across enterprise Linux VPS clusters.<\/p>\n

<\/p>\n

What Is the Production Architecture to Deploy Next.js on a Linux VPS with Nginx and PM2?<\/h2>\n
\nDirect Answer:<\/strong> To deploy nextjs on linux vps nginx pm2<\/strong> for enterprise workloads, compile Next.js into a standalone bundle (output: 'standalone'<\/code>), manage multi-core worker instances using PM2 cluster mode with graceful IPC readiness signals, and terminate traffic behind an Nginx reverse proxy configured for TLS offloading, static asset microcaching, WebSocket upgrades, and rolling zero-downtime reloads.\n<\/div>\n

The Anatomy of a Production Next.js Bottleneck: Why Raw Node.js Fails<\/h2>\n

In development environments, executing npm run dev<\/code> or npm start<\/code> provides immediate feedback and hot-reloading convenience. However, running raw Node.js in production introduces severe operational vulnerabilities rooted in the fundamental architecture of the V8 engine and the libuv event loop. Because Node.js executes JavaScript on a single thread, CPU-bound operations\u2014such as heavy JSON parsing, server-side HTML rendering of massive React component trees, and cryptographic signing\u2014monopolize the event loop. When the event loop is blocked, all incoming HTTP connections wait in the kernel backlog queue, causing response latencies to spike from milliseconds to seconds.<\/p>\n

Furthermore, modern Next.js features such as the App Router, React Server Components (RSC), and Image Optimization demand significant memory. Without an external process supervisor, an unhandled exception or fatal out-of-memory (OOM) error will terminate the entire Node.js runtime process instantly, returning connection reset errors to all in-flight client requests until an administrator manually restarts the service. Operating without a reverse proxy compounds this vulnerability: Node.js must handle slow client connections (Slowloris attacks), negotiate TLS handshakes, manage HTTP keep-alive pools, and serve static JavaScript chunks, wasting precious compute cycles that should be reserved strictly for SSR execution.<\/p>\n

Performance & Architecture Matrix: Raw Node.js vs. Clustered PM2 & Nginx<\/h2>\n

The following architectural matrix illustrates the concrete operational differences between running a default unmanaged Next.js instance versus a hardened Linux VPS stack combining PM2 cluster mode, Nginx reverse proxy, and Linux kernel tuning.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n\n
Feature \/ Metric<\/th>\nStandard \/ Default (npm start)<\/th>\nTuned \/ Production (PM2 + Nginx)<\/th>\n<\/tr>\n<\/thead>\n
CPU Utilization<\/td>\nSingle-Core Bottleneck (1 Core max)<\/td>\nAll Cores Saturated via PM2 Cluster Mode<\/td>\n<\/tr>\n
Deployment Downtime<\/td>\n3 to 15 seconds outage during process restart<\/td>\nZero Downtime (Rolling Graceful Reloads)<\/td>\n<\/tr>\n
Static Asset Delivery<\/td>\nNode.js V8 Event Loop Overhead (~15ms)<\/td>\nDirect Disk Offload via Nginx epoll (<1ms)<\/td>\n<\/tr>\n
Memory Management<\/td>\nUncontrolled leaks trigger fatal OOM crashes<\/td>\nAutomatic Worker Recycling at 1024MB threshold<\/td>\n<\/tr>\n
TLS \/ SSL Termination<\/td>\nV8 OpenSSL bindings consume app RAM<\/td>\nNginx OpenSSL with HTTP\/2 and Session Resumption<\/td>\n<\/tr>\n
Crash Recovery<\/td>\nManual intervention or container exit<\/td>\nInstant Sub-Second Watchdog Resurrection<\/td>\n<\/tr>\n
Latency \/ Overhead<\/td>\nBaseline Unbuffered (High Tail Latency)<\/td>\nOptimal (P99 latency drops by 78%)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

Pillar 1: Optimizing the Next.js Build Pipeline with Standalone Output<\/h2>\n

A typical Next.js production build includes the complete node_modules<\/code> directory, which often exceeds 800MB to 1.5GB of disk space. Transferring this bloated directory during CI\/CD pipelines wastes bandwidth, exhausts VPS disk space, and prolongs deployment windows. Next.js provides a native enterprise solution: the standalone<\/code> build output. When enabled, Next.js utilizes static code tracing to analyze all imports and packages only the bare minimum runtime dependencies into a self-contained folder at .next\/standalone<\/code>, reducing deployment payloads by over 85%.<\/p>\n

Production next.config.mjs Configuration:<\/strong><\/p>\n

\/** @type {import('next').NextConfig} *\/\nconst nextConfig = {\n  \/\/ Output standalone directory for high-efficiency production deployments\n  output: 'standalone',\n  \n  \/\/ Enforce strict React rendering rules to catch concurrency bugs early\n  reactStrictMode: true,\n  \n  \/\/ Power optimizations: remove powered-by header for security hardening\n  poweredByHeader: false,\n  \n  \/\/ Image optimization parameters for production VPS hosting\n  images: {\n    formats: ['image\/avif', 'image\/webp'],\n    minimumCacheTTL: 604800,\n  },\n  \n  \/\/ Compress assets using gzip before streaming to Nginx\n  compress: true,\n};\n\nexport default nextConfig;<\/code><\/pre>\n
\n
Architecture Note:<\/strong> The Next.js standalone build generates a streamlined server.js<\/code> inside .next\/standalone<\/code>, but it intentionally excludes client-side static bundles and public media assets to minimize build artifact size. In your production deployment automation, you MUST explicitly copy the public\/<\/code> folder into .next\/standalone\/public\/<\/code> and the .next\/static\/<\/code> folder into .next\/standalone\/.next\/static\/<\/code>. Omitting this step causes client-side hydration failures and 404 errors on all static CSS and JavaScript chunks.<\/p>\n<\/blockquote>\n
Pillar 2: Enterprise PM2 Cluster Configuration & Graceful Reloads<\/h2>\n
PM2 is the de facto process manager for Node.js in Linux environments. To fully utilize modern multi-core VPS processors, PM2 must be configured in cluster_mode<\/code>. Under the hood, PM2 utilizes the native Node.js cluster<\/code> module, allowing a master process to multiplex incoming TCP connections across multiple child worker processes through a shared socket.<\/p>\n
Achieving true zero-downtime reloads requires precise synchronization between PM2 and the Node.js application. If PM2 kills an old worker before the new worker has initialized its database pools and route cache, clients encounter 502 Bad Gateway<\/code> errors. By setting wait_ready: true<\/code> and configuring an adequate listen_timeout<\/code>, PM2 waits for an inter-process communication (IPC) signal or a successful port bind before terminating the retiring worker.<\/p>\n
Production ecosystem.config.cjs Configuration:<\/strong><\/p>\n
module.exports = {\n  apps: [\n    {\n      name: 'nextjs-production-app',\n      script: '.\/.next\/standalone\/server.js',\n      cwd: '\/var\/www\/nextjs-app',\n      \n      \/\/ Scale across all available CPU cores or specify explicit count\n      instances: 'max',\n      exec_mode: 'cluster',\n      \n      \/\/ Auto-restart if a worker leaks memory past 1GB\n      max_memory_restart: '1024M',\n      \n      \/\/ Environment variables passed to runtime\n      env: {\n        NODE_ENV: 'production',\n        PORT: 3000,\n        HOSTNAME: '127.0.0.1'\n      },\n      \n      \/\/ Graceful zero-downtime reload handshakes\n      wait_ready: true,\n      listen_timeout: 10000,\n      kill_timeout: 5000,\n      \n      \/\/ Health monitoring and auto-restart tuning\n      max_restarts: 10,\n      min_uptime: '15s',\n      restart_delay: 2000,\n      \n      \/\/ Log management with ISO timestamps\n      out_file: '\/var\/log\/pm2\/nextjs-out.log',\n      error_file: '\/var\/log\/pm2\/nextjs-error.log',\n      merge_logs: true,\n      time: true\n    }\n  ]\n};<\/code><\/pre>\n
\n
Architecture Note:<\/strong> When operating Next.js standalone server.js<\/code> with PM2 in cluster_mode<\/code>, the Node.js cluster master binds to the target port (e.g., 3000) once and delegates socket handles across all spawned worker processes. Do not attempt to assign distinct PORT environment variables (e.g., 3001, 3002) to each worker; the cluster module transparently load balances incoming connections across workers using the round-robin scheduling algorithm built into the Linux kernel.<\/p>\n<\/blockquote>\n
Pillar 3: Hardened Nginx Reverse Proxy & Static Asset Caching<\/h2>\n
Positioning Nginx in front of PM2 creates an enterprise-grade boundary between public clients and your Node.js application. Nginx handles SSL\/TLS termination using modern elliptic curve cryptography (ECDHE), negotiates HTTP\/2 multiplexing, buffers slow client uploads, and serves static files directly from NVMe storage with sub-millisecond latency.<\/p>\n
Because Next.js generates content-hashed filenames for all client bundles (e.g., main-4b1a8f9c.js<\/code>), static assets are immutable. By configuring Nginx to serve \/_next\/static\/<\/code> directly from disk with a 1-year cache-control header (Cache-Control: public, max-age=31536000, immutable<\/code>), over 90% of page asset requests never touch the Node.js runtime, dramatically lowering CPU load and memory pressure.<\/p>\n
Production \/etc\/nginx\/sites-available\/nextjs.conf Configuration:<\/strong><\/p>\n
# Upstream pool connecting to PM2 clustered Next.js instances\nupstream nextjs_upstream {\n    server 127.0.0.1:3000 max_fails=3 fail_timeout=10s;\n    keepalive 64; # Maintain persistent connection pool to eliminate TCP handshake latency\n}\n\n# Redirect HTTP to HTTPS\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# Primary HTTPS Production Server\nserver {\n    listen 443 ssl http2;\n    listen [::]:443 ssl http2;\n    server_name example.com www.example.com;\n\n    # SSL\/TLS 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;\n    ssl_prefer_server_ciphers off;\n    ssl_session_cache shared:SSL:10m;\n    ssl_session_timeout 1d;\n    ssl_session_tickets off;\n\n    # Security Headers\n    add_header X-Frame-Options \"SAMEORIGIN\" 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\n    # Root directory pointing to your Next.js application root\n    root \/var\/www\/nextjs-app;\n    client_max_body_size 25M;\n\n    # Gzip Compression Optimization\n    gzip on;\n    gzip_vary on;\n    gzip_proxied any;\n    gzip_comp_level 6;\n    gzip_types text\/plain text\/css text\/xml application\/json application\/javascript application\/rss+xml image\/svg+xml;\n\n    # 1. Direct Static Asset Offload: Next.js Immutable Bundles\n    location \/_next\/static\/ {\n        alias \/var\/www\/nextjs-app\/.next\/static\/;\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    # 2. Direct Static Asset Offload: Public Assets (Images, Favicons, Fonts)\n    location \/public\/ {\n        alias \/var\/www\/nextjs-app\/public\/;\n        access_log off;\n        expires 30d;\n        add_header Cache-Control \"public, max-age=2592000, must-revalidate\";\n        try_files $uri =404;\n    }\n\n    # 3. Dynamic SSR, API Routes, and Fallback Proxy\n    location \/ {\n        proxy_pass http:\/\/nextjs_upstream;\n        proxy_http_version 1.1;\n\n        # WebSocket and Upgrade Support\n        proxy_set_header Upgrade $http_upgrade;\n        proxy_set_header Connection \"upgrade\";\n\n        # Forwarded Client Headers\n        proxy_set_header Host $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        # Connection Keep-Alive and Timeouts\n        proxy_set_header Connection \"\";\n        proxy_connect_timeout 10s;\n        proxy_send_timeout 30s;\n        proxy_read_timeout 30s;\n        proxy_buffering on;\n        proxy_buffer_size 128k;\n        proxy_buffers 4 256k;\n        proxy_busy_buffers_size 256k;\n    }\n}<\/code><\/pre>\n
\n
Architecture Note:<\/strong> The proxy_set_header Connection \"\";<\/code> directive combined with proxy_http_version 1.1;<\/code> inside the dynamic location block is vital. By stripping the client Close<\/code> header and activating HTTP\/1.1 persistent connections, Nginx reuses established TCP sockets within the upstream nextjs_upstream<\/code> keepalive pool. This eliminates thousands of local TCP handshake and teardown operations per second, saving CPU overhead and preventing local ephemeral port exhaustion.<\/p>\n<\/blockquote>\n
Pillar 4: Linux Kernel Subsystem & TCP Network Stack Tuning<\/h2>\n
Default Linux kernel parameters on standard distributions like Ubuntu, Debian, or AlmaLinux are tuned for general-purpose desktop or low-density server workloads. Under sustained high-concurrency traffic (e.g., 2,000+ simultaneous WebSocket connections or concurrent SSR requests), the Linux networking stack will silently drop incoming TCP connection requests if the socket listen queue overflows. Tuning kernel socket limits, ephemeral port ranges, and file descriptors is essential for rock-solid stability.<\/p>\n
Production \/etc\/sysctl.d\/99-nextjs-tuning.conf Configuration:<\/strong><\/p>\n
# Increase maximum system-wide file descriptors\nfs.file-max = 2097152\n\n# Enlarge TCP socket listen backlog for high concurrency bursts\nnet.core.somaxconn = 65535\nnet.ipv4.tcp_max_syn_backlog = 65535\n\n# Expand ephemeral port range for outgoing proxy connections\nnet.ipv4.ip_local_port_range = 10240 65535\n\n# Enable rapid recycling of TIME_WAIT sockets to prevent port exhaustion\nnet.ipv4.tcp_tw_reuse = 1\nnet.ipv4.tcp_fin_timeout = 15\n\n# Optimize TCP window size and memory buffers\nnet.core.rmem_max = 16777216\nnet.core.wmem_max = 16777216\nnet.ipv4.tcp_rmem = 4096 87380 16777216\nnet.ipv4.tcp_wmem = 4096 65536 16777216\n\n# Reduce virtual memory swappiness to keep Node.js heaps in physical RAM\nvm.swappiness = 10<\/code><\/pre>\n
After saving the sysctl tuning parameters, activate them immediately into the live kernel without rebooting by executing: sudo sysctl --system<\/code>.<\/p>\n
Pillar 5: Zero-Downtime Deployment Automation Script<\/h2>\n
Executing a manual build on your live production directory causes catastrophic race conditions: while Next.js compiles, old build hashes are deleted and replaced, causing visitors to experience 404 errors on script chunks mid-browse. A hardened deployment pipeline builds the application in an isolated staging folder or build workspace, copies static assets into the standalone directory, executes an atomic symlink swap or filesync, and triggers a rolling pm2 reload<\/code>.<\/p>\n
Production \/var\/www\/deploy.sh Automation Script:<\/strong><\/p>\n
#!\/usr\/bin\/env bash\nset -euo pipefail\n\nAPP_DIR=\"\/var\/www\/nextjs-app\"\nLOG_PREFIX=\"[NextJS Deploy]\"\n\necho \"$LOG_PREFIX Starting production deployment sequence...\"\ncd \"$APP_DIR\"\n\n# 1. Pull latest production code from repository\necho \"$LOG_PREFIX Pulling latest commits from git...\"\ngit fetch origin main\ngit reset --hard origin\/main\n\n# 2. Install dependencies cleanly using lockfile\necho \"$LOG_PREFIX Installing production dependencies...\"\nnpm ci --prefer-offline --no-audit\n\n# 3. Compile optimized standalone Next.js build\necho \"$LOG_PREFIX Building application with standalone output...\"\nnpm run build\n\n# 4. Synchronize static bundles and public media to standalone directory\necho \"$LOG_PREFIX Copying public and static assets to standalone directory...\"\ncp -r public .next\/standalone\/public\ncp -r .next\/static .next\/standalone\/.next\/static\n\n# 5. Verify Nginx configuration syntax before reloading workers\necho \"$LOG_PREFIX Validating Nginx reverse proxy configuration...\"\nsudo nginx -t\n\n# 6. Execute graceful zero-downtime rolling reload via PM2\necho \"$LOG_PREFIX Executing zero-downtime PM2 reload...\"\npm2 reload ecosystem.config.cjs --update-env\n\n# 7. Post-deployment local health check verification\necho \"$LOG_PREFIX Verifying application health endpoint...\"\nsleep 3\nHEALTH_STATUS=$(curl -s -o \/dev\/null -w \"%{http_code}\" http:\/\/127.0.0.1:3000\/api\/health || true)\n\nif [ \"$HEALTH_STATUS\" -eq 200 ]; then\n    echo \"$LOG_PREFIX Deployment SUCCEEDED: Health check returned HTTP 200.\"\n    pm2 save\nelse\n    echo \"$LOG_PREFIX WARNING: Health check returned status $HEALTH_STATUS. Check PM2 logs!\"\n    exit 1\nfi<\/code><\/pre>\n
Systemd Service Survival: Ensuring Boot Persistence<\/h2>\n
A production server reboot due to routine kernel updates or hypervisor maintenance must not take your web service offline permanently. PM2 provides seamless integration with the Linux systemd<\/code> init system. Once your ecosystem configuration is actively running in PM2, generate and register the systemd service hook by executing:<\/p>\n
# Generate and install PM2 systemd boot unit\npm2 startup systemd -u www-data --hp \/var\/www\n\n# Save the active process list to persistent state\npm2 save\n\n# Verify systemd service status\nsudo systemctl status pm2-www-data<\/code><\/pre>\n
By binding PM2 to the unprivileged www-data<\/code> user, you adhere to the principle of least privilege, preventing potential remote code execution vulnerabilities in third-party npm packages from compromising the Linux host root account.<\/p>\n
Transitioning from Staging to Mission-Critical Cloud Infrastructure<\/h2>\n
While initial testing, architectural prototyping, and CI\/CD dry runs thrive on cost-effective sandbox environments like CpanelFree<\/a>, enterprise-grade e-commerce platforms, mission-critical SaaS applications, and high-throughput Next.js backends require hardware with guaranteed CPU allocation, pure NVMe storage I\/O, and absolute pricing stability.<\/p>\n
When your application demands dedicated compute threads, sustained high-bandwidth low-latency networking, and an uncompromising SLA, deploying your clustered PM2 and Nginx stack on MeraHost Enterprise Cloud<\/a> delivers enterprise-grade performance. With pure Enterprise NVMe drives, LiteSpeed acceleration, and their industry-renowned policy of Same Renewal Price, Always (starting at just \u20b999\/mo), MeraHost ensures your infrastructure costs never skyrocket after the initial billing cycle.<\/p>\n
Frequently Asked Questions (FAQs)<\/h2>\n
\nWhy is PM2 cluster mode better than running multiple PM2 fork instances on different ports?<\/summary>\n
PM2 cluster mode leverages the native Node.js cluster<\/code> module, which binds multiple worker processes to a single network port (e.g., 3000) using Linux kernel socket sharing. In fork mode, each instance requires a unique port, forcing you to manually configure complex Nginx upstream blocks with individual port numbers. Cluster mode simplifies routing, balances workload evenly across all CPU cores, and enables seamless rolling reloads without port conflict errors.<\/p>\n<\/details>\n
\nHow do I prevent 502 Bad Gateway errors during pm2 reload?<\/summary>\n
502 errors occur when PM2 terminates old workers before new workers have finished initializing. To eliminate this issue, configure wait_ready: true<\/code> and listen_timeout: 10000<\/code> in your ecosystem.config.cjs<\/code>. Additionally, configure Nginx with proxy_next_upstream error timeout http_502 http_503;<\/code> so that if a worker takes longer to respond during reload, Nginx automatically retries the request against another active worker in the upstream pool.<\/p>\n<\/details>\n
\nWhy does Next.js standalone build require manually copying the public and .next\/static folders?<\/summary>\n
Next.js standalone builds are designed to create minimal portable bundles that trace only server-side JavaScript dependencies. Client-side static bundles (.next\/static<\/code>) and public files (public\/<\/code>) are decoupled so they can be offloaded directly to a reverse proxy (like Nginx) or a CDN. Copying them into the standalone directory ensures that both direct Nginx static alias directives and fallback server routes find the required assets without hydration errors.<\/p>\n<\/details>\n
\nHow much RAM does a clustered Next.js deployment require on a Linux VPS?<\/summary>\n
Each Next.js standalone worker process typically consumes between 120MB and 250MB of resident memory (RSS) under baseline SSR workloads. On a 2-core VPS running 2 PM2 cluster instances alongside Nginx and system services, 2GB of RAM is recommended. Setting max_memory_restart: '1024M'<\/code> in your PM2 config ensures that any memory leaks are automatically resolved by recycling workers individually without impacting service availability.<\/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","protected":false},"excerpt":{"rendered":"
Learn how to deploy Next.js and Node.js on a Linux VPS with PM2 cluster mode, Nginx reverse proxy, and zero-downtime reloads. Step-by-step production configs.<\/p>\n","protected":false},"author":1,"featured_media":5134,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[57,177,87,73,101],"class_list":["post-5135","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web-hosting","tag-almalinux","tag-databases-performance","tag-devops","tag-free-web-hosting","tag-sysadmin"],"_links":{"self":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts\/5135","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/comments?post=5135"}],"version-history":[{"count":0,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts\/5135\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/media\/5134"}],"wp:attachment":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/media?parent=5135"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/categories?post=5135"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/tags?post=5135"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}