---

- AWS Route 53 DNS hosted zone - Web server using NGINX - Website already configured using SSL - SSH access with sudo (root) privileges - Knowledge and comfort navigating linux using the bash shell - Knowledge and comfort on how to view and edit files in linux (ie. vi, vim, nano…) ---

- Installing CertBot - Installing DNS Plugin - Create IAM Policy - Create IAM Role - Associate IAM Role with EC2 Instance - Run CertBot and get new Certs - Update NGINX to use new SSL Certs - Test and restart NGINX - Validate SSL Cert - Test and review CertBot auto renewal

---

- Click \[Create Role\] > \[AWS Service\] > \[EC2\] > \[Next: Permissions\] - Search for and select your newly created Policy (one created from above) - Click \[Next: Tags\] > (Enter a TAG if you wish) > \[Next: Review\] - Give your new role a meaningful name and description - Click \[Create Role\] ---

- Click to select your EC2 Instance - Click \[Actions\] > Instance settings > \[Attach / Replace IAM Role\] - In the “IAM Role” dropdown list, click and select the IAM Role that you created (from above) - Click \[Apply\] > \[Close\] ---

---

- /etc/nginx/nginx.conf - /etc/nginx/sites-available/<site name> - /etc/nginx/snippets/ - Update the following folders with new “fullchain.pem and privkey.pem” - beta\_ssl.conf , fastcgi-php.conf , rc\_ssl.conf , snakeoil.conf

- ssl\_certificate - ssl\_certificate\_key

- `privkey.pem` : the private key for your certificate. - `fullchain.pem`: the certificate file used in most server software. - `chain.pem` : used for OCSP stapling in Nginx >=1.3.7. - `cert.pem` : will break many server configurations, and should not be used without reading further documentation

- ssl\_certificate /etc/letsencrypt/live/`example.com`/fullchain.pem; - ssl\_certificate\_key /etc/letsencrypt/live/`example.com`/privkey.pem; ---

---

- ssl\_certificate - ssl\_certificate\_key

- ssl\_certificate /etc/letsencrypt/live/`example.com`/fullchain.pem; - ssl\_certificate\_key /etc/letsencrypt/live/`example.com`/privkey.pem; ---

---

![](https://docs.impressto.ca/wp-content/uploads/2021/07/image-1580916581549.png)

![SSL Cert Info](https://docs.impressto.ca/devdocs.ruckify.com/uploads/images/gallery/2020-02/scaled-1680-/image-1580916581549.png)

---

- /etc/crontab/ - /etc/cron.\*/\* – (ie. /etc/cron.d/certbot) - systemctl list-timers

---

- [https://certbot.eff.org/lets-encrypt/ubuntuxenial-nginx](https://certbot.eff.org/lets-encrypt/ubuntuxenial-nginx) - [https://certbot-dns-route53.readthedocs.io/en/stable/](https://certbot-dns-route53.readthedocs.io/en/stable/)

---

wq`. If you have any sort of syntax problem, `visudo` will warn you and you can abort the change or open the file for editing again.It is important to add this line at the **end** of the file, so that the other permissions do not override this directive, since they are processed in order. Note that for mac the save steps are a little different because mac uses vim for visudo edits. Press the Escape key. Then, type **:wq** and press enter. This saves the file and quits vim. Finally, open a new terminal window and run a command that requires `root` privileges, such as `sudo apt-get update`. You should not be prompted for your password! # Fix Localhost Binding for Safari Safari does not automatically bind \*.localhost domains to 127.0.0.1. To use Safari for local development and especially when using docker with SSL you will need to add the entries to your /etc/hosts file. Here is an example: ``` sudo nano /etc/hosts ``` ``` # add the following entries 127.0.0.1 mysite.localhost 127.0.0.1 somesubdomain.mysite.localhost ```

---

# Create an SSH Key for Git SSH keys are not just for Git but if you want to use SSH cloning for git, yeah you need em. To create a new SSH key pair do the following: 1.) Open a terminal on Linux or macOS, or Git Bash / WSL on Windows. 2.) Generate a new ED25519 SSH key pair: ``` ssh-keygen -t rsa -b 2048 -C "username@mysite.com" or ssh-keygen -t ed25519 -C "username@mysite.com" ``` 3.) Use the defaults for all options if you like. Doesn’t matter. ##### Copying SSH Key to Gitlab Go into the ~/.ssh folder. On Mac you may need to do the following to see the .ssh folder: ``` # open the finder dialog Command+Shift+G # enter ~/.ssh # view hidden files Command+Shift+. ``` On Linux: ``` cd ~/.ssh # on your keyboard hit Ctrl +h ``` Once you can see the hidden files you should see a file named id\_rsa.pub or something like that. It ends with .pub. Open that file with a text editor and you will see the SSH key you need to copy to your own gitlab account. ##### Using a Access Token (works too but yuk!) If you are not using an SSH connection you may need to create a personal access token (image below). Make sure you save the token on your local machine as you will not be able to retreive it once you close the page where you created it on Gitlab. To clone a repo using an access token, it is similar to cloning with https but the url is slightly different. If your token is for example xSx81KqnADs-mZ4JviHa, the cloning command will be ``` git clone https://oauth2:xSx81KqnADs-mZ4JviHa@gitlab.com/myaccount/myrep.git ``` If you were previously using https with a username and password, you will need to update the remote url on your local machine. Once you have created the access token you will need to change the remote origin of your local repo to add the access token. Here is an example of the old remote url and a new one ``` # old url https://somegitsite.com/mycompany/mysite.git # new url with access token https://oauth2:uggU-s2usayJtiqguEAQ@somegitsite.com/mycompany/mysite.git ``` To set the remote url use the following command as an example: ``` git remote set-url origin https://oauth2:AmDAyXHEVxyEBf3fbg@somegitsite.com/mycompany/mysite.git ``` # Install Mkcert for SSL on Localhost [![mkcert_on_local.jpg](https://docs.impressto.ca/uploads/images/gallery/2025-09/scaled-1680-/mkcert-on-local.jpg)](https://docs.impressto.ca/uploads/images/gallery/2025-09/mkcert-on-local.jpg) Mkcert is a simple tool for generating locally-trusted development SSL/TLS certificates. It requires minimal configuration. [https://github.com/FiloSottile/mkcert](https://github.com/FiloSottile/mkcert) #### Prerequisites (Ubuntu / Debian) Make sure you have: - `libnss3-tools` installed - Homebrew (Linuxbrew) if you want to install via brew To install on Debian (Ubuntu) use the following commands: ``` sudo apt install libnss3-tools ``` Install [LinuxBrew ](https://docs.brew.sh/Homebrew-on-Linux)– get the [installer](https://brew.sh/) ``` /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" ``` Enable it ``` test -d ~/.linuxbrew && eval $(~/.linuxbrew/bin/brew shellenv) test -d /home/linuxbrew/.linuxbrew && eval $(/home/linuxbrew/.linuxbrew/bin/brew shellenv) test -r ~/.bash_profile && echo "eval \$($(brew --prefix)/bin/brew shellenv)" >>~/.bash_profile echo "eval \$($(brew --prefix)/bin/brew shellenv)" >>~/.profile ``` Install mkcert ``` brew install mkcert; mkcert -install; ``` If at this point you are getting a `mkcert command not found` , or `Warning: /home/linuxbrew/.linuxbrew/bin is not in your PATH.` you many need to fix the global PATH var to include the mkcert bin folder. Edit your ~/$HOME/.profile file and add the following : ``` if [ -d "/home/linuxbrew/.linuxbrew/bin" ] ; then PATH="/home/linuxbrew/.linuxbrew/bin:$PATH" fi ``` Save the .profile file and from the terminal run `source ~/.profile` An alternative way to install Mkcert is the following (not fully tested by me): ``` sudo apt-get update sudo apt install wget libnss3-tools set MCVER="v.1.4.1" wget -O mkcert https://github.com/FiloSottile/mkcert/releases/download/${MCVER}/mkcert-${MCVER}-linux-amd64 chmod +x mkcert sudo mv mkcert /user/local/bin ``` #### Why This Matters Using mkcert lets you emulate HTTPS in your local environment, which helps with catching mixed content issues, testing secure cookies, HSTS, etc., before you deploy to production. # Apache Tricks #### **Set Server Agent Name** ``` sudo apt-get install libapache2-mod-security2 ``` Once the module is installed, you can modify the Apache config under the file `/etc/apache2/apache2.conf`. Add this line around the end of the file. ``` SecServerSignature "ecoware" ``` --- #### How to set the Expires Headers in Apache enable expires and headers modules for Apache ``` sudo a2enmod expires; sudo a2enmod headers; ``` Edit the /etc/apache2/apache2.conf file ``` sudo nano /etc/apache2/apache2.conf ``` Add the following ``` ExpiresActive on AddType image/x-icon .ico ExpiresDefault "access plus 2 hours" ExpiresByType text/html "access plus 7 days" ExpiresByType image/gif "access plus 7 days" ExpiresByType image/jpg "access plus 7 days" ExpiresByType image/jpeg "access plus 7 days" ExpiresByType image/png "access plus 7 days" ExpiresByType text/js "access plus 2 hours" ExpiresByType text/javascript "access plus 2 hours" ExpiresByType text/plain "access plus 2 hours" ExpiresByType image/x-icon "access plus 30 days" ExpiresByType image/ico "access plus 30 days" ``` Restart apache ``` sudo service apache2 restart ``` Check that it worked by loading an image. You should see an expired line in the output such as ``` Expires: Wed, 22 Aug 2020 22:03:35 GMT ``` See: [https://hooshmand.net/fix-set-expires-headers-apache/](https://hooshmand.net/fix-set-expires-headers-apache/) # NodeJS Proxy via Apache Here is how to serve nodejs entry points by using an Apache proxy. This hides the port number and the nodeJs entry points simply appear as part of the “monolithic” application. WINDOWS: Setup is easy: ``` Include "conf/extra/httpd-proxy.conf" LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_connect_module modules/mod_proxy_connect.so LoadModule proxy_http_module modules/mod_proxy_http.so ``` 2.) Open your proxy config file `C:\xampp\apache\conf\extra\httpd-proxy.conf`. Edit it to match the following: ``` ProxyRequests On ProxyVia On Order deny,allow Allow from all ProxyPass /node http://127.0.0.1:3000/ ProxyPassReverse /node http://127.0.0.1:3000/ ``` 3.) Open your vhosts file `C:\xampp\apache\conf\extra\httpd-vhosts.conf`. Add the following: ``` ProxyPreserveHost On ProxyPass "/node" "http://127.0.0.1:3000/" ProxyPassReverse "/node" "http://127.0.0.1:3000/" ServerName api.impressto.net ``` 4.) Restart Apache. from command terminal run: ``` sudo a2enmod proxy sudo a2enmod proxy_http sudo a2enmod proxy_balancer sudo a2enmod lbmethod_byrequest sudo service apache2 restart ``` 2.) Open vhosts file /etc/`apache2/sites-available/api.impressto.net.conf`. Add the following: ``` ServerAdmin admin@impressto.net ServerName impressto.localhost DocumentRoot /var/www/impressto.localhost/public ProxyPreserveHost On ProxyPass / http://127.0.0.1:8000/ ProxyPassReverse / http://127.0.0.1:8000/ ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/apache2/ssl/apache.crt SSLCertificateKeyFile /etc/apache2/ssl/apache.key Options Indexes FollowSymLinks MultiViews AllowOverride All Require all granted ``` .. # SQL simplified [![464839105_2251428365242267_4073966686533682812_n.jpg](https://docs.impressto.ca/uploads/images/gallery/2024-11/scaled-1680-/464839105-2251428365242267-4073966686533682812-n.jpg)](https://docs.impressto.ca/uploads/images/gallery/2024-11/464839105-2251428365242267-4073966686533682812-n.jpg) # Setup a WebSocket Server with Cloudflare

## 1. What WebRTC is WebRTC (**Web Real-Time Communication**) is a set of APIs built into modern browsers that lets two peers (e.g., two users in React apps) **connect directly** to each other to exchange:

- Audio/video streams - Data (via a “data channel”) — chat messages, files, game state, etc.

The magic: it works **peer-to-peer**, not through a central server (though servers are still used to help them connect).

---

## 2. The Core Pieces For two apps to talk over WebRTC, you need: ### a) **Signaling**

- Before peers connect, they must exchange “connection setup” info (called **SDP offers/answers** and **ICE candidates**). - This is usually done via a server using **WebSockets**, **HTTP POST**, or any other channel you choose. - Example: your React app might send the connection info through a Node.js/Express WebSocket server.

### b) **ICE / STUN / TURN**

- WebRTC peers must figure out how to reach each other across the internet (even behind NAT/firewalls). - **STUN servers**: help discover the public IP/port of each peer. - **TURN servers**: relay data if direct P2P fails (fallback). - WebRTC handles this automatically if you give it the server addresses.

### c) **PeerConnection**

- In code: `new RTCPeerConnection()` - This object manages the whole connection, media, and data.

### d) **Data Channel**

- In code: `peerConnection.createDataChannel("chat")` - Lets you send arbitrary text or binary data → perfect for chat and file transfers. ---

## 3. Flow of a Connection Here’s what happens when User A chats with User B:

1. **A creates an RTCPeerConnection.** 2. **A creates a data channel** (`chat`). 3. **A creates an SDP offer** (basically: "here’s what I support"). 4. **A sends the offer to B** via your signaling server. 5. **B receives the offer**, creates an RTCPeerConnection, and sets it as `remoteDescription`. 6. **B creates an SDP answer** (like: "ok, here’s what I support"). 7. **B sends the answer back to A** via the signaling server. 8. **Both A and B exchange ICE candidates** until they find a working route. 9. **Connection established 🎉** - Now data (chat messages, files) or media (audio/video streams) flows directly between browsers. ---

## 4. Chat Example (DataChannel)

On Peer B:

---

## 5. File Transfer Example WebRTC DataChannels support **binary blobs**, so you can send files chunk-by-chunk:

Receiver just listens for binary data and reconstructs the file.

---

## 6. Why This Is Cool

- **Low latency** → no central server relaying chat or files. - **Efficient file transfer** → can be faster than traditional uploads. - Works in **all modern browsers** (React can just wrap the APIs). ---

👉 So in your React app, the “chat + file transfer” works because:

- You use **WebRTC DataChannels** to send text or binary data. - A **signaling server** helps the two peers find each other and exchange connection info. - Once connected, the peers exchange messages/files **directly**. ---

---

## 1. What signaling needs Signaling is just about exchanging:

- **SDP offers/answers** (connection descriptions) - **ICE candidates** (network routes)

This requires **bidirectional, asynchronous communication** between peers (via your server).

---

## 2. Options compared ### ✅ WebSockets

- **Persistent, bidirectional** connection → server and client can both push messages. - Handles **real-time** signaling well. - Scales decently (lots of libraries and servers like Socket.IO). - Good match for WebRTC’s event-driven flow (offer → answer → ICE candidates).

### ⚠️ HTTP (long polling / REST)

- Works, but is **clunky**: - Client has to poll server repeatedly for new messages. - Higher latency (not great if you want snappy connection setup). - Server load is heavier (more requests). - Might make sense if: - You already have an HTTP-only environment. - You’re connecting infrequently and can tolerate delay. ---

## 3. Hybrid approach Some apps start with **HTTP POST** to register a peer (like “here’s my offer”) and then switch to **WebSocket** or another channel for ongoing exchange. But for your React chat/file transfer app, that’s overkill — just stick with WebSockets.

---

## 4. Rule of thumb

- **If real-time matters (chat, file transfer, video, games): → WebSockets.** - **If it’s rare / one-off signaling (like joining a Zoom meeting via invite link): → HTTP can work, but WebSockets still nicer.** ---

👉 So for your use case (chat + file sharing between React apps), **WebSockets are definitely the better choice** for signaling. Would you like me to show you a **minimal WebSocket + WebRTC signaling server (Node.js)** that you could plug into your React app as a starting point?

---

## 1. Why you can use PHP

- **WebRTC doesn’t care what language your signaling server is in.** All it needs is a way to exchange JSON messages (offers, answers, ICE candidates). - WebSockets are just a protocol — PHP can handle them. ---

## 2. Options for PHP WebSocket servers

- **Ratchet** (most popular PHP WebSocket library) - Built on ReactPHP (event loop). - Handles multiple connections easily. - **Workerman** (another solid async PHP framework). - Native PHP WebSocket scripts exist, but they’re much more limited. ---

## 3. Minimal Ratchet Example Install via Composer:

Server (server.php):

`use Ratchet\MessageComponentInterface;use Ratchet\ConnectionInterface;require __DIR__ . '/vendor/autoload.php';class SignalingServer implements MessageComponentInterface { public function onOpen(ConnectionInterface $conn) { echo "New connection: {$conn->resourceId}\n"; } public function onMessage(ConnectionInterface $from, $msg) { // Broadcast to all clients except sender foreach ($from->httpRequest->getUri()->getHost() as $client) { if ($from !== $client) { $client->send($msg); } } } public function onClose(ConnectionInterface $conn) { echo "Connection {$conn->resourceId} closed\n"; } public function onError(ConnectionInterface $conn, \Exception $e) { echo "Error: {$e->getMessage()}\n"; $conn->close(); }}$server = Ratchet\App('localhost', 8080);$server->route('/signaling', new SignalingServer, ['*']);$server->run();`

Run it:

---

## 4. Connecting from React In your React app:

---

## 5. Is PHP the best choice?

- If your app is **already running PHP (LAMP stack, WordPress, Laravel, etc.)** → Ratchet is fine. - If you want **scalability** or **lots of concurrent users** → Node.js / Go / Python WebSocket servers perform better. ---

---

## 1. Does Cloudflare support WebSockets? ✅ Yes.

- Cloudflare has supported **WebSocket proxying** for years on **all plans** (Free, Pro, Business, Enterprise). - Your WebSocket server just needs to listen on a port Cloudflare allows (usually 80/443 through HTTPS/WSS). ---

## 2. How Cloudflare Tunnel affects it

- **Cloudflare Tunnel (cloudflared)** creates a secure outbound-only connection from your server → Cloudflare → the internet. - If your React app connects to `wss://yourdomain.com/signal`, Cloudflare terminates TLS and then forwards the WebSocket traffic through the tunnel to your server. - From your server’s perspective, it just sees a normal WebSocket connection.

So yes, **your PHP WebSocket server will work fine through Cloudflare Tunnel**.

---

## 3. Things to watch out for

- **Long-lived connections:** WebSockets rely on staying open. Cloudflare supports long-lived connections (up to 24 hours on free tier, unlimited on Enterprise). If a connection drops, your app should be able to reconnect. - **Ports:** If you’re behind Cloudflare, you generally can’t just expose random ports like `:8080` directly. Instead: - Run your WebSocket server on `:443` (wss) or `:80` (ws). - Or let `cloudflared` map `wss://yourdomain.com/signal` → your local server’s `localhost:8080`. - **Performance:** WebRTC **media/data traffic does not flow through Cloudflare** — only the signaling WebSocket does. Once peers connect P2P, audio/video/files bypass Cloudflare. (Exception: if TURN relay is needed, then that server must be public too, and Cloudflare isn’t involved.) ---

## 4. Example Setup

1. Run your PHP Ratchet WebSocket server on `localhost:8080`. 2. Start a Cloudflare tunnel: 3. In Cloudflare dashboard, map a subdomain (e.g., `signal.example.com`) to `http://localhost:8080`. Cloudflare will handle upgrading HTTP → WebSocket automatically. 4. In your React app: ---

✅ Result:

- React app → Cloudflare → tunnel → PHP WebSocket server. - WebRTC peers connect directly (only signaling goes through Cloudflare). ---

---

## 1. Prerequisites

- A **domain** managed by Cloudflare (e.g. `example.com`) - Cloudflare Tunnel (`cloudflared`) installed on your server - Your **PHP WebSocket server** running locally on port `8080` (Ratchet example earlier) ---

## 2. Create a named tunnel

This generates a tunnel UUID and credentials file, usually at:

---

## 3. Configure the tunnel (YAML) Create a config file at `~/.cloudflared/config.yml`:

### Explanation:

- `hostname`: the public domain/subdomain you want (`signal.example.com`) - `service`: the local service (your PHP WebSocket server on `localhost:8080`) - The last catch-all rule (`http_status:404`) ensures requests not matching go nowhere ---

## 4. Connect the tunnel to Cloudflare Run:

This tells Cloudflare DNS to point `signal.example.com` → your tunnel.

---

## 5. Run the tunnel Foreground (debugging):

Background (production):

---

## 6. React client connection Now in your React app, connect securely:

---

## 7. Important notes

- **Use `wss://`** (not plain `ws://`) — Cloudflare will terminate TLS for you. - Cloudflare automatically upgrades HTTP → WebSocket, so you don’t need any special handling in PHP. - Your WebSocket server doesn’t need to know about Cloudflare; it just sees normal connections. - Only **signaling traffic** goes through Cloudflare. The actual WebRTC peer-to-peer data (chat, files, media) bypasses Cloudflare once established. ---

👉 With this setup, you get:

- Secure **WebSocket signaling** (`wss://signal.example.com`) - Automatic TLS from Cloudflare - No need to expose random ports — everything runs through 443 ---

Done — I created a code + instructions document in the canvas titled **Webrtc-php-ratchet-signaling-and-react**. It includes:

- A Ratchet PHP signaling server that supports rooms and routing `offer` / `answer` / `ice` messages to specific peers. - A compact React hook (`useWebRTC`) showing how to join, create offers/answers, exchange ICE, and open a DataChannel for chat/files. - File-transfer tips, message formats, Cloudflare Tunnel reminders, and production recommendations.

Open the canvas (the document named **Webrtc-php-ratchet-signaling-and-react**) to copy the server and client code and follow the run instructions.

---

## 1. Do you need special Nginx config? It depends how you’re exposing your WebSocket server:

- **If you’re using Cloudflare Tunnel** (as we outlined earlier): - Nginx doesn’t see the WebSocket traffic at all — `cloudflared` maps your domain directly to the Ratchet server on `localhost:8080`. - No special Nginx config is needed for signaling. Nginx can still serve your React app or APIs on the same domain or another subdomain. - **If you want Nginx to proxy WebSockets** to Ratchet (without Cloudflare): - You need to enable **upgrade headers** in the proxy config. Example:

`server { listen 443 ssl; server_name signal.example.com; ssl_certificate /etc/letsencrypt/live/signal.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/signal.example.com/privkey.pem; location / { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; }}`

Key part is: That allows Nginx to upgrade the HTTP request to a WebSocket connection. ---

## 2. Does the PHP Ratchet server need to be persistent? Yes ✅

- Ratchet is an **event loop server** (like Node.js). - Unlike normal PHP web apps (short-lived scripts under FPM/Apache), this **must run as a long-lived process** because it maintains open WebSocket connections.

That means:

- You run it via `php server.php`, and it stays running. - You should manage it like any daemon: - With **systemd** (recommended): create a unit file so it auto-restarts and runs on boot. - Or with **supervisord**, `pm2`, or Docker.

Example `systemd` unit (`/etc/systemd/system/ratchet.service`):

Then:

---

## 3. Summary

- **With Cloudflare Tunnel** → no Nginx config needed. - **With Nginx reverse proxy** → add `proxy_set_header Upgrade` + `Connection "Upgrade"` for WebSockets. - **Ratchet must run persistently** → treat it like a daemon, not like a normal PHP-FPM request/response cycle. ---

---

### 🔑 Why Node.js fits better than PHP Ratchet for signaling

1. **Event-driven runtime** - Node was built for long-lived connections (like WebSockets). - You don’t need to think about keeping PHP alive or managing a daemon separately. 2. **Ecosystem** - `ws` (a very popular WebSocket library) is lightweight and fast. - Tons of tutorials, examples, and tools for WebRTC signaling in Node. 3. **Deployment simplicity** - Easier to containerize with Docker. - Works seamlessly with **Cloudflare Tunnel** (no Nginx needed, just tunnel directly to your Node app). 4. **Code symmetry** - Your React frontend is already JS/TS → using Node on the backend means you can reuse types and data structures. ---

### 🟢 Minimal Node.js WebSocket signaling server

`// server.jsimport { WebSocketServer } from 'ws';const wss = new WebSocketServer({ port: 8080 });const rooms = new Map();wss.on('connection', (ws) => { ws.on('message', (msg) => { const data = JSON.parse(msg); const { type, room, payload } = data; if (type === 'join') { if (!rooms.has(room)) rooms.set(room, new Set()); rooms.get(room).add(ws); ws.room = room; } // Broadcast messages to everyone else in the same room if (['offer', 'answer', 'ice', 'chat', 'file'].includes(type)) { for (let client of rooms.get(room) || []) { if (client !== ws && client.readyState === ws.OPEN) { client.send(JSON.stringify({ type, payload })); } } } }); ws.on('close', () => { if (ws.room && rooms.has(ws.room)) { rooms.get(ws.room).delete(ws); if (rooms.get(ws.room).size === 0) { rooms.delete(ws.room); } } });});console.log("WebSocket signaling server running on ws://localhost:8080");`

---

### 🔄 React client-side example

---

### 🚀 Deployment with Cloudflare Tunnel

- Run the server on your host: `node server.js` (listening on port 8080). - Tunnel it: - Cloudflare handles SSL and exposure, no Nginx needed. ---

✅ So in your case:

- Keep **Nginx + PHP** for your normal APIs / website. - Run a **separate Node.js WebSocket signaling server** for WebRTC. - Expose it with Cloudflare Tunnel (no special Nginx config). ---

---

### 🔧 Options if port 8080 is already taken

1. **Pick a different local port** (simplest) - Run your Node signaling server on, say, `localhost:9000` or `localhost:7000`. - Example: - Expose it with Cloudflare Tunnel: - Cloudflare doesn’t care which local port you use — you can map it to any public subdomain. --- 2. **Run multiple services behind one Cloudflare Tunnel** - Cloudflare Tunnel supports **routing rules**. - Example `config.yml`: - That way, you can keep your existing app on 8080 and just run WebRTC signaling on another port. --- 3. **Use Nginx locally as a multiplexer** - If you want to keep everything on port 8080 internally, you can put Nginx in front: - Nginx listens on 8080. - Proxies `/signal` to `localhost:9000`. - Proxies `/` or `/api` to your other app. - Then Cloudflare Tunnel points to Nginx only. - This way, multiple apps coexist on the same port. Example: ---

### ✅ Recommended If this signaling server is dedicated, **Option 1 (different port + Cloudflare Tunnel mapping)** is the cleanest and least error-prone. You don’t even need to touch your existing app or Nginx config.

---

## 1. Example setup

- React frontend → `app.example.com` → served by Nginx on `localhost:3000` - PHP API → `api.example.com` → running on `localhost:8080` - WebRTC signaling server (Node.js WebSocket) → `signal.example.com` → running on `localhost:9000` ---

## 2. Cloudflare Tunnel config file (`/etc/cloudflared/config.yml`)

> 🔑 Notes: > > - `http://` is for normal HTTP traffic. > - `ws://` is for raw WebSockets (Node signaling server). > - `http_status:404` ensures unmatched requests don’t hang.

---

## 3. Start the tunnel If your tunnel is already created:

If not, create one first:

---

## 4. DNS setup in Cloudflare

- Each hostname (`app.example.com`, `api.example.com`, `signal.example.com`) should point to the tunnel. - Cloudflare takes care of SSL certificates for each. ---

## 5. Verify

- Open `https://app.example.com` → should serve your React app. - Open `https://api.example.com` → should hit your PHP backend. - Open `wss://signal.example.com` from your React client → should connect to your Node WebSocket server. ---

👉 This way you don’t worry about port clashes at all — every local service can run on its own port, and Cloudflare maps them to different hostnames.

---

## 1. Create the systemd unit file Create a new file:

Paste this:

> 🔑 Replace `my-tunnel-id` with the name or UUID of your tunnel (you can see it in `cloudflared tunnel list`). > You might also need to change `/usr/bin/cloudflared` if it’s installed elsewhere (`which cloudflared` will tell you).

---

## 2. Create a dedicated user (optional, but safer)

---

## 3. Enable and start

---

## 4. Check status & logs

---

## 5. Verify it’s working

- Visit your exposed hostnames (`app.example.com`, `api.example.com`, `signal.example.com`). - Check Cloudflare dashboard → **Zero Trust → Tunnels** to confirm connections. ---

✅ With this, your tunnel will:

- Start on boot. - Auto-restart if it crashes. - Log to syslog (or the custom log file). ---

---

## 1. Create the service file Save as:

Example unit:

---

## 2. Adjust paths and user

- `/usr/bin/node` → run `which node` to confirm the correct path. - `/var/www/signaling/server.js` → change to your actual signaling server location. - `User=www-data` → pick the same user that owns your app files (you can also create a dedicated user like `signaling`). ---

## 3. Enable and start

---

## 4. Check logs

---

## 5. Auto-restart on crash The `Restart=always` + `RestartSec=5s` ensures that if your Node app crashes, systemd will bring it back up in 5 seconds.

---

✅ At this point:

- **cloudflared.service** handles your Cloudflare Tunnel. - **signaling.service** keeps your Node.js WebSocket server alive. - Both start automatically on boot and are monitored by `systemd`. ---

---

## 🔧 Target Setup

- **Frontend React app** → served by Nginx → `app.example.com` - **PHP backend (API)** → PHP-FPM via Nginx → `api.example.com` - **Node.js WebRTC signaling server** → runs separately → `signal.example.com` - **Cloudflare Tunnel** → maps each subdomain to the right local service ---

## 1. PHP-FPM + Nginx config (API + frontend) Example Nginx site config (e.g. `/etc/nginx/sites-available/example.conf`):

`server { listen 3000; server_name app.example.com; root /var/www/react-app/build; index index.html; location / { try_files $uri /index.html; }}server { listen 8080; server_name api.example.com; root /var/www/api/public; index index.php; location / { try_files $uri /index.php; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php/php8.2-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }}`

> Here: > > - React build served on **localhost:3000** > - PHP-FPM API served on **localhost:8080**

---

## 2. Node.js signaling server Say you have `/var/www/signaling/server.js`:

Runs on **localhost:9000**.

---

## 3. Cloudflare Tunnel config (`/etc/cloudflared/config.yml`)

---

## 4. Services managed by `systemd` ### Cloudflared `/etc/systemd/system/cloudflared.service`

### Node signaling server `/etc/systemd/system/signaling.service`

---

## 5. Enable & start everything

---

## 6. Result

- `https://app.example.com` → React app via Nginx - `https://api.example.com` → PHP API via Nginx + PHP-FPM - `wss://signal.example.com` → WebRTC signaling via Node.js - Cloudflare Tunnel maps them securely, with SSL managed by Cloudflare ---

✅ With this, you have an **all-in-one blueprint**: PHP + Nginx + Node + Cloudflare Tunnel living together. You never need to expose raw ports — just map each subdomain to the right service in your `config.yml`.

---

## 🟢 Enhanced Node.js Signaling + Messaging Server

`// server.jsimport { WebSocketServer } from "ws";const wss = new WebSocketServer({ port: 9000 });const rooms = new Map();function broadcast(room, sender, message) { const clients = rooms.get(room) || new Set(); for (let client of clients) { if (client !== sender && client.readyState === client.OPEN) { client.send(JSON.stringify(message)); } }}wss.on("connection", (ws) => { ws.on("message", (raw) => { let data; try { data = JSON.parse(raw); } catch { return; } const { type, room, payload } = data; if (type === "join") { if (!rooms.has(room)) rooms.set(room, new Set()); rooms.get(room).add(ws); ws.room = room; console.log(`Client joined room ${room}`); return; } if (!ws.room) return; switch (type) { case "offer": case "answer": case "ice": // WebRTC signaling broadcast(ws.room, ws, { type, payload }); break; case "chat": // Chat messages broadcast(ws.room, ws, { type: "chat", from: ws._id || "anonymous", payload, }); break; case "file-chunk": // File transfer (chunked) // payload = { filename, chunk, seq, done } broadcast(ws.room, ws, { type: "file-chunk", from: ws._id || "anonymous", payload, }); break; } }); ws.on("close", () => { if (ws.room && rooms.has(ws.room)) { rooms.get(ws.room).delete(ws); if (rooms.get(ws.room).size === 0) { rooms.delete(ws.room); } } });});console.log("Signaling server running on ws://localhost:9000");`

---

## 🟡 React Client Example ### Connecting & joining

### Sending chat

### File transfer (chunked)

`function sendFile(file) { const chunkSize = 16 * 1024; // 16 KB let offset = 0; const reader = new FileReader(); reader.onload = (e) => { const chunk = e.target.result; const done = offset + chunk.byteLength >= file.size; ws.send(JSON.stringify({ type: "file-chunk", room: "chatroom1", payload: { filename: file.name, chunk: Array.from(new Uint8Array(chunk)), seq: offset, done } })); offset += chunk.byteLength; if (!done) readNext(); }; function readNext() { const slice = file.slice(offset, offset + chunkSize); reader.readAsArrayBuffer(slice); } readNext();}`

### Receiving chat / files

---

## 🔑 Key Points

- **WebRTC first** → Use signaling (`offer`, `answer`, `ice`) to establish P2P. - **Fallback to WebSocket** → If NAT/firewall blocks P2P, chat and files still work over the signaling server. - **Chunked files** → Keeps memory usage reasonable; reassemble chunks client-side. ---

✅ This way your Node server is:

- Lightweight signaling hub - Backup chat and file transfer channel ---

---

## 🟡 File Receiving & Reassembly in React ### State for tracking incoming files

### Handle incoming file chunks

`ws.onmessage = (event) => { const data = JSON.parse(event.data); if (data.type === "file-chunk") { const { filename, chunk, seq, done } = data.payload; if (!incomingFiles.current[filename]) { incomingFiles.current[filename] = { chunks: [], received: 0, done: false }; } const fileData = incomingFiles.current[filename]; fileData.chunks.push({ seq, chunk }); fileData.received += chunk.length; if (done) fileData.done = true; // If file is complete, assemble if (fileData.done) { assembleFile(filename); } }};`

---

### Assemble and download file

`function assembleFile(filename) { const fileData = incomingFiles.current[filename]; // Sort chunks by seq (in case they arrive out of order) fileData.chunks.sort((a, b) => a.seq - b.seq); // Convert chunk arrays back into Uint8Array const buffers = fileData.chunks.map(c => new Uint8Array(c.chunk)); // Merge all buffers const totalLength = buffers.reduce((sum, b) => sum + b.length, 0); const merged = new Uint8Array(totalLength); let offset = 0; for (const b of buffers) { merged.set(b, offset); offset += b.length; } // Create a downloadable blob const blob = new Blob([merged]); const url = URL.createObjectURL(blob); // Trigger download const a = document.createElement("a"); a.href = url; a.download = filename; a.click(); // Cleanup URL.revokeObjectURL(url); delete incomingFiles.current[filename];}`

---

## 🔑 How It Works

1. Each chunk arrives as `{ filename, chunk, seq, done }`. 2. We collect them in `incomingFiles`. 3. Once `done = true`, we sort chunks and rebuild into a single `Uint8Array`. 4. Create a `Blob` and trigger a browser download. ---

## ✅ Now your flow is:

- **Send file** → split into chunks, send via WebSocket. - **Receive file** → collect chunks, assemble when complete, prompt download. - Works whether WebRTC P2P succeeds or not.