DEV Community: GSVPS

How to Build a Self-Hosted Remote Desktop with Cloudflare Workers and WebRTC

GSVPS — Sun, 05 Jul 2026 02:15:33 +0000

If you want a self-hosted remote desktop without paying for a relay server, a Cloudflare-based setup is one practical option to evaluate.

A recent GSVPS tutorial walks through deploying GsDesk, an open-source remote desktop project that can run on Cloudflare Workers or on a VPS. The Cloudflare version uses Workers for the API layer, authentication, and signaling, while the desktop stream itself is designed to go peer to peer over WebRTC instead of being relayed through the server.

That separation is the main idea worth paying attention to. It reduces bandwidth pressure on the backend, but it also means you still need to think about client compatibility, NAT traversal, and what happens when direct peer connectivity is limited.

What this deployment includes

According to the original tutorial, the Cloudflare deployment uses these building blocks:

Cloudflare Workers for the application entry point and request handling
D1 for relational data
KV for lightweight key-value data
R2 for object storage
Durable Objects for coordination and signaling state

The article also describes a browser control path and a Windows client, with the server handling API requests, authentication, and WebSocket signaling rather than forwarding the actual remote desktop video stream.

Before you deploy

The original guide is most useful if you already have these prerequisites in place:

A Cloudflare account with access to Workers and the related storage products
A domain or worker route you can publish to
Node.js and the Cloudflare tooling needed to build and deploy the project
A clear plan for your controller token, JWT secret, and any other deployment secrets

If you are testing this architecture for the first time, it is worth treating the deployment as a lab environment first. Verify the control plane, then validate remote access behavior from the networks and devices you actually care about.

What to verify after deployment

The most practical part of the source tutorial is the verification checklist. After deployment, check at least three things:

The root URL responds successfully, so you know the worker is reachable.
The web control path loads correctly, so static assets and route configuration are in sync.
The client can connect with the expected API address and token, so the control plane is working end to end.

If the web control path has been changed from its default value, rebuild the web assets before redeploying. Otherwise, mismatched paths can lead to missing static files or broken routes.

Where this architecture fits well

This kind of design can make sense when you want:

A low-cost control plane for a personal or small-team remote access setup
Browser-based control alongside a desktop client
A self-hosted option that does not require a traditional always-on relay server for screen transport

It is less of a drop-in choice if you need guaranteed connectivity in heavily restricted network environments, because peer-to-peer designs still depend on the surrounding network conditions.

Cloudflare Workers vs. VPS self-hosting

The source material notes that GsDesk also supports VPS self-hosting. In practice, the choice is mostly about operational tradeoffs.

Use the Cloudflare route if you want a managed edge control plane and are comfortable with the Cloudflare product stack.

Use the VPS route if you want more conventional server control, easier low-level customization, or a setup that is less tied to one platform's services.

Final note

If you want the full deployment walkthrough, including the original build and deployment flow, read the source article from GSVPS here:
https://www.gsvps.com/articles/news-20

Original source: GSVPS. This adaptation keeps the original relationship visible and does not claim hands-on test results beyond what the source describes.

How to Migrate a Linux VPS with rsync and Keep Downtime Low

GSVPS — Fri, 03 Jul 2026 04:49:46 +0000

Moving a Linux VPS to a new server is usually less about one command and more about sequencing. If you copy files too early, your data goes stale. If you switch DNS too soon, users land on an incomplete system. If you try to clone everything at once, you can easily bring across temporary paths and host-specific settings that do not belong on the new machine.

This article is adapted from a GSVPS tutorial on Linux VPS migration. Original source:
https://www.gsvps.com/articles/linux-vps-ru-he-qian-yi-dao-xin-fu-wu-qi-2026-zui-xin-rsync-jiao-cheng-ji-hu-1-1-wu-sun-qian-yi-wang-zhan-docker-he-shu-ju

The practical goal is not "zero risk." It is a controlled migration with a short write-free window and a clear rollback path.

1. Start with an inventory, not with `rsync`

Before copying anything, write down what actually lives on the old server:

web roots such as /var/www
Nginx or Apache config
application env files and secrets
database engines and database names
Docker Compose files, bind mounts, and named volumes
cron jobs
SSL certificate paths
firewall rules and open ports

Also note what should not be copied blindly:

/proc, /sys, /dev, /run
temporary files
mounted backup disks
bootloader state
network interface settings tied to the old host

That distinction matters. A migration usually fails because someone copied "everything" without deciding what "everything" meant.

2. Prepare the new server first

The destination host should be reachable and basically ready before any final sync:

create the admin user you will keep using
add SSH keys
install the packages your stack needs
confirm time, hostname, and firewall rules
make sure the target disks are mounted where you expect

Useful early checks:

hostnamectl
ip addr
df -h
lsblk
systemctl --failed

If the new server cannot pass basic health checks, do not start the migration yet.

3. Lower DNS TTL before the cutover

If a site or API is moving, lower DNS TTL well before the migration window. That gives you a faster switchover later and reduces the period where some users still hit the old host.

This does not eliminate downtime by itself. It only shortens propagation pain when the final change happens.

4. Use `rsync` for repeatable file transfer

For website files, application directories, and many bind-mounted workloads, rsync is still one of the most useful tools because you can run it more than once.

A common pattern is:

run an initial sync while services are still live
validate the new server
stop write-heavy services briefly
run one final sync
switch traffic

Example for a web root:

sudo rsync -aHAXx --numeric-ids --delete --info=progress2 \
  /var/www/ user@NEW_SERVER:/var/www/

Flags here matter:

-a preserves recursion, permissions, timestamps, and symlinks
-HAX helps preserve hard links, ACLs, and xattrs where relevant
-x keeps the copy on one filesystem
--numeric-ids avoids UID or GID name mismatches
--delete keeps the destination aligned with the source

Do not use --delete casually against the wrong path. Verify both source and destination before pressing Enter.

5. Treat databases separately from static files

If the application writes to MySQL, MariaDB, or PostgreSQL, file sync alone is not enough.

Typical export commands:

mysqldump --single-transaction --routines --triggers DB_NAME > db.sql
pg_dump -Fc DB_NAME > db.dump

Those should be imported on the new server after the database service is prepared.

For busy applications, the cleanest cutover is usually:

enable maintenance mode or temporarily stop writes
take the final dump or replication-consistent copy
import on the new host
run the final file sync

That write-free window is where you win or lose data consistency.

6. For Docker, migrate config and data intentionally

If the workload runs under Docker Compose, copy the Compose files, env files, and persistent data paths deliberately rather than assuming the container image is the hard part.

A simple sequence is:

docker compose config
docker compose down
sudo rsync -aHAX --delete /srv/app/ user@NEW_SERVER:/srv/app/

Then on the new server:

docker compose pull
docker compose up -d
docker compose ps

If you use named volumes instead of bind mounts, inspect where the actual persistent data lives before moving anything.

7. Validate before DNS cutover

Before sending production traffic to the new host, verify:

the web server starts cleanly
the application can connect to its database
file permissions are correct
scheduled jobs exist where needed
TLS certificates are present or can be reissued
uploads, login flows, and API writes still work

Useful checks include:

nginx -t
systemctl status nginx
docker compose logs --tail=100
ss -tlnp
curl -I http://127.0.0.1

If the service stack is not healthy locally, changing DNS only hides the real problem behind a network symptom.

8. Keep rollback simple

Do not tear down the old server immediately after cutover.

Keep it available long enough to:

compare logs
recover missed files
re-check database state
reverse DNS if a critical issue appears

A migration plan is better when rollback is boring.

Final takeaway

The original GSVPS article focuses on using rsync to move a Linux VPS with minimal disruption. That is a sensible base, but the real success condition is broader: prepare the target host, separate static files from live data, run repeatable syncs, and keep the final write window short and explicit.

If you treat migration as a sequence instead of a copy job, rsync becomes a reliable part of the process rather than a gamble.

VPS Hosting Performance Comparison: Key Metrics for 2026

GSVPS — Thu, 02 Jul 2026 20:17:11 +0000

Choosing a VPS provider is one of the most critical decisions for developers and system administrators. Here's what I've learned from benchmarking various providers:

CPU Performance Matters

Single-core performance can vary significantly. Look for modern AMD EPYC or Intel Xeon processors with high clock speeds rather than just core count.

Storage: NVMe vs SSD

NVMe storage offers 3-5x faster read/write speeds compared to traditional SSD. If your application is I/O intensive, this is non-negotiable.

Network Throughput

Test with iperf3 before committing. Some providers advertise 1Gbps but deliver far less during peak hours. Check real user reviews and independent benchmarks.

Price-to-Performance Ratio

After extensive testing, I found that providers like GSVPS (www.gsvps.com) offer excellent value with NVMe storage and generous bandwidth at competitive rates. They're worth checking out if you're shopping around.

Essential Benchmarks to Run

UnixBench for overall system performance
fio for disk I/O
iperf3 for network throughput
yabs.sh for a quick all-in-one test

Always test before you commit to a long-term plan. The hosting market in 2026 is competitive, which means better options for informed buyers.

A Practical Linux Operations Roadmap for 2026

GSVPS — Thu, 02 Jul 2026 02:25:50 +0000

Linux operations is a wide field, and most beginners get stuck for the same reason: they try to learn everything at once. A more useful approach is to build a sequence. Start with system basics, add one service stack, then add automation, security, and monitoring.

This post is adapted from a GSVPS tutorial on Linux operations. The original article is here:
https://www.gsvps.com/articles/linux-yun-wei-ru-men-jiao-cheng-2026-cong-xi-tong-guan-li-docker-nginx-dao-ansible-quan-mian-xue-xi-zhi-nan

If you are just getting started with Linux server work, this is the order that makes the rest of the stack easier to understand.

1. Start with core system habits

Before touching Docker, Nginx, or Ansible, get comfortable with a few system-level tasks:

navigating the filesystem
reading logs
managing users and groups
checking disk, memory, and network state
editing configuration files safely

The point is not to memorize commands. The point is to recognize where to look when something breaks.

Examples worth practicing early:

ls, cp, mv, find, grep
ip addr, ip route, ss -tlnp
df -h, free -h, lsblk
systemctl status
journalctl -u <service>

If you can answer "what changed?", "what is listening?", and "what is failing?" on a Linux host, you already have useful operational skill.

2. Learn one web stack end to end

A beginner does not need five deployment patterns. One is enough at first.

The classic entry point is a small LNMP-style stack:

Linux
Nginx
MySQL or PostgreSQL
PHP or another app runtime

The value of this exercise is not the exact stack choice. It is the experience of wiring services together:

install packages
enable services at boot
check listening ports
inspect logs after config changes
test locally before exposing a service publicly

Even if you do not plan to run PHP in production, Nginx plus one database teaches the core operational loop: configure, reload, verify, and debug.

3. Add container basics only after the host makes sense

Docker helps a lot, but it does not replace Linux fundamentals. If you cannot inspect storage, networking, and logs on the host, containers usually make debugging harder.

Once the host feels familiar, Docker becomes much easier:

run a service in isolation
map ports intentionally
persist data with volumes
read container logs
inspect environment variables and startup commands

Useful first checks include:

docker ps -a
docker logs <container>
docker inspect <container>
docker stats

At this stage, simple Compose files are enough. The goal is to understand service dependencies, not to jump straight into orchestration.

4. Treat automation as the next multiplier

Manual work teaches you what matters. Automation keeps you from repeating it badly.

After you can update a host, deploy a web service, and troubleshoot a failed restart by hand, start learning Ansible. It is still one of the most practical ways to manage small and medium Linux fleets because it keeps the workflow readable:

define inventory
describe desired state
run repeatable changes over SSH

Good beginner automation targets:

install baseline packages
create users and SSH keys
deploy Nginx config
push application files
restart services only when config changes

If you can turn a one-hour manual rebuild into an idempotent playbook, you have crossed an important line from administration into operations engineering.

5. Security should be operational, not decorative

A lot of "security hardening" advice is either too vague or too heavy for small deployments. For most Linux VPS and small server environments, the basics still matter most:

disable direct root SSH login where possible
prefer SSH keys over passwords
limit exposed ports
keep services updated
watch authentication logs
use a firewall with rules you can explain
add Fail2ban or equivalent controls for repeated login abuse

Two practical rules help here:

First, do not enable controls you cannot recover from remotely.

Second, log review is part of security. If you never read auth logs, service logs, or ban events, you are not really verifying that your controls work.

6. Monitoring starts with simple questions

Many teams jump straight to dashboards. Early on, it is better to build the habit of checking a system with a few direct questions:

Is the service up?
Is it reachable on the expected port?
Is the host out of disk or memory?
Did a recent change increase errors?

That is why tools like journalctl, ss, df, free, top, and iostat still matter. They help you answer the first operational questions quickly.

When your environment grows, you can layer better visibility on top:

Glances for quick host inspection
Prometheus for metrics collection
Grafana for dashboards

The key is not the tool count. The key is whether you can move from symptom to evidence without guessing.

7. Build a repeatable weekly routine

Linux operations gets easier when maintenance becomes routine instead of reactive.

A simple weekly checklist is enough for many small environments:

Check load, memory, disk, and service status.
Review authentication and web service logs for anomalies.
Apply pending security updates on a controlled schedule.
Confirm backups are recent and restorable.
Verify SSL certificate and domain-related expiry risk.

This is not glamorous work, but it prevents a large share of avoidable outages.

8. What to learn after the basics

Once the first layer feels natural, the next useful topics are:

WireGuard or Tailscale for private access
log rotation and retention
backup automation
nftables or a clearer firewall model
CI/CD pipelines
high-availability patterns
Kubernetes only when you have a real need for it

The common mistake is skipping directly to complex tooling before learning service behavior on one machine. In practice, strong single-host discipline scales better than weak multi-node complexity.

Final takeaway

The original GSVPS article covers a wide range of Linux operations topics, from command-line basics to Docker, databases, automation, and hardening. The most practical way to use that kind of guide is not to copy every command into one server. It is to turn it into a learning order.

If you are early in your Linux operations journey, focus on this sequence:

system basics
one service stack
container basics
automation
security and monitoring
disciplined maintenance

That path is not the fastest-looking one, but it is usually the one that produces fewer fragile systems.

How to Enable and Verify TCP BBR on Linux

GSVPS — Wed, 01 Jul 2026 16:00:59 +0000

BBR is a TCP congestion-control algorithm that estimates bandwidth and round-trip time. It can improve throughput on long-distance or high-latency TCP connections, but it is not a universal speed boost. If the bottleneck is CPU, storage, a bandwidth cap, a poor route, or UDP traffic, BBR may make little difference.

Check support first

uname -r
sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc

Linux 4.9 or newer is generally required. Continue only if the available algorithms include bbr. If BBR is missing, editing sysctl configuration will not help; upgrade to a supported kernel first.

Enable BBR safely

Back up the configuration and check for conflicting entries:

sudo cp /etc/sysctl.conf /etc/sysctl.conf.bak
grep -nE 'net.core.default_qdisc|net.ipv4.tcp_congestion_control' /etc/sysctl.conf

If the keys are absent, add:

net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr

Then load the configuration:

sudo sysctl -p

Modern Ubuntu, Debian, CentOS Stream, Rocky Linux, and AlmaLinux installations usually need no extra steps when the running kernel supports BBR. CentOS 7 often has an older default kernel, so check the actual kernel.

Verify the active setting

sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
lsmod | grep bbr

The important result is net.ipv4.tcp_congestion_control = bbr. Some systems may not show an obvious lsmod entry even when BBR is active.

Measure instead of guessing

Compare before and after results using the same destination, file size, time window, and route. Look at sustained throughput, rsync or SCP stability, retransmissions, and performance over high-latency links. A single page refresh is not a useful benchmark.

If sysctl -p reports an invalid argument, recheck the available algorithms and look for duplicate settings in /etc/sysctl.conf and /etc/sysctl.d/. If the value changes after reboot, another sysctl file, cloud-init, a control panel, or an optimization script may be overriding it.

Roll back

sudo cp /etc/sysctl.conf.bak /etc/sysctl.conf
sudo sysctl -p

The practical rule: verify kernel support, back up the configuration, enable BBR, confirm the active value, and measure under repeatable conditions.

The original GSVPS guide includes distro-specific commands and a status-check script.

Building a Self-Hosted Remote Desktop with Cloudflare Workers and WebRTC

GSVPS — Mon, 29 Jun 2026 18:51:02 +0000

Running a remote desktop service usually means maintaining a relay server with enough bandwidth to carry every screen frame. That is expensive and creates an obvious bottleneck. A different design is to separate the control plane from the media plane:

Cloudflare Workers handles the API, authentication, and WebSocket signaling.
D1, KV, R2, and Durable Objects provide persistence and coordination.
WebRTC sends screen, keyboard, mouse, and clipboard traffic directly between peers.
An optional VPS deployment replaces the Cloudflare backend with Node.js, SQLite, and Docker.

GsDesk is an open-source implementation of this architecture. Its server helps two endpoints find and authenticate each other, but it does not relay the desktop video stream.

Why this architecture matters

The expensive part of remote desktop software is continuous media traffic. If a Worker only processes API requests and signaling messages, the majority of bandwidth avoids the server entirely. That makes a free or low-cost serverless control plane practical for personal remote access, home labs, NAS administration, and lightweight IT support.

There is an important limitation: peer-to-peer connectivity depends on the network conditions of both endpoints. Strict NAT or firewall policies can prevent direct connections. A production deployment should therefore test the networks it needs to support and decide whether a TURN relay is required as a fallback.

Fast deployment path

Clone the project and install its dependencies:

git clone https://github.com/gsvps/gsdesk.git
cd gsdesk
npm install

Authenticate Wrangler and deploy the Cloudflare backend:

npx wrangler login
npm run deploy:cloudflare

After deployment, verify two separate routes:

https://your-domain.example/ should return success; this is the health endpoint, not the control interface.
https://your-domain.example/app/ should open the browser control interface. The path is configurable through WEB_APP_PATH.

The Windows client exposes its local UI at http://127.0.0.1:19527. Configure the deployed API URL and the controller JWT secret, enable incoming control on the target device, and connect with its eight-digit device ID plus either a one-time or permanent password.

Self-hosting on a VPS

If you prefer to keep the control plane off Cloudflare, the same protocol can run on a Linux VPS:

docker compose up -d --build

The self-hosted backend uses Node.js, SQLite, local file storage, and WebSockets. This option is useful when you need full control over persistence, logs, or network policy. It does not change the core design: desktop media still uses WebRTC peer-to-peer transport.

Security checklist

Before exposing an instance to the internet:

Replace CONTROLLER_JWT_SECRET with a strong random value.
Treat the device ID as an identifier, not a password.
Keep Ed25519 device private keys on the endpoint.
Use OTPs for temporary access and avoid storing them.
Disable automatic acceptance when users should approve each session.
Keep API rate limiting and failed-login controls enabled.
Use HTTPS/WSS and review any custom reverse-proxy configuration.
Restrict access to the browser control route when your use case permits it.

WebRTC protects media with DTLS, but transport encryption does not compensate for weak controller secrets or overly permissive access settings. Authentication and endpoint security remain part of the threat model.

What to validate after deployment

A basic smoke test should cover more than the home page:

GET /              -> success
GET /api/health    -> API status and web_app_entry
GET /app/          -> browser controller

Then test device registration, a complete remote session, clipboard synchronization, file transfer, reconnect behavior, and connectivity from the actual networks you intend to use.

The full tutorial includes configuration variables, API routes, directory layout, Windows client build instructions, Cloudflare and VPS deployment details, and troubleshooting notes:

Original guide: https://www.gsvps.com/articles/tutorials-22

Disclosure: I am affiliated with GSVPS, which publishes the original tutorial and maintains the linked GsDesk project.

DEV Community: GSVPS

How to Build a Self-Hosted Remote Desktop with Cloudflare Workers and WebRTC

What this deployment includes

Before you deploy

What to verify after deployment

Where this architecture fits well

Cloudflare Workers vs. VPS self-hosting

Final note

How to Migrate a Linux VPS with rsync and Keep Downtime Low

1. Start with an inventory, not with rsync

2. Prepare the new server first

3. Lower DNS TTL before the cutover

4. Use rsync for repeatable file transfer

5. Treat databases separately from static files

6. For Docker, migrate config and data intentionally

7. Validate before DNS cutover

8. Keep rollback simple

Final takeaway

VPS Hosting Performance Comparison: Key Metrics for 2026

CPU Performance Matters

Storage: NVMe vs SSD

Network Throughput

Price-to-Performance Ratio

Essential Benchmarks to Run

A Practical Linux Operations Roadmap for 2026

1. Start with core system habits

2. Learn one web stack end to end

3. Add container basics only after the host makes sense

4. Treat automation as the next multiplier

5. Security should be operational, not decorative

6. Monitoring starts with simple questions

7. Build a repeatable weekly routine

8. What to learn after the basics

Final takeaway

How to Enable and Verify TCP BBR on Linux

Check support first

Enable BBR safely

Verify the active setting

Measure instead of guessing

Roll back

Building a Self-Hosted Remote Desktop with Cloudflare Workers and WebRTC

Why this architecture matters

Fast deployment path

Self-hosting on a VPS

Security checklist

What to validate after deployment

1. Start with an inventory, not with `rsync`

4. Use `rsync` for repeatable file transfer