{"id":3613,"date":"2025-12-28T18:37:42","date_gmt":"2025-12-28T15:37:42","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/how-websockets-and-real-time-apps-really-work\/"},"modified":"2025-12-28T18:37:42","modified_gmt":"2025-12-28T15:37:42","slug":"how-websockets-and-real-time-apps-really-work","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/how-websockets-and-real-time-apps-really-work\/","title":{"rendered":"How WebSockets and Real\u2011Time Apps Really Work"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>{<br \/>\n  &#8220;title&#8221;: &#8220;Hosting WebSocket and Real\u2011Time Apps on Shared Hosting and VPS&#8221;,<br \/>\n  &#8220;content&#8221;: &#8220;<\/p>\n<p>WebSocket and real\u2011time features are no longer reserved for giant social networks. Chat widgets, live order dashboards, in\u2011app notifications, collaborative editors, trading panels, and multiplayer games are now common even on small business and SaaS projects. When you add Node.js, Laravel Echo and Socket.io into the mix, the hosting question appears immediately: <strong>can this run on shared hosting, or do you really need a <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>?<\/strong><\/p>\n<p>In this article, we look at the problem exactly as we do when advising dchost.com customers. We will walk through how WebSockets actually work, which limitations you hit on typical shared hosting, how a VPS changes the picture, and concrete architectures for Node.js, Laravel Echo and Socket.io. You will see realistic patterns: from \u201cI only have cPanel\u201d to \u201cI\u2019m ready to run reverse proxies, queues and Redis on a VPS.\u201d By the end, you should be able to choose the right platform, size it properly, and deploy a secure, stable real\u2011time stack without surprises.<\/p>\n<p>To choose the right hosting, it helps to understand what makes WebSockets different from normal HTTP.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><ul><li><a href=\"#HTTP_vs_WebSocket_in_simple_terms\"><span class=\"toc_number toc_depth_2\">0.1<\/span> HTTP vs WebSocket in simple terms<\/a><\/li><li><a href=\"#Where_Nodejs_Laravel_Echo_and_Socketio_fit\"><span class=\"toc_number toc_depth_2\">0.2<\/span> Where Node.js, Laravel Echo and Socket.io fit<\/a><\/li><\/ul><\/li><li><a href=\"#Shared_Hosting_vs_VPS_for_WebSocket_and_RealTime_Workloads\"><span class=\"toc_number toc_depth_1\">1<\/span> Shared Hosting vs VPS for WebSocket and Real\u2011Time Workloads<\/a><ul><li><a href=\"#Constraints_of_typical_shared_hosting\"><span class=\"toc_number toc_depth_2\">1.1<\/span> Constraints of typical shared hosting<\/a><\/li><li><a href=\"#What_shared_hosting_is_still_good_for\"><span class=\"toc_number toc_depth_2\">1.2<\/span> What shared hosting is still good for<\/a><\/li><li><a href=\"#What_changes_when_you_move_to_a_VPS\"><span class=\"toc_number toc_depth_2\">1.3<\/span> What changes when you move to a VPS<\/a><\/li><\/ul><\/li><li><a href=\"#Architecture_Patterns_for_Nodejs_Laravel_Echo_and_Socketio\"><span class=\"toc_number toc_depth_1\">2<\/span> Architecture Patterns for Node.js, Laravel Echo and Socket.io<\/a><ul><li><a href=\"#Pattern_1_Everything_on_one_VPS\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Pattern 1: Everything on one VPS<\/a><\/li><li><a href=\"#Pattern_2_Shared_hosting_for_Laravel_VPS_for_realtime\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Pattern 2: Shared hosting for Laravel, VPS for real\u2011time<\/a><\/li><li><a href=\"#Pattern_3_Full_Nodejs_stack_with_Laravel_only_as_API\"><span class=\"toc_number toc_depth_2\">2.3<\/span> Pattern 3: Full Node.js stack with Laravel only as API<\/a><\/li><\/ul><\/li><li><a href=\"#Running_WebSockets_on_Shared_Hosting_What_Is_Actually_Possible\"><span class=\"toc_number toc_depth_1\">3<\/span> Running WebSockets on Shared Hosting: What Is Actually Possible?<\/a><ul><li><a href=\"#Option_1_Simulate_realtime_without_WebSockets\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Option 1: Simulate \u201creal\u2011time\u201d without WebSockets<\/a><\/li><li><a href=\"#Option_2_Use_an_external_realtime_service\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Option 2: Use an external real\u2011time service<\/a><\/li><li><a href=\"#Option_3_Move_only_the_WebSocket_piece_to_a_VPS\"><span class=\"toc_number toc_depth_2\">3.3<\/span> Option 3: Move only the WebSocket piece to a VPS<\/a><\/li><\/ul><\/li><li><a href=\"#Setting_Up_WebSockets_on_a_VPS_A_Practical_Blueprint\"><span class=\"toc_number toc_depth_1\">4<\/span> Setting Up WebSockets on a VPS: A Practical Blueprint<\/a><ul><li><a href=\"#Step_1_Basic_server_hardening_and_web_stack\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Step 1: Basic server hardening and web stack<\/a><\/li><li><a href=\"#Step_2_Install_Nodejs_and_your_WebSocket_server\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Step 2: Install Node.js and your WebSocket server<\/a><\/li><li><a href=\"#Step_3_Configure_Laravel_broadcasting\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Step 3: Configure Laravel broadcasting<\/a><\/li><li><a href=\"#Step_4_Nginx_reverse_proxy_for_WebSockets\"><span class=\"toc_number toc_depth_2\">4.4<\/span> Step 4: Nginx reverse proxy for WebSockets<\/a><\/li><li><a href=\"#Step_5_Frontend_configuration_Laravel_Echo_Socketio_client\"><span class=\"toc_number toc_depth_2\">4.5<\/span> Step 5: Frontend configuration (Laravel Echo \/ Socket.io client)<\/a><\/li><\/ul><\/li><li><a href=\"#Performance_Scaling_and_Resource_Planning_for_RealTime_Apps\"><span class=\"toc_number toc_depth_1\">5<\/span> Performance, Scaling and Resource Planning for Real\u2011Time Apps<\/a><ul><li><a href=\"#Key_resource_dimensions\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Key resource dimensions<\/a><\/li><li><a href=\"#Connection_counts_and_limits\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Connection counts and limits<\/a><\/li><li><a href=\"#Measure_before_guessing\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Measure before guessing<\/a><\/li><\/ul><\/li><li><a href=\"#Security_and_Reliability_Checklist_for_WebSocket_Hosting\"><span class=\"toc_number toc_depth_1\">6<\/span> Security and Reliability Checklist for WebSocket Hosting<\/a><ul><li><a href=\"#1_Use_TLS_everywhere\"><span class=\"toc_number toc_depth_2\">6.1<\/span> 1. Use TLS everywhere<\/a><\/li><li><a href=\"#2_Strict_authentication_and_authorization\"><span class=\"toc_number toc_depth_2\">6.2<\/span> 2. Strict authentication and authorization<\/a><\/li><li><a href=\"#3_Rate_limiting_and_abuse_protection\"><span class=\"toc_number toc_depth_2\">6.3<\/span> 3. Rate limiting and abuse protection<\/a><\/li><li><a href=\"#4_Robust_process_supervision_and_logging\"><span class=\"toc_number toc_depth_2\">6.4<\/span> 4. Robust process supervision and logging<\/a><\/li><li><a href=\"#5_Plan_for_graceful_deploys\"><span class=\"toc_number toc_depth_2\">6.5<\/span> 5. Plan for graceful deploys<\/a><\/li><\/ul><\/li><li><a href=\"#Conclusion_Choosing_the_Right_Home_for_Your_RealTime_App\"><span class=\"toc_number toc_depth_1\">7<\/span> Conclusion: Choosing the Right Home for Your Real\u2011Time App<\/a><\/li><\/ul><\/div>\n<h3><span id=\"HTTP_vs_WebSocket_in_simple_terms\">HTTP vs WebSocket in simple terms<\/span><\/h3>\n<p>Traditional HTTP is <strong>request\/response<\/strong> based. The browser opens a connection, asks for a page or API response, receives it, and then the connection is usually closed. For anything live (chat, notifications, counters), we used to rely on tricks like:<\/p>\n<ul>\n<li><strong>Short polling:<\/strong> The browser hits an endpoint every few seconds.<\/li>\n<li><strong>Long polling:<\/strong> The server keeps the request open until there is new data.<\/li>\n<li><strong>Server\u2011Sent Events (SSE):<\/strong> A one\u2011way stream from server to browser.<\/li>\n<\/ul>\n<p>WebSocket is different. After an initial HTTP handshake, the connection <strong>upgrades<\/strong> to a persistent, full\u2011duplex TCP channel. Browser and server can push data to each other at any time without reopening connections.<\/p>\n<p>For real\u2011time apps, that means:<\/p>\n<ul>\n<li>Fewer connection setups (less overhead).<\/li>\n<li>Lower latency once the socket is open.<\/li>\n<li>Ability to push events to large numbers of online users simultaneously.<\/li>\n<\/ul>\n<h3><span id=\"Where_Nodejs_Laravel_Echo_and_Socketio_fit\">Where Node.js, Laravel Echo and Socket.io fit<\/span><\/h3>\n<p>In many stacks we see at dchost.com, the roles are roughly:<\/p>\n<ul>\n<li><strong>Laravel (PHP):<\/strong> Main application, APIs, authentication, database operations.<\/li>\n<li><strong>Broadcasting layer:<\/strong> Laravel broadcasting events to Redis or directly to a WebSocket server.<\/li>\n<li><strong>Laravel Echo:<\/strong> JavaScript client that subscribes to channels and listens for broadcast events.<\/li>\n<li><strong>Socket.io server:<\/strong> Usually written in Node.js, handles WebSocket (and fallbacks) and manages rooms\/channels, presence, etc.<\/li>\n<\/ul>\n<p>You can also build everything purely in Node.js (Express + Socket.io or NestJS + WebSockets), but Laravel + Node.js is extremely common in our customers\u2019 projects.<\/p>\n<h2><span id=\"Shared_Hosting_vs_VPS_for_WebSocket_and_RealTime_Workloads\">Shared Hosting vs VPS for WebSocket and Real\u2011Time Workloads<\/span><\/h2>\n<p>Most developers first encounter WebSockets while already running on shared hosting. The natural question is: \u201cCan I just turn on WebSockets here?\u201d The honest answer is: <strong>it depends on what your shared hosting plan actually allows<\/strong>, but there are hard limits you should know.<\/p>\n<h3><span id=\"Constraints_of_typical_shared_hosting\">Constraints of typical shared hosting<\/span><\/h3>\n<p>On classic shared hosting with cPanel or DirectAdmin, the provider usually gives you:<\/p>\n<ul>\n<li>PHP (often with multiple versions).<\/li>\n<li>Apache or LiteSpeed as the main web server.<\/li>\n<li>MySQL\/MariaDB as the database.<\/li>\n<li>Process limits (no long\u2011running custom daemons).<\/li>\n<li>No ability to bind to arbitrary ports (like 3000, 6001).<\/li>\n<\/ul>\n<p>WebSockets require a <strong>long\u2011running process<\/strong> (Node.js or a dedicated WebSocket server) that keeps TCP connections open. On typical shared hosting, you cannot just start a custom Node.js script and keep it running forever, because:<\/p>\n<ul>\n<li>The platform kills background processes that exceed resource limits.<\/li>\n<li>You do not control the global firewall or listening ports.<\/li>\n<li>You cannot easily configure a reverse proxy (Nginx) to forward <code>wss:\/\/<\/code> traffic.<\/li>\n<\/ul>\n<p>There are some shared hosting platforms with integrated Node.js support, but even then you often have strict limits on memory, CPU and concurrent connections. For anything beyond a demo\u2011level real\u2011time app, this becomes a bottleneck fast.<\/p>\n<h3><span id=\"What_shared_hosting_is_still_good_for\">What shared hosting is still good for<\/span><\/h3>\n<p>Shared hosting is still perfectly fine for:<\/p>\n<ul>\n<li>Your <strong>main PHP\/Laravel site<\/strong> and classic HTTP APIs.<\/li>\n<li><strong>Simple real\u2011time\u2011like features<\/strong> implemented via AJAX polling or SSE, where latency of a few seconds is acceptable.<\/li>\n<li>Using an <strong>external real\u2011time platform<\/strong> (a hosted WebSocket\/broadcasting SaaS) via HTTP APIs from your PHP app.<\/li>\n<\/ul>\n<p>If you are interested in a deeper PHP framework comparison on shared environments, we wrote a detailed guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/laravel-ve-diger-php-frameworkler-icin-paylasimli-hosting-mi-vps-mi\/\">choosing between shared hosting and VPS for Laravel and other PHP frameworks<\/a>. Many of the same trade\u2011offs apply directly to real\u2011time workloads.<\/p>\n<h3><span id=\"What_changes_when_you_move_to_a_VPS\">What changes when you move to a VPS<\/span><\/h3>\n<p>On a VPS from dchost.com you get:<\/p>\n<ul>\n<li>Root (or sudo) access to install Node.js, Redis, queue workers, supervisors.<\/li>\n<li>Full control over ports and firewall (e.g. 80\/443 for HTTP(S), 6001 for Laravel Echo, 3000 for Socket.io).<\/li>\n<li>The ability to run long\u2011lived processes using <strong>systemd<\/strong> or <strong>PM2<\/strong>.<\/li>\n<li>Freedom to configure <strong>Nginx or Apache as a reverse proxy<\/strong> to terminate TLS and forward <code>wss:\/\/<\/code> traffic to your WebSocket processes.<\/li>\n<\/ul>\n<p>At that point, you are building a small \u201creal\u201d backend architecture, not just uploading PHP files. If you want a step\u2011by\u2011step look at what that feels like in production, we documented it in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/node-jsi-canliya-alirken-panik-yapma-pm2-systemd-nginx-ssl-ve-sifir-kesinti-deploy-nasil-kurulur\/\">hosting Node.js in production with PM2, Nginx, SSL and zero\u2011downtime deploys<\/a>.<\/p>\n<p>For a typical chat or notification system, a small VPS (1\u20132 vCPU, 2\u20134 GB RAM) is usually enough to get started. In our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/woocommerce-laravel-ve-node-jsde-dogru-vps-kaynaklarini-nasil-secersin-cpu-ram-nvme-ve-bant-genisligi-rehberi\/\">choosing VPS specs for WooCommerce, Laravel and Node.js<\/a>, we go deeper into sizing CPU, RAM and storage for application servers; the same logic applies to WebSocket workloads.<\/p>\n<h2><span id=\"Architecture_Patterns_for_Nodejs_Laravel_Echo_and_Socketio\">Architecture Patterns for Node.js, Laravel Echo and Socket.io<\/span><\/h2>\n<p>Let\u2019s look at practical architectures we often see on dchost.com infrastructure, from simplest to more advanced.<\/p>\n<h3><span id=\"Pattern_1_Everything_on_one_VPS\">Pattern 1: Everything on one VPS<\/span><\/h3>\n<p>This is the most common pattern for small to medium projects:<\/p>\n<ul>\n<li><strong>Nginx (or Apache)<\/strong> on port 80\/443 as the public entry point.<\/li>\n<li><strong>PHP\u2011FPM<\/strong> for Laravel on a local socket or port (e.g. 127.0.0.1:9000).<\/li>\n<li><strong>MySQL\/MariaDB<\/strong> on the same VPS (or a separate database VPS later).<\/li>\n<li><strong>Redis<\/strong> for cache + broadcasting (optional but recommended).<\/li>\n<li><strong>Node.js<\/strong> running:\n<ul>\n<li>A Laravel Echo Server (<code>laravel-echo-server<\/code> package) or<\/li>\n<li>A custom Socket.io server (e.g. <code>server.js<\/code>).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Nginx handles HTTPS and reverse proxies specific paths or subdomains to the Node.js WebSocket server:<\/p>\n<ul>\n<li><code>https:\/\/example.com<\/code> \u2192 Laravel (PHP\u2011FPM)<\/li>\n<li><code>wss:\/\/ws.example.com<\/code> \u2192 Node.js + Socket.io<\/li>\n<\/ul>\n<p>This keeps operations relatively simple: one VPS, one firewall, one set of backups and monitoring. It is a great starting point for internal tools, SaaS MVPs, and moderate\u2011traffic sites.<\/p>\n<h3><span id=\"Pattern_2_Shared_hosting_for_Laravel_VPS_for_realtime\">Pattern 2: Shared hosting for Laravel, VPS for real\u2011time<\/span><\/h3>\n<p>If you already have a stable Laravel application on shared hosting and want to add WebSockets without migrating everything, a practical compromise is:<\/p>\n<ul>\n<li>Keep the <strong>Laravel app<\/strong> and database where they are (shared hosting).<\/li>\n<li>Provision a <strong>small VPS<\/strong> for the Node.js WebSocket server (and optionally Redis).<\/li>\n<li>Configure Laravel broadcasting to point to this external WebSocket server.<\/li>\n<li>Expose a subdomain like <code>ws.example.com<\/code> that points to the VPS IP (via DNS A\/AAAA records).<\/li>\n<\/ul>\n<p>The WebSocket traffic (and associated CPU\/ RAM usage) is isolated on the VPS, while your shared hosting plan continues serving normal HTTP. You still have to solve authentication and CORS carefully, but it reduces the risk and cost of a full migration on day one.<\/p>\n<h3><span id=\"Pattern_3_Full_Nodejs_stack_with_Laravel_only_as_API\">Pattern 3: Full Node.js stack with Laravel only as API<\/span><\/h3>\n<p>On some projects, teams move more and more logic into Node.js (React\/Vue\/Next.js frontend + Node APIs + Socket.io), while Laravel remains as legacy or for certain admin interfaces. In that case, you can:<\/p>\n<ul>\n<li>Expose a single entry point (e.g. <code>app.example.com<\/code>) handled by Node.js + Socket.io.<\/li>\n<li>Use Laravel as a <strong>separate API<\/strong> on another subdomain (e.g. <code>api.example.com<\/code>).<\/li>\n<li>Share auth via JWTs or OAuth2 between both worlds.<\/li>\n<\/ul>\n<p>From the hosting side, this looks more like a classic Node.js SaaS architecture and benefits strongly from the practices we detail in <a href=\"https:\/\/www.dchost.com\/blog\/en\/node-js-uygulamalarini-nerede-host-etmeli-cpanel-paylasimli-hosting-ve-vps-karsilastirmasi\/\">our comparison of where to host Node.js apps: cPanel, shared hosting or VPS<\/a>.<\/p>\n<h2><span id=\"Running_WebSockets_on_Shared_Hosting_What_Is_Actually_Possible\">Running WebSockets on Shared Hosting: What Is Actually Possible?<\/span><\/h2>\n<p>Given these patterns, what can you realistically do if you are <strong>stuck on shared hosting<\/strong> for now?<\/p>\n<h3><span id=\"Option_1_Simulate_realtime_without_WebSockets\">Option 1: Simulate \u201creal\u2011time\u201d without WebSockets<\/span><\/h3>\n<p>If your use case is not ultra\u2011latency\u2011sensitive, you can often get away with:<\/p>\n<ul>\n<li><strong>Short polling:<\/strong> JavaScript hitting an endpoint every 3\u20135 seconds for new messages or notifications.<\/li>\n<li><strong>Long polling:<\/strong> PHP script that holds the HTTP connection open for up to 30 seconds and returns as soon as there is new data.<\/li>\n<li><strong>Server\u2011Sent Events (SSE):<\/strong> If your host allows streaming responses, SSE provides a one\u2011way push channel from server to browser.<\/li>\n<\/ul>\n<p>This approach is easier to host on shared plans because you are not running a separate daemon. However, it has downsides: higher overhead, more database queries and limited scalability. At a certain traffic level, the economics of a small VPS quickly look better.<\/p>\n<h3><span id=\"Option_2_Use_an_external_realtime_service\">Option 2: Use an external real\u2011time service<\/span><\/h3>\n<p>Another pattern is to use a <strong>third\u2011party real\u2011time platform<\/strong> (a hosted WebSocket\/broadcasting SaaS) that provides:<\/p>\n<ul>\n<li>A WebSocket endpoint your frontend can connect to.<\/li>\n<li>HTTP APIs your PHP\/Laravel app can call to publish events.<\/li>\n<li>SDKs for presence channels, private channels, etc.<\/li>\n<\/ul>\n<p>Here, your shared hosting remains responsible for page rendering and business logic, while the heavy lifting of managing persistent connections and scaling WebSockets is outsourced. This can be a good intermediate step before investing in your own VPS stack.<\/p>\n<h3><span id=\"Option_3_Move_only_the_WebSocket_piece_to_a_VPS\">Option 3: Move only the WebSocket piece to a VPS<\/span><\/h3>\n<p>As described earlier, you can keep Laravel on shared hosting and create a small Node.js + Redis stack on a VPS to act as the broadcasting and WebSocket layer. This is often the most cost\u2011effective upgrade path when teams hit the limitations of pure shared hosting.<\/p>\n<h2><span id=\"Setting_Up_WebSockets_on_a_VPS_A_Practical_Blueprint\">Setting Up WebSockets on a VPS: A Practical Blueprint<\/span><\/h2>\n<p>Let\u2019s walk through a realistic deployment on a dchost.com VPS. We will assume:<\/p>\n<ul>\n<li>Ubuntu or Debian\u2011based Linux on the VPS.<\/li>\n<li>Nginx as reverse proxy.<\/li>\n<li>Laravel app (PHP\u2011FPM) and Node.js on the same machine.<\/li>\n<\/ul>\n<h3><span id=\"Step_1_Basic_server_hardening_and_web_stack\">Step 1: Basic server hardening and web stack<\/span><\/h3>\n<p>Before touching WebSockets, prepare the VPS properly:<\/p>\n<ol>\n<li>Update packages and enable automatic security updates.<\/li>\n<li>Configure a firewall (e.g. <code>ufw<\/code> or <code>iptables<\/code>) to allow only required ports (22, 80, 443, plus your WebSocket port if exposed directly).<\/li>\n<li>Install Nginx, PHP\u2011FPM and your database.<\/li>\n<\/ol>\n<p>If you want a structured checklist for initial VPS hardening, our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-guvenlik-sertlestirme-kontrol-listesi-sshd_config-fail2ban-ve-root-erisimini-kapatmak\/\">VPS security hardening (sshd_config, Fail2ban, disabling direct root)<\/a> is a good reference. Investing in this early saves a lot of trouble later.<\/p>\n<h3><span id=\"Step_2_Install_Nodejs_and_your_WebSocket_server\">Step 2: Install Node.js and your WebSocket server<\/span><\/h3>\n<p>On the VPS, install Node.js from the official repositories or a Node version manager. Then:<\/p>\n<ul>\n<li>For <strong>Laravel Echo Server<\/strong>: install the <code>laravel-echo-server<\/code> package globally or in your project and create a config file (typically <code>laravel-echo-server.json<\/code>).<\/li>\n<li>For a <strong>custom Socket.io server<\/strong>: initialize a Node project and create e.g. <code>server.js<\/code> that sets up an HTTP server and attaches Socket.io.<\/li>\n<\/ul>\n<p>Run the server on a local port, for example:<\/p>\n<ul>\n<li>Laravel Echo Server on <code>127.0.0.1:6001<\/code><\/li>\n<li>Custom Socket.io server on <code>127.0.0.1:3000<\/code><\/li>\n<\/ul>\n<p>Then configure <strong>systemd units or PM2<\/strong> to keep these processes alive, restart on failure and start at boot. Our Node.js production guide shows concrete examples of both approaches.<\/p>\n<h3><span id=\"Step_3_Configure_Laravel_broadcasting\">Step 3: Configure Laravel broadcasting<\/span><\/h3>\n<p>In your Laravel app:<\/p>\n<ol>\n<li>Set <code>BROADCAST_DRIVER<\/code> in <code>.env<\/code> to <code>redis<\/code>, <code>pusher<\/code> or a custom driver that talks to your Node.js Socket.io server.<\/li>\n<li>If using Redis, configure Redis host\/port in <code>.env<\/code> and set up the Redis server on the same VPS (or another internal instance).<\/li>\n<li>Define broadcast channels in <code>routes\/channels.php<\/code> and implement authorization callbacks.<\/li>\n<\/ol>\n<p>Now when your application fires events (e.g. <code>event(new MessageSent($message))<\/code>), Laravel will push them to Redis or directly to your WebSocket server, which then forwards them to connected clients via Laravel Echo or a Socket.io client.<\/p>\n<h3><span id=\"Step_4_Nginx_reverse_proxy_for_WebSockets\">Step 4: Nginx reverse proxy for WebSockets<\/span><\/h3>\n<p>Most browsers talk WebSockets over <code>wss:\/\/<\/code> (WebSocket over TLS). A common, clean pattern is:<\/p>\n<ul>\n<li>Terminate TLS at Nginx (port 443).<\/li>\n<li>Forward specific paths or hostnames to the internal Node.js process.<\/li>\n<\/ul>\n<p>For example, if your Socket.io server listens on <code>127.0.0.1:3000<\/code> and you want it served at <code>wss:\/\/ws.example.com\/socket.io\/<\/code>, your Nginx server block might roughly contain:<\/p>\n<pre>&lt;code&gt;server {n    listen 443 ssl http2;n    server_name ws.example.com;nn    ssl_certificate     \/etc\/ssl\/certs\/your.crt;n    ssl_certificate_key \/etc\/ssl\/private\/your.key;nn    location \/socket.io\/ {n        proxy_pass http:\/\/127.0.0.1:3000;nn        proxy_http_version 1.1;n        proxy_set_header Upgrade $http_upgrade;n        proxy_set_header Connection \"upgrade\";n        proxy_set_header Host $host;nn        proxy_read_timeout 60s;n        proxy_send_timeout 60s;n    }n}&lt;\/code&gt;<\/pre>\n<p>This ensures the Upgrade header and connection are preserved so Socket.io can upgrade the HTTP request to WebSocket.<\/p>\n<p>If you plan to put Cloudflare or another CDN in front of your site, pay attention to their WebSocket support and timeout limits. We have a dedicated article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/cloudflare-ile-websocket-ve-grpc-yayini-nasil-hep-canli-kalir-nginx-timeout-keep%e2%80%91alive-ve-kesintisiz-dagitimin-sirlari\/\">keeping WebSockets and gRPC happy behind Cloudflare with correct Nginx timeouts and keep\u2011alive settings<\/a>, which applies directly here.<\/p>\n<h3><span id=\"Step_5_Frontend_configuration_Laravel_Echo_Socketio_client\">Step 5: Frontend configuration (Laravel Echo \/ Socket.io client)<\/span><\/h3>\n<p>On the frontend, you typically:<\/p>\n<ul>\n<li>Install Laravel Echo and the Socket.io client via npm\/yarn.<\/li>\n<li>Initialize Echo with the correct broadcaster and host\/port settings.<\/li>\n<li>Join channels and listen for events that match your Laravel broadcast names.<\/li>\n<\/ul>\n<p>Example (simplified):<\/p>\n<pre>&lt;code&gt;import Echo from 'laravel-echo';nimport io from 'socket.io-client';nnwindow.io = io;nnwindow.Echo = new Echo({n    broadcaster: 'socket.io',n    host: 'ws.example.com',n    transports: ['websocket', 'polling'],n});nnwindow.Echo.private('chat.1')n    .listen('MessageSent', (e) =&gt; {n        console.log('New message', e.message);n    });&lt;\/code&gt;<\/pre>\n<p>Make sure the host and protocol (wss vs ws) align with your Nginx configuration and TLS setup.<\/p>\n<h2><span id=\"Performance_Scaling_and_Resource_Planning_for_RealTime_Apps\">Performance, Scaling and Resource Planning for Real\u2011Time Apps<\/span><\/h2>\n<p>WebSockets change the resource profile of your server. Instead of lots of short\u2011lived HTTP requests, you now have <strong>many concurrent open connections<\/strong>. That affects how you size and tune your VPS.<\/p>\n<h3><span id=\"Key_resource_dimensions\">Key resource dimensions<\/span><\/h3>\n<ul>\n<li><strong>vCPU:<\/strong> Message fan\u2011out, JSON encoding\/decoding, business logic in Node\/Laravel all use CPU. For simple chat\/notification workloads, 1\u20132 vCPU is often fine to start.<\/li>\n<li><strong>RAM:<\/strong> Each WebSocket connection consumes memory in the Node process and in system buffers. Add room for Redis and PHP\u2011FPM processes.<\/li>\n<li><strong>Network bandwidth and latency:<\/strong> Real\u2011time apps are sensitive to jitter. Hosting closer to your main user base and choosing NVMe\u2011backed VPS storage (for database and Redis) improves overall responsiveness. Our <a href=\"https:\/\/www.dchost.com\/blog\/en\/nvme-vps-hosting-rehberi-hizin-nereden-geldigini-nasil-olculdugunu-ve-gercek-sonuclari-beraber-gorelim\/\">NVMe VPS hosting guide<\/a> explains why fast disk I\/O still matters even for seemingly \u201cin\u2011memory\u201d workloads.<\/li>\n<\/ul>\n<h3><span id=\"Connection_counts_and_limits\">Connection counts and limits<\/span><\/h3>\n<p>A small VPS can handle surprisingly many idle WebSocket connections (thousands) as long as message throughput is modest. Bottlenecks tend to be:<\/p>\n<ul>\n<li>Per\u2011process file descriptor limits.<\/li>\n<li>Kernel networking buffers (e.g. <code>net.core.somaxconn<\/code>, <code>net.ipv4.tcp_max_syn_backlog<\/code>).<\/li>\n<li>Application\u2011level broadcast patterns (e.g. broadcasting to 10,000 clients on every keystroke).<\/li>\n<\/ul>\n<p>As your app grows, you can:<\/p>\n<ul>\n<li>Use <strong>Redis or another message bus<\/strong> and Socket.io\u2019s Redis adapter to scale horizontally across multiple Node.js instances.<\/li>\n<li>Separate the <strong>database<\/strong> and <strong>WebSocket servers<\/strong> onto different VPS plans to avoid resource contention.<\/li>\n<li>Introduce <strong>rate limiting and debouncing<\/strong> for chat typing indicators, presence updates, etc.<\/li>\n<\/ul>\n<h3><span id=\"Measure_before_guessing\">Measure before guessing<\/span><\/h3>\n<p>Don\u2019t rely only on \u201cfeels fast\u201d. Use load testing tools (k6, Locust, custom scripts) to simulate concurrent users and message bursts. We cover this style of validation in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/trafik-patlamasindan-once-load-test-yapmak-k6-jmeter-ve-locust-ile-kapasite-olcme-rehberi\/\">load testing your hosting before real traffic spikes<\/a>. The same discipline applies to WebSocket apps: test join\/leave rates, broadcast storms and reconnect behaviour.<\/p>\n<h2><span id=\"Security_and_Reliability_Checklist_for_WebSocket_Hosting\">Security and Reliability Checklist for WebSocket Hosting<\/span><\/h2>\n<p>Persistent connections bring persistent attack surfaces. Here are practical measures we recommend to dchost.com customers deploying real\u2011time stacks.<\/p>\n<h3><span id=\"1_Use_TLS_everywhere\">1. Use TLS everywhere<\/span><\/h3>\n<p>Always serve WebSockets as <code>wss:\/\/<\/code> behind HTTPS. This protects session cookies, auth tokens and message content from sniffing. Modern browsers also block insecure WebSockets from secure pages, so <code>ws:\/\/<\/code> is not an option in production.<\/p>\n<h3><span id=\"2_Strict_authentication_and_authorization\">2. Strict authentication and authorization<\/span><\/h3>\n<ul>\n<li>Use Laravel\u2019s built\u2011in <strong>private and presence channels<\/strong> for per\u2011user\/per\u2011room access control.<\/li>\n<li>Ensure the WebSocket server <strong>verifies auth tokens<\/strong> on connection and when joining channels.<\/li>\n<li>Expire tokens and handle revoked sessions (e.g. after password change).<\/li>\n<\/ul>\n<h3><span id=\"3_Rate_limiting_and_abuse_protection\">3. Rate limiting and abuse protection<\/span><\/h3>\n<p>WebSockets can be abused by:<\/p>\n<ul>\n<li>Opening many concurrent connections from the same IP.<\/li>\n<li>Flooding the server with messages.<\/li>\n<li>Attempting to brute\u2011force channel names or auth tokens.<\/li>\n<\/ul>\n<p>Defences include:<\/p>\n<ul>\n<li>IP\u2011based connection limits in your Node.js server.<\/li>\n<li>Application\u2011level throttling (e.g. one message per N milliseconds per user).<\/li>\n<li>Network\u2011level protections and WAF rules on the HTTP handshake endpoints.<\/li>\n<\/ul>\n<p>For broader WAF and bot\u2011blocking strategies around your real\u2011time app, our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/waf-ve-bot-korumasi-cloudflare-modsecurity-ve-fail2bani-ayni-masada-baristirmanin-sicacik-hikayesi\/\">layered WAF and bot protection with Cloudflare, ModSecurity and Fail2ban<\/a> gives a practical, hosting\u2011side view.<\/p>\n<h3><span id=\"4_Robust_process_supervision_and_logging\">4. Robust process supervision and logging<\/span><\/h3>\n<ul>\n<li>Use <strong>systemd<\/strong> or <strong>PM2<\/strong> with proper restart policies for Node.js.<\/li>\n<li>Centralize logs from Nginx, Laravel and Node to simplify debugging.<\/li>\n<li>Set up basic health checks (e.g. hitting a <code>\/health<\/code> endpoint on your WebSocket server) and uptime monitoring.<\/li>\n<\/ul>\n<p>We have written several guides on <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-kaynak-kullanimi-izleme-rehberi-htop-iotop-netdata-ve-prometheus\/\">VPS resource monitoring<\/a> and <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-izleme-ve-uyari-nasil-kurulur-prometheus-grafana-ve-node-exporter-ile-sessiz-alarmlari-konusturmak\/\">setting up Prometheus + Grafana + exporters for alerting<\/a>; these same tools work well for tracking connection counts, CPU spikes and memory leaks in real\u2011time stacks.<\/p>\n<h3><span id=\"5_Plan_for_graceful_deploys\">5. Plan for graceful deploys<\/span><\/h3>\n<p>Because WebSocket clients hold persistent connections, naive restarts can abruptly disconnect thousands of users. Aim for:<\/p>\n<ul>\n<li>Rolling or zero\u2011downtime deploys (e.g. symlink releases + systemd reloads).<\/li>\n<li>Short connection timeouts and automatic reconnect logic on the frontend.<\/li>\n<li>Version negotiation if you change message formats or channel naming.<\/li>\n<\/ul>\n<p>We use the same techniques described in our guide to <a href=\"https:\/\/www.dchost.com\/blog\/en\/vpse-sifir-kesinti-ci-cd-nasil-kurulur-rsync-sembolik-surumler-ve-systemd-ile-sicacik-bir-yolculuk\/\">zero\u2011downtime CI\/CD to a VPS with rsync, symlinked releases and systemd<\/a> when deploying real\u2011time apps.<\/p>\n<h2><span id=\"Conclusion_Choosing_the_Right_Home_for_Your_RealTime_App\">Conclusion: Choosing the Right Home for Your Real\u2011Time App<\/span><\/h2>\n<p>WebSockets, Node.js, Laravel Echo and Socket.io open the door to richer, more interactive applications. But they also bring new hosting requirements: long\u2011running processes, open TCP ports, TLS termination, and higher expectations around latency and reliability.<\/p>\n<p>If you are today on shared hosting, you can still experiment with pseudo\u2011real\u2011time features using polling or an external real\u2011time service, and even offload only the WebSocket component to a small VPS while keeping the rest of your Laravel app where it is. Once real\u2011time becomes core to your product, moving to a VPS or even a <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a> at dchost.com gives you the control you need over Node.js, Redis, Nginx and security hardening.<\/p>\n<p>As a hosting provider focused on developers, we help customers daily with questions like \u201cIs my current plan enough for WebSockets?\u201d or \u201cHow do I wire Laravel Echo to a new VPS correctly?\u201d If you are planning a real\u2011time feature or a full\u2011blown WebSocket\u2011based SaaS, our team can help you design the right mix of shared hosting, VPS, dedicated server or colocation. Start small, measure, and iterate\u2014your infrastructure can grow alongside your real\u2011time app instead of getting in its way.<\/p>\n<p>&#8220;,<br \/>\n  &#8220;focus_keyword&#8221;: &#8220;Hosting WebSocket and real-time apps&#8221;,<br \/>\n  &#8220;meta_description&#8221;: &#8220;Learn how to host WebSocket and real-time apps with Node.js, Laravel Echo and Socket.io on shared hosting or a VPS, with practical setups and limits in production.&#8221;,<br \/>\n  &#8220;faqs&#8221;: [<br \/>\n    {<br \/>\n      &#8220;question&#8221;: &#8220;Can I run WebSockets on a shared hosting plan?&#8221;,<br \/>\n      &#8220;answer&#8221;: &#8220;In most classic shared hosting environments, you cannot run a custom long\u2011running WebSocket server like Node.js or Laravel Echo because you do not control ports or background processes. However, you can still simulate real\u2011time behaviour with short polling, long polling or Server\u2011Sent Events, and you can integrate with external hosted real\u2011time APIs via HTTP from your PHP application. When WebSockets become central to your app or you need thousands of concurrent connections, moving at least the WebSocket component to a VPS is usually the practical next step.&#8221;<br \/>\n    },<br \/>\n    {<br \/>\n      &#8220;question&#8221;: &#8220;Do I need a VPS to use Laravel Echo and Socket.io in production?&#8221;,<br \/>\n      &#8220;answer&#8221;: &#8220;If you want to run your own Laravel Echo Server or custom Socket.io server, a VPS (or dedicated server) is strongly recommended. You need root access to install Node.js, configure Nginx as a reverse proxy for wss:\/\/ traffic, open custom ports and run long\u2011lived processes under systemd or PM2. You can technically keep the main Laravel app on shared hosting and host only the Echo\/Socket.io piece on a small VPS, but the moment real\u2011time features become core to your product, consolidating everything on a well\u2011sized VPS brings simpler operations and better performance.&#8221;<br \/>\n    },<br \/>\n    {<br \/>\n      &#8220;question&#8221;: &#8220;How many users can a small VPS handle for WebSocket connections?&#8221;,<br \/>\n      &#8220;answer&#8221;: &#8220;A modest VPS (for example 2 vCPU and 4 GB RAM) can handle thousands of mostly idle WebSocket connections, assuming your message rate per user is moderate and your code is efficient. The real limits depend on CPU, memory, file descriptor limits, and how often you broadcast to large groups. The best approach is to load test your specific workload: simulate the number of concurrent users, the frequency of messages and reconnect behaviour. As you grow, you can scale out by running multiple Node.js instances behind Nginx and using Redis as a message bus for Socket.io.&#8221;<br \/>\n    },<br \/>\n    {<br \/>\n      &#8220;question&#8221;: &#8220;How do I secure WebSocket connections in a Laravel + Node.js setup?&#8221;,<br \/>\n      &#8220;answer&#8221;: &#8220;First, always use TLS and serve WebSockets as wss:\/\/ behind HTTPS. In Laravel, rely on private and presence channels so access is checked on every subscription. Your WebSocket server (Laravel Echo or Socket.io) should verify auth tokens and user IDs for each connection and channel join. Add rate limiting and message throttling to prevent abuse, and protect your HTTP upgrade endpoints with a WAF and basic DDoS mitigations. Finally, run Node.js and Laravel under non\u2011root users, keep packages updated and monitor logs so you can quickly spot suspicious patterns or crashes.&#8221;<br \/>\n    },<br \/>\n    {<br \/>\n      &#8220;question&#8221;: &#8220;Can I put WebSockets behind Cloudflare or another CDN?&#8221;,<br \/>\n      &#8220;answer&#8221;: &#8220;Yes, modern CDNs support WebSockets, but there are practical details. You must enable proxying on the hostname, ensure the CDN is configured to pass the Upgrade and Connection headers correctly, and respect any idle timeout limits they impose. On your origin server, Nginx should be tuned with appropriate proxy_read_timeout and keepalive settings so connections are not dropped prematurely. We have a dedicated guide on keeping WebSockets healthy behind Cloudflare and Nginx, and the same principles\u2014longer timeouts, proper headers and health checks\u2014apply to most CDN setups.&#8221;<br \/>\n    }<br \/>\n  ]<br \/>\n}<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>{ &#8220;title&#8221;: &#8220;Hosting WebSocket and Real\u2011Time Apps on Shared Hosting and VPS&#8221;, &#8220;content&#8221;: &#8220; WebSocket and real\u2011time features are no longer reserved for giant social networks. Chat widgets, live order dashboards, in\u2011app notifications, collaborative editors, trading panels, and multiplayer games are now common even on small business and SaaS projects. When you add Node.js, Laravel [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3614,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3613","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3613","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3613"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3613\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3614"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3613"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3613"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3613"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}