DEV Community: Aris Kurniawan

Home Labs #2: Setup Raspberry Pi with Cloudflare Zero Trust (Managed Tunnel)

Aris Kurniawan — Wed, 30 Jul 2025 03:09:51 +0000

Want to securely access your Raspberry Pi from anywhere without port forwarding?

This tutorial walks you through setting up Cloudflare Zero Trust with a managed tunnel to expose your Pi’s services safely.

📝 0. Prerequisites: Register Cloudflare Zero Trust

Log in to your Cloudflare Dashboard
Sign up for Zero Trust (Free plan is enough)
Buy a domain (e.g., from Hostinger or Namecheap)
Add the domain to Cloudflare:
- Go to Add a Site in Cloudflare
- Enter your domain
- Choose Quick scan → Free Plan → Continue

Cloudflare will provide nameservers
Update your domain's nameservers via your registrar (e.g., Hostinger)
Wait for DNS propagation (~10 min–24 hours)
Once active, you’re ready to create your tunnel

🔧 1. Install Cloudflare Connector on Raspberry Pi

SSH into your Raspberry Pi and run:

Add GPG key

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null

Add Cloudflare repository

echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main' | sudo tee /etc/apt/sources.list.d/cloudflared.list

Install `cloudflared`

sudo apt update && sudo apt install cloudflared -y

🌐 2. Connect Tunnel to Cloudflare

In Cloudflare Dashboard (Zero Trust → Networks → Tunnels), create a new tunnel.

Then run the command provided, e.g.:

cloudflared service install <TUNNEL-TOKEN>

This registers and installs the tunnel as a systemd service.

⚙️ 3. Enable and Start the Tunnel Service

sudo systemctl enable cloudflared
sudo systemctl start cloudflared

Check status:

sudo systemctl status cloudflared

🌍 4. Install Nginx on Raspberry Pi

sudo apt update
sudo apt install nginx -y

Default page is served on http://localhost:80.

🧭 5. Add a Public Hostname in Cloudflare

In Cloudflare Dashboard:

Go to Zero Trust → Networks → Tunnels
Select your tunnel → click Public Hostnames
Click Add a Hostname
- Hostname: example.com
- Service: http://localhost:80

- Save and deploy

This will expose your Pi’s Nginx page to the internet.

✅ 6. Test It!

Now try visiting:

https://example.com

You should see the default Nginx page securely tunneled through Cloudflare!

🛠️ Optional: Customize Nginx Page

Edit the default HTML:

sudo nano /var/www/html/index.nginx-debian.html

Then restart Nginx:

sudo systemctl restart nginx

🔒 7. Access Securely with Zero Trust Policies

Want to restrict access to only you or your team?

Go to Zero Trust → Access → Applications
Add a new Web or SSH application
Set rules: e.g., Google login, email domain, OTP, etc.

Now, services like SSH or a web dashboard can only be accessed by authenticated users.

🚀 Why Use Cloudflare Tunnel?

✅ No port forwarding

✅ Works behind NAT/CGNAT

✅ End-to-end TLS by default

✅ Easy dashboard management

✅ Supports access policies (SSO, OTP, etc.)

Happy homelabbing! 🧪🌐

Home Labs #1: Install Raspberry Pi OS Lite (64-bit) on Raspberry

Aris Kurniawan — Wed, 30 Jul 2025 03:01:06 +0000

Want to set up a headless server or lightweight IoT project using Raspberry Pi?

This guide walks you through installing the 64-bit Lite version of Raspberry Pi OS on a Raspberry Pi 3 Model B+.

🧰 1. Download Raspberry Pi Imager

👉 https://www.raspberrypi.com/software/

Choose the installer based on your OS:

Windows → .exe
macOS → .dmg
Linux → .deb / .rpm

Install it as usual.

💾 2. Prepare microSD Card & Raspberry Pi

Use at least an 8GB microSD (Recommended: 16GB or more).
In this tutorial, I use a 32GB microSD.
Make sure you have a microSD card reader ready.

🚀 3. Launch Raspberry Pi Imager

Insert the microSD card into your computer.
Open Raspberry Pi Imager.

🧠 4. Choose OS

Click "Choose OS"
Select: Raspberry Pi OS (Other) → Raspberry Pi OS Lite (64-bit)

⚠️ "Lite" means no desktop environment — it's CLI only!

💽 5. Choose Storage

Click "Choose Storage"
Select your microSD card

⚙️ 6. Configure Settings (Optional but Recommended)

Click the gear icon ⚙️ at the bottom right to set:

✅ Enable SSH
👤 Set username and password
📶 Enter your WiFi SSID and password
🌍 Set Locale, Timezone, and Keyboard layout

📝 These settings will apply automatically when you boot. No manual config needed!

📥 7. Flash the OS

Click Write
Wait for the process to complete
Eject the microSD card safely

🧾 8. Boot Your Raspberry Pi

Insert the microSD card into your Raspberry Pi
Power it up and wait for it to boot
Login using terminal or SSH (if enabled)

Username: pi
Password: [your password]

🔗 Next Up: Home Labs #2: Setup Raspberry Pi with Cloudflare Zero Trust (Managed Tunnel)

RabbitMQ with Web MQTT Plugin vs. Node.js : Performance and Memory Usage Comparison

Aris Kurniawan — Tue, 29 Oct 2024 05:37:27 +0000

Introduction

In applications that require real-time, efficient data communication, two commonly used technologies are RabbitMQ with the Web MQTT Plugin and Node.JS (Socket.IO). RabbitMQ with the Web MQTT Plugin allows for communication using the MQTT protocol over WebSockets, while Node.JS (Socket.IO) provides a JavaScript runtime that efficiently handles events in real-time. This article compares the performance and memory usage of RabbitMQ with the Web MQTT Plugin and Node.JS (Socket.IO), particularly for handling 36 events such as notifications, data reloads, and queue management. It also analyzes whether this setup is optimal or requires further adjustments.

Overview of RabbitMQ with Web MQTT Plugin

What is RabbitMQ with Web MQTT Plugin?

RabbitMQ is a message broker that supports multiple protocols, including MQTT. The Web MQTT Plugin in RabbitMQ enables clients to communicate with the broker via WebSockets using the MQTT protocol. This is particularly useful for web-based applications that need real-time, two-way communication, such as notifications or data queuing.

Key Functions of RabbitMQ with Web MQTT Plugin

WebSocket Communication: Allows web-based clients to use MQTT over WebSockets, enabling direct communication between the server and browser clients.
Queue and Topic Management: Supports queue and topic configurations for effective message traffic management.
Retained Messages: Stores the last message so that newly connected clients can receive the latest information without re-requesting.
High Scalability for Lightweight Messages: Ideal for applications sending real-time notifications with low latency, like data reloads and notification queues.

Overview of Node.JS (Socket.IO)

What is Node.JS (Socket.IO)?

Node.JS (Socket.IO) is a JavaScript runtime built on Chrome's V8 engine, designed to handle non-blocking I/O operations. In this context, server.js is used to manage notification events, data reloads, and queues via WebSocket or HTTP protocols, depending on the application requirements.

Key Functions of Node.JS (Socket.IO)

Non-Blocking I/O: Allows handling multiple requests simultaneously without blocking other operations, ideal for event-driven applications.
Event-Driven Architecture: Reduces resource consumption by running code only when specific events occur.
Two-Way Communication: Node.JS (Socket.IO) is well-suited for real-time applications that require continuous two-way communication between the client and server via WebSocket.
Efficiency and Responsiveness: Efficiently handles large numbers of I/O-based connections, such as managing notifications and queues.

Challenges and Limitations

RabbitMQ with Web MQTT Plugin

Resource Consumption: RabbitMQ, especially with the Web MQTT Plugin, can consume a lot of memory and CPU to handle high message volumes. In this test, RabbitMQ showed a CPU usage of about 5.2%, which is relatively high but reasonable for a message broker.
Latency under High Load: Under extremely high loads, there might be a slight latency in message delivery, which can impact applications heavily reliant on real-time performance.
More Complex Configuration: Compared to Node.JS (Socket.IO), RabbitMQ with Web MQTT Plugin requires more initial configuration, especially for setting up queues, topics, and bindings.

Node.JS (Socket.IO)

Single-Threaded: Node.JS (Socket.IO) uses a single thread, so CPU-intensive operations can become a bottleneck. In testing, CPU usage reached 50.5%, which is high for a single-threaded application and may cause delays.
Memory Leaks: If not managed properly, a Node.JS (Socket.IO) application can experience memory leaks, especially in long-running applications with high event activity.
Dependency on External Libraries: Node.JS (Socket.IO) often relies on many third-party libraries which, if not maintained, could affect overall performance.

Performance Analysis with Glances

Overview of the Processes

RabbitMQ with Web MQTT Plugin:
- CPU usage: 5.2%
- Memory usage: 2.8% (5.97 GB Virtual, 887 MB Resident)
- Uptime: 18 hours and 26 minutes
Node.js (server.js):
- CPU usage: 50.5%
- Memory usage: 0.4% (1.04 GB Virtual, 257 MB Resident)
- Uptime: 4 hours and 1 minute

These numbers give an initial impression of how each service is consuming resources.

CPU Usage Comparison

RabbitMQ is relatively light on CPU, only consuming 5.2%, even though it is managing 36 events (notifications, data reloads, and queue management tasks). This low CPU usage is characteristic of RabbitMQ, as it is optimized for message handling and asynchronous communication.
Node.js (server.js) is consuming significantly more CPU, at 50.5%. This high usage suggests that server.js may be handling more compute-intensive tasks, possibly related to managing WebSocket connections, processing requests, or handling real-time data. This high CPU usage could impact the server’s performance under higher load or when additional applications are running concurrently.

Memory Usage Comparison

RabbitMQ shows higher memory usage with 887 MB resident memory, which is reasonable for a messaging broker handling continuous WebSocket connections and MQTT messaging through the Web MQTT Plugin. Its virtual memory footprint (5.97 GB) is high, but this is typically due to pre-allocation and not actual memory in use.
Node.js (server.js) has a much lower memory footprint, with only 257 MB resident memory. Node.js applications generally have a small memory footprint but can grow based on the complexity of tasks. Its relatively low memory usage here suggests it is well-optimized for handling tasks, though the high CPU usage may indicate some inefficiencies in CPU-bound tasks.

Uptime and Stability

RabbitMQ has an uptime of over 18 hours, and it’s using minimal CPU, indicating that it is stable and efficient over longer periods.
Node.js (server.js) has only been running for 4 hours but is consuming a large percentage of the CPU. If this CPU usage trend continues, it could become a bottleneck and may require restarting or optimization, especially for a production environment that expects high uptime.

Implications on System Performance

RabbitMQ with Web MQTT Plugin appears to be less demanding on the CPU and moderate in memory usage. This makes it well-suited for applications that require high-throughput messaging with minimal latency. The current resource usage does not seem excessive, but monitoring memory over longer uptime periods is advised, as message brokers can accumulate memory usage with a high volume of persistent messages.
Node.js (server.js) at 50.5% CPU usage suggests that it could be CPU-bound, which could affect other processes or reduce system responsiveness under high load. If server.js handles WebSocket connections, optimizing the code for asynchronous tasks or offloading some processes could reduce CPU usage. High CPU usage in Node.js might also suggest the need for load balancing across multiple instances, especially if the server needs to scale to handle more events.

Recommendations for Optimization

RabbitMQ: Although RabbitMQ's memory usage is moderate, monitoring is recommended to ensure it doesn't grow unbounded over time, especially with increased event volumes.
Node.js (server.js):
- Optimize CPU Usage: Review code for any CPU-intensive operations or synchronous code that might benefit from asynchronous handling.
- Benchmark and Load Test: Conduct stress tests to see if server.js CPU usage increases further with more concurrent events. This could help identify specific code bottlenecks.
- Scaling: Consider horizontal scaling for server.js by running multiple instances behind a load balancer, especially if high CPU usage persists under typical workloads.

Latency

RabbitMQ with Web MQTT Plugin: Generally has low latency, especially in real-time communication for lightweight messages, which is ideal for notification and data reload scenarios.
Node.JS (Socket.IO): Low latency, but high CPU load can introduce delays, especially if the application handles CPU-intensive events.

Conclusion

RabbitMQ with Web MQTT Plugin is a good choice for applications that require real-time message handling, particularly for the 36 events including notifications, data reloads, and queue management. With around 5.2% CPU usage, RabbitMQ is stable for high message delivery loads, especially when low latency and two-way communication are needed.

Node.JS (Socket.IO) is suitable for applications needing an event-driven architecture with two-way communication. However, with CPU usage reaching 50.5%, applications may face limitations in scenarios requiring high CPU processing. Therefore, solutions like clustering or worker threads could be considered if usage continues to grow.

Overall:

RabbitMQ with Web MQTT Plugin: Highly recommended for applications with large messaging and notification needs. It also simplifies managing connections and messages through WebSockets efficiently.
Node.JS (Socket.IO): Ideal for web applications that require fast responses and two-way communication but may require further adjustments to reduce CPU load.

With performance analysis through Glances, both technologies have demonstrated results by capturing the highest CPU usage values from each process, which is quite suitable for this scenario. However, regular monitoring is necessary to prevent spikes in CPU or memory usage that could impact the overall system performance.

please correct me if I'm wrong 😁

Note : If you have any suggestions for testing, please comment below, and feel free to recommend other tools for real-time communication between the client and server 😊.

Documentation:
https://www.rabbitmq.com/docs/web-mqtt
https://socket.io/docs/v2/