How WebSockets and Real‑Time Apps Really Work

{
“title”: “Hosting WebSocket and Real‑Time Apps on Shared Hosting and VPS”,
“content”: “

WebSocket and real‑time features are no longer reserved for giant social networks. Chat widgets, live order dashboards, in‑app 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: can this run on shared hosting, or do you really need a VPS?

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 “I only have cPanel” to “I’m ready to run reverse proxies, queues and Redis on a VPS.” By the end, you should be able to choose the right platform, size it properly, and deploy a secure, stable real‑time stack without surprises.

To choose the right hosting, it helps to understand what makes WebSockets different from normal HTTP.

HTTP vs WebSocket in simple terms

Traditional HTTP is request/response 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:

• Short polling: The browser hits an endpoint every few seconds.
• Long polling: The server keeps the request open until there is new data.
• Server‑Sent Events (SSE): A one‑way stream from server to browser.

WebSocket is different. After an initial HTTP handshake, the connection upgrades to a persistent, full‑duplex TCP channel. Browser and server can push data to each other at any time without reopening connections.

For real‑time apps, that means:

• Fewer connection setups (less overhead).
• Lower latency once the socket is open.
• Ability to push events to large numbers of online users simultaneously.

Where Node.js, Laravel Echo and Socket.io fit

In many stacks we see at dchost.com, the roles are roughly:

• Laravel (PHP): Main application, APIs, authentication, database operations.
• Broadcasting layer: Laravel broadcasting events to Redis or directly to a WebSocket server.
• Laravel Echo: JavaScript client that subscribes to channels and listens for broadcast events.
• Socket.io server: Usually written in Node.js, handles WebSocket (and fallbacks) and manages rooms/channels, presence, etc.

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’ projects.

Shared Hosting vs VPS for WebSocket and Real‑Time Workloads

Most developers first encounter WebSockets while already running on shared hosting. The natural question is: “Can I just turn on WebSockets here?” The honest answer is: it depends on what your shared hosting plan actually allows, but there are hard limits you should know.

Constraints of typical shared hosting

On classic shared hosting with cPanel or DirectAdmin, the provider usually gives you:

• PHP (often with multiple versions).
• Apache or LiteSpeed as the main web server.
• MySQL/MariaDB as the database.
• Process limits (no long‑running custom daemons).
• No ability to bind to arbitrary ports (like 3000, 6001).

WebSockets require a long‑running process (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:

• The platform kills background processes that exceed resource limits.
• You do not control the global firewall or listening ports.
• You cannot easily configure a reverse proxy (Nginx) to forward wss:// traffic.

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‑level real‑time app, this becomes a bottleneck fast.

What shared hosting is still good for

Shared hosting is still perfectly fine for:

• Your main PHP/Laravel site and classic HTTP APIs.
• Simple real‑time‑like features implemented via AJAX polling or SSE, where latency of a few seconds is acceptable.
• Using an external real‑time platform (a hosted WebSocket/broadcasting SaaS) via HTTP APIs from your PHP app.

If you are interested in a deeper PHP framework comparison on shared environments, we wrote a detailed guide on choosing between shared hosting and VPS for Laravel and other PHP frameworks. Many of the same trade‑offs apply directly to real‑time workloads.

What changes when you move to a VPS

On a VPS from dchost.com you get:

• Root (or sudo) access to install Node.js, Redis, queue workers, supervisors.
• Full control over ports and firewall (e.g. 80/443 for HTTP(S), 6001 for Laravel Echo, 3000 for Socket.io).
• The ability to run long‑lived processes using systemd or PM2.
• Freedom to configure Nginx or Apache as a reverse proxy to terminate TLS and forward wss:// traffic to your WebSocket processes.

At that point, you are building a small “real” backend architecture, not just uploading PHP files. If you want a step‑by‑step look at what that feels like in production, we documented it in our guide on hosting Node.js in production with PM2, Nginx, SSL and zero‑downtime deploys.

For a typical chat or notification system, a small VPS (1–2 vCPU, 2–4 GB RAM) is usually enough to get started. In our article on choosing VPS specs for WooCommerce, Laravel and Node.js, we go deeper into sizing CPU, RAM and storage for application servers; the same logic applies to WebSocket workloads.

Architecture Patterns for Node.js, Laravel Echo and Socket.io

Let’s look at practical architectures we often see on dchost.com infrastructure, from simplest to more advanced.

Pattern 1: Everything on one VPS

This is the most common pattern for small to medium projects:

• Nginx (or Apache) on port 80/443 as the public entry point.
• PHP‑FPM for Laravel on a local socket or port (e.g. 127.0.0.1:9000).
• MySQL/MariaDB on the same VPS (or a separate database VPS later).
• Redis for cache + broadcasting (optional but recommended).
• Node.js running:
  • A Laravel Echo Server (laravel-echo-server package) or
  • A custom Socket.io server (e.g. server.js).

Nginx handles HTTPS and reverse proxies specific paths or subdomains to the Node.js WebSocket server:

• https://example.com → Laravel (PHP‑FPM)
• wss://ws.example.com → Node.js + Socket.io

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‑traffic sites.

Pattern 2: Shared hosting for Laravel, VPS for real‑time

If you already have a stable Laravel application on shared hosting and want to add WebSockets without migrating everything, a practical compromise is:

• Keep the Laravel app and database where they are (shared hosting).
• Provision a small VPS for the Node.js WebSocket server (and optionally Redis).
• Configure Laravel broadcasting to point to this external WebSocket server.
• Expose a subdomain like ws.example.com that points to the VPS IP (via DNS A/AAAA records).

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.

Pattern 3: Full Node.js stack with Laravel only as API

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:

• Expose a single entry point (e.g. app.example.com) handled by Node.js + Socket.io.
• Use Laravel as a separate API on another subdomain (e.g. api.example.com).
• Share auth via JWTs or OAuth2 between both worlds.

From the hosting side, this looks more like a classic Node.js SaaS architecture and benefits strongly from the practices we detail in our comparison of where to host Node.js apps: cPanel, shared hosting or VPS.

Running WebSockets on Shared Hosting: What Is Actually Possible?

Given these patterns, what can you realistically do if you are stuck on shared hosting for now?

Option 1: Simulate “real‑time” without WebSockets

If your use case is not ultra‑latency‑sensitive, you can often get away with:

• Short polling: JavaScript hitting an endpoint every 3–5 seconds for new messages or notifications.
• Long polling: PHP script that holds the HTTP connection open for up to 30 seconds and returns as soon as there is new data.
• Server‑Sent Events (SSE): If your host allows streaming responses, SSE provides a one‑way push channel from server to browser.

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.

Option 2: Use an external real‑time service

Another pattern is to use a third‑party real‑time platform (a hosted WebSocket/broadcasting SaaS) that provides:

• A WebSocket endpoint your frontend can connect to.
• HTTP APIs your PHP/Laravel app can call to publish events.
• SDKs for presence channels, private channels, etc.

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.

Option 3: Move only the WebSocket piece to a VPS

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‑effective upgrade path when teams hit the limitations of pure shared hosting.

Setting Up WebSockets on a VPS: A Practical Blueprint

Let’s walk through a realistic deployment on a dchost.com VPS. We will assume:

• Ubuntu or Debian‑based Linux on the VPS.
• Nginx as reverse proxy.
• Laravel app (PHP‑FPM) and Node.js on the same machine.

Step 1: Basic server hardening and web stack

Before touching WebSockets, prepare the VPS properly:

1. Update packages and enable automatic security updates.
2. Configure a firewall (e.g. ufw or iptables) to allow only required ports (22, 80, 443, plus your WebSocket port if exposed directly).
3. Install Nginx, PHP‑FPM and your database.

If you want a structured checklist for initial VPS hardening, our guide on VPS security hardening (sshd_config, Fail2ban, disabling direct root) is a good reference. Investing in this early saves a lot of trouble later.

Step 2: Install Node.js and your WebSocket server

On the VPS, install Node.js from the official repositories or a Node version manager. Then:

• For Laravel Echo Server: install the laravel-echo-server package globally or in your project and create a config file (typically laravel-echo-server.json).
• For a custom Socket.io server: initialize a Node project and create e.g. server.js that sets up an HTTP server and attaches Socket.io.

Run the server on a local port, for example:

• Laravel Echo Server on 127.0.0.1:6001
• Custom Socket.io server on 127.0.0.1:3000

Then configure systemd units or PM2 to keep these processes alive, restart on failure and start at boot. Our Node.js production guide shows concrete examples of both approaches.

Step 3: Configure Laravel broadcasting

In your Laravel app:

1. Set BROADCAST_DRIVER in .env to redis, pusher or a custom driver that talks to your Node.js Socket.io server.
2. If using Redis, configure Redis host/port in .env and set up the Redis server on the same VPS (or another internal instance).
3. Define broadcast channels in routes/channels.php and implement authorization callbacks.

Now when your application fires events (e.g. event(new MessageSent($message))), 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.

Step 4: Nginx reverse proxy for WebSockets

Most browsers talk WebSockets over wss:// (WebSocket over TLS). A common, clean pattern is:

• Terminate TLS at Nginx (port 443).
• Forward specific paths or hostnames to the internal Node.js process.

For example, if your Socket.io server listens on 127.0.0.1:3000 and you want it served at wss://ws.example.com/socket.io/, your Nginx server block might roughly contain:

<code>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}</code>

This ensures the Upgrade header and connection are preserved so Socket.io can upgrade the HTTP request to WebSocket.

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 keeping WebSockets and gRPC happy behind Cloudflare with correct Nginx timeouts and keep‑alive settings, which applies directly here.

Step 5: Frontend configuration (Laravel Echo / Socket.io client)

On the frontend, you typically:

• Install Laravel Echo and the Socket.io client via npm/yarn.
• Initialize Echo with the correct broadcaster and host/port settings.
• Join channels and listen for events that match your Laravel broadcast names.

Example (simplified):

<code>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) => {n        console.log('New message', e.message);n    });</code>

Make sure the host and protocol (wss vs ws) align with your Nginx configuration and TLS setup.

Performance, Scaling and Resource Planning for Real‑Time Apps

WebSockets change the resource profile of your server. Instead of lots of short‑lived HTTP requests, you now have many concurrent open connections. That affects how you size and tune your VPS.

Key resource dimensions

• vCPU: Message fan‑out, JSON encoding/decoding, business logic in Node/Laravel all use CPU. For simple chat/notification workloads, 1–2 vCPU is often fine to start.
• RAM: Each WebSocket connection consumes memory in the Node process and in system buffers. Add room for Redis and PHP‑FPM processes.
• Network bandwidth and latency: Real‑time apps are sensitive to jitter. Hosting closer to your main user base and choosing NVMe‑backed VPS storage (for database and Redis) improves overall responsiveness. Our NVMe VPS hosting guide explains why fast disk I/O still matters even for seemingly “in‑memory” workloads.

Connection counts and limits

A small VPS can handle surprisingly many idle WebSocket connections (thousands) as long as message throughput is modest. Bottlenecks tend to be:

• Per‑process file descriptor limits.
• Kernel networking buffers (e.g. net.core.somaxconn, net.ipv4.tcp_max_syn_backlog).
• Application‑level broadcast patterns (e.g. broadcasting to 10,000 clients on every keystroke).

As your app grows, you can:

• Use Redis or another message bus and Socket.io’s Redis adapter to scale horizontally across multiple Node.js instances.
• Separate the database and WebSocket servers onto different VPS plans to avoid resource contention.
• Introduce rate limiting and debouncing for chat typing indicators, presence updates, etc.

Measure before guessing

Don’t rely only on “feels fast”. 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 load testing your hosting before real traffic spikes. The same discipline applies to WebSocket apps: test join/leave rates, broadcast storms and reconnect behaviour.

Security and Reliability Checklist for WebSocket Hosting

Persistent connections bring persistent attack surfaces. Here are practical measures we recommend to dchost.com customers deploying real‑time stacks.

1. Use TLS everywhere

Always serve WebSockets as wss:// behind HTTPS. This protects session cookies, auth tokens and message content from sniffing. Modern browsers also block insecure WebSockets from secure pages, so ws:// is not an option in production.

2. Strict authentication and authorization

• Use Laravel’s built‑in private and presence channels for per‑user/per‑room access control.
• Ensure the WebSocket server verifies auth tokens on connection and when joining channels.
• Expire tokens and handle revoked sessions (e.g. after password change).

3. Rate limiting and abuse protection

WebSockets can be abused by:

• Opening many concurrent connections from the same IP.
• Flooding the server with messages.
• Attempting to brute‑force channel names or auth tokens.

Defences include:

• IP‑based connection limits in your Node.js server.
• Application‑level throttling (e.g. one message per N milliseconds per user).
• Network‑level protections and WAF rules on the HTTP handshake endpoints.

For broader WAF and bot‑blocking strategies around your real‑time app, our article on layered WAF and bot protection with Cloudflare, ModSecurity and Fail2ban gives a practical, hosting‑side view.

4. Robust process supervision and logging

• Use systemd or PM2 with proper restart policies for Node.js.
• Centralize logs from Nginx, Laravel and Node to simplify debugging.
• Set up basic health checks (e.g. hitting a /health endpoint on your WebSocket server) and uptime monitoring.

We have written several guides on VPS resource monitoring and setting up Prometheus + Grafana + exporters for alerting; these same tools work well for tracking connection counts, CPU spikes and memory leaks in real‑time stacks.

5. Plan for graceful deploys

Because WebSocket clients hold persistent connections, naive restarts can abruptly disconnect thousands of users. Aim for:

• Rolling or zero‑downtime deploys (e.g. symlink releases + systemd reloads).
• Short connection timeouts and automatic reconnect logic on the frontend.
• Version negotiation if you change message formats or channel naming.

We use the same techniques described in our guide to zero‑downtime CI/CD to a VPS with rsync, symlinked releases and systemd when deploying real‑time apps.

Conclusion: Choosing the Right Home for Your Real‑Time App

WebSockets, Node.js, Laravel Echo and Socket.io open the door to richer, more interactive applications. But they also bring new hosting requirements: long‑running processes, open TCP ports, TLS termination, and higher expectations around latency and reliability.

If you are today on shared hosting, you can still experiment with pseudo‑real‑time features using polling or an external real‑time 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‑time becomes core to your product, moving to a VPS or even a dedicated server at dchost.com gives you the control you need over Node.js, Redis, Nginx and security hardening.

As a hosting provider focused on developers, we help customers daily with questions like “Is my current plan enough for WebSockets?” or “How do I wire Laravel Echo to a new VPS correctly?” If you are planning a real‑time feature or a full‑blown WebSocket‑based SaaS, our team can help you design the right mix of shared hosting, VPS, dedicated server or colocation. Start small, measure, and iterate—your infrastructure can grow alongside your real‑time app instead of getting in its way.

“,
“focus_keyword”: “Hosting WebSocket and real-time apps”,
“meta_description”: “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.”,
“faqs”: [
{
“question”: “Can I run WebSockets on a shared hosting plan?”,
“answer”: “In most classic shared hosting environments, you cannot run a custom long‑running WebSocket server like Node.js or Laravel Echo because you do not control ports or background processes. However, you can still simulate real‑time behaviour with short polling, long polling or Server‑Sent Events, and you can integrate with external hosted real‑time 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.”
},
{
“question”: “Do I need a VPS to use Laravel Echo and Socket.io in production?”,
“answer”: “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‑lived 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‑time features become core to your product, consolidating everything on a well‑sized VPS brings simpler operations and better performance.”
},
{
“question”: “How many users can a small VPS handle for WebSocket connections?”,
“answer”: “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.”
},
{
“question”: “How do I secure WebSocket connections in a Laravel + Node.js setup?”,
“answer”: “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‑root users, keep packages updated and monitor logs so you can quickly spot suspicious patterns or crashes.”
},
{
“question”: “Can I put WebSockets behind Cloudflare or another CDN?”,
“answer”: “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—longer timeouts, proper headers and health checks—apply to most CDN setups.”
}
]
}