System Migration (notes)
VPS OS Comparison:
Debian Alternatives for Web Hosting Infrastructure
Audience: directsponsor.net / roflfaucet.com / clickforcharity.net
Date: July 2026 | Horizon: 3β5 years
Executive Summary
Your concerns about Debian are well-founded and corroborated by documented events (the APT/Rust controversy, governance friction). For a web hosting workload of your type β nginx/PHP/MariaDB-based websites with moderate complexity β you have excellent alternatives. The Debian ecosystem is not the only safe harbour, and in some respects it is becoming a less safe one.
IMPORTANT
Top Recommendations: Devuan (primary) or Alpine Linux (secondary, if you’re willing to invest a small amount of initial setup time). Both are strongly suited to your workload. Full rationale and migration plan below.
Your Workload Profile
Based on your sites (clickforcharity.net, directsponsor.net, roflfaucet.com), the typical stack is:
- Nginx as web server / reverse proxy
- PHP-FPM for dynamic pages
- MariaDB / SQLite for data storage
- Bash / cron for background jobs and automation
- Certbot / Let’s Encrypt for TLS
- Cockpit for server management UI
- Standard monitoring / backup scripts
This is a textbook LEMP stack. It is exceptionally well-supported on every distro evaluated below. You have essentially zero stack compatibility concerns β this is the easy part.
Candidate Evaluation
1. Devuan
Overview: Devuan is Debian with systemd removed, using SysVinit, OpenRC, or runit as init. It tracks Debian testing/stable closely and is binary-compatible.
| Dimension | Assessment |
|---|---|
| Stability | β Excellent β inherits Debian’s “boringly stable” reputation |
| Security | β Receives Debian security patches nearly simultaneously |
| Package availability | β Full Debian repo access; near-identical package selection |
| Migration effort | β Very low β in-place migration from Debian is well-documented and usually works cleanly |
| Maintenance burden | β Low β same cadence as Debian Stable (releases every ~2β3 years, LTS support) |
| Future risk | β Low β no Rust in init/APT by default; community is explicitly anti-bloat |
| VPS provider support | β οΈ Moderate β many providers don’t offer Devuan images; may need to migrate from Debian or use a custom image |
| Community size | β οΈ Small but focused, experienced, and ideologically aligned with your goals |
Pros:
- Drops systemd entirely β eliminates the single biggest source of Debian “scope creep”
- Same
apt/.debecosystem you already know - Scripts, configs, and muscle memory transfer 1:1
- Traditional service management via
/etc/init.d/is easier to audit and debug - No surprise hard-pulls of Rust, Sequoia, or other language ecosystems
- OpenRC (optional init) is clean, well-documented, and used in production at scale (it’s what Gentoo uses)
- Strong alignment with your stated values: minimalism, transparency, avoiding lock-in
Cons:
- Doesn’t track Debian 1:1 forever; some packages may lag slightly
- Smaller user base = slower discovery of obscure edge-case bugs
- VPS providers rarely offer Devuan as a first-party image
- Some tooling (e.g., Ansible roles, hardening scripts) assumes systemd
Cultural/governance risk going forward: Very low. Devuan exists specifically to resist the type of upstream drift Debian is undergoing. Its maintainers are ideologically committed to init freedom and minimalism, and the project has no corporate sponsor to push an agenda.
2. Alpine Linux
Overview: A security-focused, minimal distribution using musl libc, BusyBox, and OpenRC. Originally designed for embedded/container use, increasingly popular as a production server OS.
| Dimension | Assessment |
|---|---|
| Stability | β Stable release available (not just edge); very reliable once configured |
| Security | β Excellent β smallest attack surface of all options; PIE + SSP hardening by default |
| Package availability | β nginx, PHP 8.x, MariaDB, Certbot all in official repos |
| Migration effort | β οΈ Moderate β requires fresh install; configs mostly transfer but musl differences can surprise |
| Maintenance burden | β Very low once stable β tiny footprint, fewer moving parts |
| Future risk | β Very low β independent project with clear minimal philosophy |
| VPS provider support | β Good β many providers (Hetzner, Vultr, DigitalOcean, Linode) offer Alpine images |
| Community size | β Large for its niche; Docker’s dominant base image, so extremely well-tested |
Pros:
- Smallest possible attack surface β literally thousands fewer packages installed by default
- RAM and disk usage are dramatically lower than Debian (often 50β60% less idle RAM)
apkpackage manager is fast, simple, and transparent- No systemd ever β uses OpenRC, which is mature and production-proven
- Security hardening (stack protection, PIE) enabled by default unlike Debian
apkrepositories have no Rust dependency issues in the core package manager itself- Stable releases (not just rolling) with multi-year support windows
- Used in production at enormous scale (mostly via containers, but the OS itself is solid)
Cons:
- musl libc instead of glibc: This is the most significant practical risk. Most common software (nginx, PHP, MariaDB, Python) works fine. However, occasionally a PHP extension or binary tool expects glibc behaviour. This is a known, manageable issue β not a showstopper for your stack
- Smaller package repo than Debian (though all your core tools are there)
- BusyBox utilities are slightly different from GNU coreutils β occasional script adjustments needed
- Less documentation for non-container use cases compared to Debian
musl compatibility for your stack: All confirmed available and working:
nginxβphp83/php84+ common extensions βmariadbβcertbotβopenssh,fail2ban,rsync,cronβ
Cultural/governance risk: Extremely low. Alpine is a small, technically-focused project with clear scope. No corporate sponsor. The project has been remarkably stable in philosophy for 15+ years.
3. Debian Stable (with mitigation)
Overview: Stay on Debian but apply strategies to reduce exposure to the issues you’ve identified.
| Dimension | Assessment |
|---|---|
| Stability | β Proven, exceptional |
| Security | β Strong β LTS, security team, extended support |
| Package availability | β Best-in-class |
| Migration effort | β None |
| Maintenance burden | β Low today β increasing over time |
| Future risk | β οΈ Medium-high β the trend line is concerning |
Mitigation strategies if staying:
- Pin to Debian Stable, never testing/unstable
- Delay major version upgrades by 6β12 months until post-release churn settles
- Monitor the Rust/APT situation β if the May 2026 Rust-in-APT change lands, evaluate its real-world impact
- Use
apt-mark holdto freeze specific packages if upstream decisions are unacceptable - Subscribe to
debian-devel-announceto get advance warning of governance changes
Why mitigation has limits:
The APT/Rust controversy is a signal, not an isolated incident. The pattern β unilateral decisions by individual maintainers on fundamental infrastructure, ideology-adjacent justifications for forced dependencies β is unlikely to stop. You’d be on a slow drift toward exactly what you want to avoid, with each Debian stable release requiring renewed evaluation.
Verdict: Viable short-term. Not a good 5-year bet if your priority is predictability and stability of values, not just software versions.
4. Void Linux
Overview: An independent rolling-release distro with runit init, available in both glibc and musl flavours. Built from scratch, not derived from any other distro.
| Dimension | Assessment |
|---|---|
| Stability | β οΈ Rolling release β generally stable but occasional surprise breakage |
| Security | β Good β small team, but security patches issued promptly |
| Package availability | β Good but smaller than Debian; all your tools available |
| Migration effort | β High β full reinstall required, no shared base with Debian |
| Maintenance burden | β οΈ Moderate β rolling release requires active monitoring of updates |
| Future risk | β Low β fully independent, ideologically minimal |
| VPS provider support | β Poor β rarely available as a VPS image |
Verdict: Excellent desktop distro. For production VPS hosting where “set it and forget it” is the goal, the rolling release model is a poor fit. The update cadence creates risk for production web servers. Not recommended for your use case.
5. FreeBSD
Overview: A complete Unix operating system (not Linux). Well-known for stability, the Jails isolation system, and excellent networking.
| Dimension | Assessment |
|---|---|
| Stability | β Outstanding β conservative, well-tested releases |
| Security | β Excellent β tight, audited codebase |
| Package availability | β
All your tools available via pkg (ports); nginx, PHP, MariaDB all first-class |
| Migration effort | β Very high β completely different OS, different init, different tooling |
| Maintenance burden | β Low once set up |
| Future risk | β Very low β BSD governance is exceptionally stable and conservative |
| VPS provider support | β οΈ Limited but growing β available on Vultr, DigitalOcean |
Why not recommend as primary:
- Migration from Debian is substantial β every script, cron job, service config, and sysadmin habit needs to be re-examined
- Smaller ecosystem for some operational tooling (Ansible coverage, monitoring agents, etc.)
- Learning curve is real even for experienced Linux admins
If you were starting from scratch and prioritised maximum long-term stability above all else, FreeBSD would be a serious contender. The BSDs have never had a “systemd moment” β their governance model makes such a thing structurally unlikely.
Verdict: Excellent long-term platform. Migration cost is the primary barrier. Worth considering for new servers rather than migrated ones.
6. Gentoo (brief note)
Powerful, minimal, source-based. Gives you complete control over every package and flag. However:
- Compilation time is a real operational burden on VPS hardware
- Requires deep expertise to maintain correctly
- Not recommended unless you have a specific reason to need that level of control
Scoring Summary
| Distro | Stability | Security | Pkg Avail | Migration | Maintenance | Future Risk | Overall |
|---|---|---|---|---|---|---|---|
| Devuan | β β | β β | β β | β β | β β | β β | βββββ |
| Alpine | β β | β β β | β | β | β β β | β β β | ββββΒ½ |
| Debian Stable | β β β | β β | β β β | β β β | β β | β οΈ | βββ |
| Void | β | β β | β | β οΈ | β | β β β | ββΒ½ |
| FreeBSD | β β β | β β β | β β | β | β β | β β β | ββββ (new servers) |
Recommendation
Primary: Devuan
Devuan is the optimal migration path for your existing servers. The migration is the lowest-risk of any alternative:
- No new package manager to learn
- No new init system if you stay on SysVinit (or gentle upgrade to OpenRC)
- Same file layout, same config syntax, same
aptcommands - Minimal opportunity for surprise failures
The philosophical alignment is exact: Devuan exists specifically to be what Debian used to be.
Secondary: Alpine Linux
(new servers or fresh rebuilds)
Alpine is the better choice for any new VPS you provision from scratch, or if you’re willing to do a clean install on existing ones. It provides:
- Dramatically reduced attack surface
- Lower resource usage (relevant for VPS billing)
- The cleanest possible base for a LEMP server
Once configured, Alpine servers tend to be less maintenance-intensive than Debian, not more, because there is simply less software that can go wrong.
Migration Plan
Option A: Devuan Migration
(Recommended for existing servers)
Devuan can be migrated in-place from Debian without reinstallation. This is the standard documented path.
Step 1: Preparation
bash# Full snapshot/backup of the VPS (critical β do this first)# On Hetzner/other providers, create a server snapshot before proceeding# Verify current Debian versioncat /etc/debian_versionlsb_release -a
Step 2: Add Devuan repositories
bash# Install Devuan keyringapt-get install -y devuan-keyring || \ (wget https://pkgmaster.devuan.org/devuan-keyring.gpg -O /etc/apt/trusted.gpg.d/devuan.gpg)# Replace sources.list with Devuan equivalent# For Debian Bookworm (12) β Devuan Daedalus (5)cat > /etc/apt/sources.list << 'EOF'deb http://pkgmaster.devuan.org/merged daedalus main contrib non-free non-free-firmwaredeb http://pkgmaster.devuan.org/merged daedalus-security main contrib non-free non-free-firmwaredeb http://pkgmaster.devuan.org/merged daedalus-updates main contrib non-free non-free-firmwareEOF
Step 3: Migrate
bashapt-get updateapt-get install -y devuan-keyringapt-get dist-upgrade# Remove systemd (Devuan replaces it with sysvinit-core)apt-get install -y sysvinit-core# Reboot β system should come up with SysVinitreboot
Step 4: Cleanup
bash# After reboot, verify initps -p 1 -o comm= # Should show "init" not "systemd"apt-get --purge remove systemd libsystemd0apt-get autoremove
NOTE
The Devuan migration is well-tested and documented. Devuan’s own migration guide at devuan.org is the authoritative reference. For production servers, do one server at a time, verifying full functionality before proceeding to the next.
Time estimate: 1β2 hours per server, mostly waiting
Risk: Low (take snapshot first; rollback is trivial)
Downtime: ~5 minutes for the reboot
Option B: Alpine Linux
Best approach: provision a new Alpine VPS, build your stack there, test it, then migrate DNS to cut over.
Step 1: Base install
bash# Alpine installer is minimal β answer prompts or use setup-alpinesetup-alpine# Enable community repo (needed for some packages)echo "https://dl-cdn.alpinelinux.org/alpine/v3.21/community" >> /etc/apk/repositoriesapk update
Step 2: LEMP stack
bashapk add nginx php83 php83-fpm php83-mysqli php83-mbstring php83-curl \ php83-xml php83-gd php83-opcache mariadb mariadb-client \ certbot certbot-nginx fail2ban openssh rsync dcron# Enable servicesrc-update add nginx defaultrc-update add php-fpm83 defaultrc-update add mariadb defaultrc-update add sshd defaultrc-update add crond defaultrc-update add fail2ban defaultrc-service nginx startrc-service mariadb start
Step 3: Configure
bash# Nginx config lives at /etc/nginx/nginx.conf β same syntax as Debian# PHP-FPM config at /etc/php83/php-fpm.d/www.conf β same syntax# MariaDB setupmysql_install_db --user=mysql --basedir=/usr --datadir=/var/lib/mysqlrc-service mariadb startmysql_secure_installation
Step 4: Transfer
- Copy
/etc/nginx/configs β adjust any Debian-specific paths - Copy
/var/www/web roots - Dump and restore databases via
mysqldump - Copy cron jobs (
crontab -l,/etc/cron.d/) - Install Certbot certs or re-issue
Time estimate: 3β5 hours per server for a careful build-and-test
Risk: Very low (old server stays live until DNS cutover)
Downtime: Near-zero if done with DNS TTL management
Operational Notes Going Forward
Regardless of which you choose:
- Pin critical packages to avoid surprise upgrades breaking things:
- Devuan:
apt-mark hold nginx mariadb-server - Alpine: Use locked versions in your documentation
- Devuan:
- Monitor upstream mailing lists β 30 minutes per month reading announce lists prevents 30 hours of emergency debugging
- Automate security-only updates β keep CVE patches flowing automatically, but treat feature updates as deliberate events
- Test upgrades on non-production first β if you have 3+ VPSes, designate one as the “canary” that takes upgrades 2 weeks ahead of the others
- Document your init scripts / service setup β whichever init system you use, keep your service definitions in version control (git). This is especially important on SysVinit where knowledge is less widely distributed than systemd.
On the Broader Trend
Your concerns are not paranoid β they are consistent with documented patterns. The Rust-in-APT controversy is one of several:
- Debian requiring
dbus-broker(Rust-based) as a dependency for packages that shouldn’t need it - The
meson/ninjabuild system displacingautotoolsacross the ecosystem, often pulling in Python as a hard build dependency - Governance disputes where individual DDs (Debian Developers) have effectively imposed contentious changes unilaterally
The fundamental tension is between Debian’s historical role as a universal OS and pressure from upstream projects (systemd, Rust, Python-heavy build systems) that assume a modern general-purpose environment.
Devuan and Alpine have both explicitly rejected this trajectory. They are better bets for your 5-year horizon.
TIP
If you want to hedge, a sensible intermediate position is: migrate existing servers to Devuan now (low-risk, minimal disruption) and use Alpine for any new VPS you provision going forward. Over 2β3 years, as existing servers need rebuilding anyway, you’ll naturally converge on Alpine.
Document prepared July 2026. Distro versions current as of this date: Devuan 5 (Daedalus), Alpine 3.21, Debian 12 (Bookworm).
===========================================
Debian has been hi-jacked by political ideologues who have good coding as a secondary criterion. Rust and many other things are being introduced and already are causing problems but they are forging ahead anyway because… “feelings.” So we need to be ahead of this game.
Here’s my full analysis and recommendation. The short version:
Recommendations
π₯ Primary: Devuan
β for existing servers
Devuan is Debian without systemd, and it’s the easiest possible migration. The apt muscle memory, config syntax, package names, and directory layout are all identical. The Rust-in-APT changes don’t apply because the Devuan project deliberately filters upstream cruft. You can migrate a running Debian server in-place in ~1β2 hours with 5 minutes of downtime. The project exists precisely because people share your concerns, and that gives it strong governance stability.
π₯ Secondary: Alpine Linux
β for new servers going forward
For any VPS you provision fresh, Alpine is outstanding. It has a dramatically smaller attack surface, lower resource use, OpenRC init, and the package manager has none of the Rust-dependency issues. Your whole stack (Nginx, PHP-FPM, MariaDB, Certbot, and fail2ban) is in the official repos and well-tested. The only real concern is musl libc vs. glibc But for standard LEMP hosting, it’s a non-issue in practice.
What I’d Avoid
- Staying on Debian: Viable short-term, but the trend line is bad. The APT/Rust controversy is confirmed and documented β it’s not speculation
- Void Linux: Great OS, wrong model β a rolling release on production web servers creates unnecessary risk
- FreeBSD: Excellent platform but migration effort from Debian is substantial; worth considering for new builds if you want maximum long-term independence
Practical Strategy
A pragmatic hedge: migrate existing servers to Devuan now (minimal disruption), and use Alpine for any new VPS going forward. Over the natural lifecycle of your infrastructure (servers need rebuilding every few years anyway), you’ll converge on Alpine with zero forced migration events.
The full document has step-by-step migration commands for both paths. Happy to do any of these migrations with you when you’re ready β it’s straightforward work.
For a minimal stack consisting of HTML, CSS, JavaScript, PHP, and a standard SQL database, Alpine Linux is practically an industry standard. It is incredibly stable, hyper-efficient, and entirely free of OS-level drama.
— Claude via Antigravity.
Maybe Alpine now instead of later
Why Your Stack Fits Alpine Perfectly
- First-Class PHP Support: Alpine maintains highly up-to-date and modular PHP packages (
php82,php83, etc.) in its official repositories. All common extensions needed for authentication and web servingβsuch asphp-pdo,php-openssl,php-session, andphp-curlβare natively compiled againstmusland install instantly. [1] - Standard Web Servers Work Out-of-the-Box: Whether you use Nginx, Apache (
httpd), or Caddy, they are fully supported and exceptionally lightweight on Alpine. An Nginx + PHP-FPM setup on Alpine typically idles at just a few megabytes of RAM. [1] - Database Compatibility: Mainstream databases like MariaDB, MySQL, and PostgreSQL are native to Alpine’s package manager. They compile perfectly against
muslbecause they are open-source and standard-compliant. - No Pre-Compiled Binary Hassles: The
muslissue usually only trips up developers who need to run closed-source, pre-compiled proprietary binaries (like specific enterprise oracle drivers or proprietary backup agents). Since PHP code is interpreted at runtime and your web server/database are open-source, everything works seamlessly.
A Minimal Production Architecture
Because Alpine cuts out all the political and architectural bloat, a production server or container running your authentication system becomes incredibly easy to audit and maintain. You get a rock-solid, secure environment where the operating system stays out of your way and lets your code do the work.
— Gemini