CloudStick is a server control panel for developers and agencies that lets you manage cloud servers on AWS, DigitalOcean, Vultr, Linode, and Hetzner without using the command line. Plans start at $9/month — the Basic plan covers 1 server with unlimited websites; Pro at $19/month and Business at $49/month cover unlimited servers.

Will features I pay for ever get moved to a higher plan?

No. CloudStick is committed to keeping all features you currently pay for within your existing plan. New features may be added to higher tiers, but existing plan features will never be removed or require a forced upgrade.

What happens to my servers if I cancel CloudStick?

Your servers remain fully operational after cancellation. CloudStick does not host your servers — it manages them. If you cancel, you lose access to the CloudStick dashboard, but your servers continue running on your cloud provider.

Is there a free trial for CloudStick?

Yes. CloudStick offers a 7-day free trial on all paid plans with no credit card required. You can explore every feature and upgrade, downgrade, or cancel at any time during or after the trial.

VPS SETUP

Jun 23/2026

Updating and Upgrading a Linux Server Safely

8 min read

CloudStick Team

WordPress Engineer

Share this article

Updating and Upgrading a Linux Server Safely

Safe Linux
server updates

Understanding apt update vs apt upgrade vs dist-upgrade

These three commands are frequently confused because their names sound similar. They do fundamentally different things, and mixing them up on a production server can cause unexpected service disruptions.

apt update refreshes the local package index from the configured repositories. It downloads metadata — package names, versions, and dependency information — but installs absolutely nothing. Always run this before any upgrade command to ensure you are seeing the latest available versions.

apt upgrade downloads and installs newer versions of all currently installed packages. Critically, it does not install new packages or remove existing ones — this constraint makes it the safe choice for production servers, since it will not pull in unexpected new dependencies or remove a package that something else depends on.

apt full-upgrade (formerly dist-upgrade) does everything apt upgrade does, plus handles dependency changes that require installing new packages or removing old ones. Use this cautiously on production — it can occasionally remove a package that seems obsolete but is actually required by your application.

# Step 1: Refresh the package index (always first)
sudo apt update
# Step 2: Preview what will be upgraded before committing
apt list --upgradable
# Step 3: Upgrade installed packages (production-safe)
sudo apt upgrade -y
# Step 4: Clean up orphaned packages
sudo apt autoremove -y

Running a Safe Server Update Without Downtime

Never run updates blindly during business hours. Check what is upgrading, look for service restarts that require downtime, and schedule the update during a low-traffic window. The safe process:

# See exactly which packages will be updated
apt list --upgradable 2>/dev/null
# Check if a reboot is currently required
cat /var/run/reboot-required 2>/dev/null && echo "Reboot needed" || echo "No reboot"
# Run the upgrade and log output for review
sudo apt upgrade -y 2>&1 | tee /tmp/apt-upgrade.log
# Check core services are still running after upgrade
sudo systemctl status nginx mysql php8.3-fpm

PREREQUISITE

Take a server snapshot before major upgrades. DigitalOcean, Vultr, and Hetzner all support one-click snapshots from their dashboards — the process takes 2-5 minutes and gives you an instant rollback point if the upgrade breaks something critical.

Automating Security Patches with Unattended-Upgrades

Security vulnerabilities in system packages are discovered and patched constantly — many of them are critical and exploited within hours of disclosure. Unattended-upgrades automatically applies security patches from the Ubuntu Security Notice (USN) feed, so your server stays protected even if you forget to run apt upgrade manually for a week.

Crucially, unattended-upgrades only applies packages from the security repository by default — not all upgrades. This means it patches OpenSSL, glibc, and the kernel without touching your application packages like PHP or MySQL, reducing the risk of breaking production.

sudo apt install unattended-upgrades apt-listchanges -y
sudo dpkg-reconfigure --priority=low unattended-upgrades
# Edit configuration for auto-reboot during maintenance window
sudo nano /etc/apt/apt.conf.d/50unattended-upgrades
# Add or uncomment:
# Unattended-Upgrade::Automatic-Reboot "true";
# Unattended-Upgrade::Automatic-Reboot-Time "03:00";
# Unattended-Upgrade::Mail "you@example.com";
# Dry-run to test without making changes
sudo unattended-upgrade --dry-run --debug

TIP

Set the Automatic-Reboot-Time to a time when your traffic is lowest — typically between 2:00am and 5:00am in your primary user timezone. If your site serves a global audience 24/7, consider using a two-server setup behind a load balancer so one server is always available during the reboot window.

Handling Kernel Updates and Reboot Windows

Kernel updates require a full reboot — there is no live-patching solution available on standard Ubuntu installations. The update installs the new kernel package, but the system continues running on the old kernel until you reboot. The /var/run/reboot-required file is created automatically when a reboot is needed.

# Check the currently running kernel version
uname -r
# Check installed kernel packages (look for newer versions)
dpkg -l | grep linux-image
# Check if a reboot is pending
cat /var/run/reboot-required
# Schedule a reboot during your maintenance window
sudo shutdown -r +60 "Rebooting for kernel update in 60 minutes"
# After reboot, verify the new kernel is active
uname -r

For high-availability setups running two servers behind a load balancer, update and reboot one server at a time. Route all traffic to server B, update and reboot server A, verify it comes back healthy, then switch traffic back and update server B. This gives you zero-downtime kernel updates.

What to Do When an Update Breaks Something

Most service breakage after apt upgrade comes from PHP-FPM, MySQL, or Nginx configuration incompatibilities introduced in newer package versions. The recovery steps, in order of severity:

# 1. Check which packages were recently upgraded
grep "upgrade" /var/log/dpkg.log | tail -20
# 2. Check service logs for the specific error
sudo journalctl -u nginx --since "1 hour ago"
sudo journalctl -u mysql --since "1 hour ago"
# 3. Downgrade a specific package to a previous version
# First, find available versions:
apt-cache showpkg nginx
# Then install the older version:
sudo apt install nginx=1.24.0-2ubuntu7
# 4. Nuclear option: restore from cloud provider snapshot
# Do this via your DigitalOcean/Vultr/Hetzner dashboard

One-Click Security Updates in CloudStick

CloudStick's Security & Third-party Updates feature in the server panel triggers apt update && apt upgrade on your server from the web dashboard — no SSH required. This is available on all CloudStick plans and is useful for teams where not every member has server SSH access but needs to apply routine security patches.

For kernel reboots, you can initiate a server restart from the CloudStick dashboard as well, timing it to your maintenance window. CloudStick's Service Management panel shows the status of Nginx, MySQL, and PHP-FPM after the restart, confirming all services came back up without requiring you to SSH in and check manually.