Migrating VPS Servers

from Debian to Alpine Linux

Testing domain not needed. Use the real domain name throughout by temporarily overriding DNS locally via /etc/hosts. This avoids all URL path issues. Since sites are not yet fully operational, a direct cutover with same-day rollback capability is also viable.

Why We’re Doing This

Debian has become an increasingly poor long-term fit:

APT now has a hard Rust dependency (announced late 2025, landing ~May 2026) — the core package manager now drags in the entire Rust toolchain
Governance issues — significant changes being made unilaterally by individual maintainers without community consensus
Creeping bloat — systemd scope, Rust-by-osmosis across infrastructure packages

Alpine Linux aligns much better with our values: minimalism, security, low maintenance, no forced dependencies, and an independent project with no corporate sponsor.

Why Alpine Over Other Alternatives

Distro	Verdict
Alpine Linux	✅ Best for new/fresh servers — minimal attack surface, tiny footprint, solid LEMP support
Devuan	✅ Best for in-place migration of existing servers — Debian without systemd, same `apt` tooling
Debian Stable	⚠️ Viable short-term only — the trend is bad and won’t reverse
Void Linux	❌ Rolling release is a poor fit for production web servers
FreeBSD	✅ Excellent long-term platform but migration cost is high

Our chosen path: Alpine Linux for all servers going forward.

The Migration Strategy (Zero-Risk Approach)

We do NOT migrate the existing Debian servers in-place.
Instead, we use a parallel build approach:

Provision a new Alpine VPS alongside the existing server
Build the full stack (nginx, PHP-FPM, MariaDB, Certbot, fail2ban, cron, SSH) on the new server
Copy all data — web files, databases, configs, cron jobs
Test thoroughly — point a test domain or local /etc/hosts entry at the new server before going live
Flip DNS to cut over — old server stays live throughout
Decommission the old Debian server only once confirmed 100% working

At no point are the live sites at risk. DNS cutover is the only “live” moment, and it’s reversible in minutes.

Backup Layers (Before Any Work Begins)

VPS provider snapshot — full disk image, one-click restore (~5 min recovery time). This is the nuclear undo button.
Database dump — mysqldump --all-databases to a file, copied offsite
Web files — tar or rsync of /var/www/
Configs — archive of /etc/nginx/, /etc/php*/, /etc/fail2ban/, crontabs
Existing backup system already covers this (servarica1 + dr4 destinations)

What Could Go Wrong (And Why It’s Low Risk)

Risk	Likelihood	Mitigation
PHP extension not in Alpine repos	Low	All common extensions available; verify before starting
musl libc breaks something	Very low for standard LEMP	Fallback: use Devuan instead
Config path differences	Moderate	Caught during testing phase, before DNS cutover
Something missed during migration	Moderate	Old server stays live — flip DNS back if needed

Suggested Site Order (Staged Rollout)

roflfaucet.com — trial run, learn the process
clickforcharity.net — once process is proven
directsponsor.net — last (most critical)

Pre-Migration Checklist (Gather This Before Starting)

Before beginning work on any server, collect the following:

VPS provider name (for snapshot procedure)
Whether sites share a server or are on separate VPSes
Current PHP version: php --version
Installed PHP extensions: php -m
List of active cron jobs: crontab -l and ls /etc/cron.d/
Any non-standard software (custom binaries, proprietary tools, monitoring agents)
Current nginx config: nginx -T
Database list: mysql -e "SHOW DATABASES;"

Time Estimate

Task	Estimated Time
Snapshot + backups	30 min
Alpine VPS setup + base stack	1–2 hours
Config transfer and adjustment	1–2 hours
Testing	1–2 hours
DNS cutover + verification	30 min
Total per server	~4–6 hours

Plan for a full day per server. Don’t start on a Friday.