What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
The lowest-effort safe approach is layered automation, not a single “auto-update” switch: apply security patches automatically from repositories you explicitly trust, watch the logs and alerts, plan reboots, restrict administration, minimize installed software, and maintain tested backups or a reproducible redeployment. On supported Ubuntu Server releases, unattended-upgrades is installed by default and runs daily, but production safety depends on controlling its scope and making failures, service impact, and pending kernel reboots visible.
What a low-effort VPS maintenance routine actually includes
Patch automation removes repetitive logins; it does not remove operational responsibility. A dependable routine has seven layers:
Free tools Windows power users keep installed
One-click scans. No signup required.
- Supported software: run a supported Ubuntu release and know when its security maintenance ends.
- Controlled update scope: apply security updates automatically, while deciding deliberately whether normal updates and third-party repositories belong in automation.
- Observability: retain update logs and send email or monitoring alerts for failures, held packages, and reboots that are still required.
- Planned restart behavior: leave automatic reboots disabled for fragile production services unless you have a tested window and out-of-band console access.
- Restricted administration: use a named, non-root administrator, strong SSH authentication, and a firewall exposing only required ports.
- Small attack surface: remove unused packages, daemons, accounts, and casual repositories.
- Recovery: keep backups and a reproducible image or deployment so a bad update is recoverable without improvisation.
This is the practical interpretation of NIST SP 800-123: server security is a process of selecting, implementing, and maintaining controls, rather than a one-time hardening script.
How Ubuntu automatic updates behave by default
Daily execution and delayed installation
Ubuntu says unattended-upgrades is installed by default on supported Ubuntu Server installations and runs once per day. Detailed activity is written to /var/log/unattended-upgrades. Ubuntu’s security guidance states that, from Ubuntu 18.04 onward, security updates are installed after a default delay of 24 hours and normal updates after seven days. These are defaults, not a guarantee that every package will install: dependency conflicts, held packages, repository errors, disk exhaustion, and interrupted package operations can stop a run.
#1 Best Overall
- POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
Canonical’s stated risk judgment is explicit: “Ubuntu believes that risk to be less than the risk of NOT applying a security update, which is why unattended-upgrades will apply security updates by default.” That favors timely security fixes, but you still need a recovery plan for the occasional incompatible update.
Which repositories are included
Automatic updates cover Ubuntu archive repositories and, when enabled, Extended Security Maintenance (ESM) sources. Third-party repositories and PPAs are not automatically included merely because they are configured on the server. To include one, add its origin explicitly through an Allowed-Origins drop-in under /etc/apt/apt.conf.d/.
Use a numbered drop-in file rather than editing the vendor-supplied 50unattended-upgrades. This keeps local policy separate from package updates that may replace the vendor file. Before adding an origin, identify its signing key, maintainer, release policy, rollback options, and whether it publishes security fixes promptly. Every additional repository expands the software you must trust and troubleshoot.
Security-only versus normal updates
Security updates are the sensible starting scope for hands-off production patching. Normal updates can include behavior changes, new dependencies, and feature transitions that deserve a maintenance window or staging test. Ubuntu’s seven-day default delay for normal updates gives operators more time, but it is not a substitute for testing application compatibility.
A step-by-step setup that stays observable
1. Confirm release, source, and capacity
- Check that the Ubuntu release is still supported and record its end-of-standard-support date in your maintenance calendar. Do not automate patching on an abandoned release as if it were maintained.
- Review the files in
/etc/apt/sources.listand/etc/apt/sources.list.d/. Remove disabled, obsolete, or unknown entries and confirm that repository suites match the installed release. - Check free space in the root filesystem and in
/boot. Package transactions can fail when either is full, leaving a partially configured system. - Confirm that your VPS provider offers a web console or equivalent out-of-band access. SSH alone is insufficient if a firewall change or reboot cuts off networking.
2. Inspect and preserve the policy
Open the unattended-upgrades configuration under /etc/apt/apt.conf.d/ and inspect Allowed-Origins. Keep the distribution’s security origins enabled. Add a third-party origin only when you can explain why it is needed and how you would recover if its package breaks an application. Store your local drop-in in a separately numbered file so an Ubuntu package update does not silently overwrite it.
3. Run a dry test before relying on automation
Use Ubuntu’s documented simulation command:
sudo unattended-upgrade -v --dry-runA dry run shows what the current policy would do without changing packages. Read the proposed origins and packages; an unexpected repository or broad upgrade scope is a policy problem, not a reason to click through. After changing the drop-in, run the dry test again.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match4. Verify the real run and logs
After the scheduled run, inspect /var/log/unattended-upgrades for downloaded packages, install results, held packages, and errors. Forward these logs to your monitoring system or configure the documented email reporting so an unattended failure creates an actionable alert. Alert on repeated failures, not only on total absence of messages: a server can be “quiet” because its timer stopped.
5. Decide how reboots will happen
Automatic reboot is disabled by default. Keep it disabled for stateful databases, clustered services, and applications that need connection draining unless you have tested the complete restart sequence. Instead, alert when a new kernel or library requires a reboot and perform it during a defined window.
If you enable automatic reboot, limit it to a maintenance period, verify that the provider’s console works, and define a post-reboot health check. A reboot policy without a service check can turn a successful package transaction into a prolonged outage.
Rank #2
- Ultra-Compact FIDO2 Security Key - Plug-and-stay or carry on a keychain. This USB-A hardware security key offers portable, always-on protection for desktop and mobile use. (Item Size: 0.75 X 0.74 IN x 0.25 IN)
- USB-A Hardware Key for All Devices - Works with USB-A ports on PC, Mac, Android, and other laptop/notebook device. Enables secure, cross-platform login with FIDO2.0 passkey support.
- FIDO Certified Security Key - Meets FIDO and FIDO2 standards. Works with Google, Microsoft, GitHub, Dropbox, and more. Please check service compatibility before purchase.
- Passwordless Login with Passkey - Supports passkey login via WebAuthn and CTAP2. Enjoy password-free sign-ins where supported. Not all websites or services currently support passkeys.
- Advanced Multi-Factor Authentication - Offers 200 FIDO2 passkey slots and 50 OATH-TOTP slots. Strong, flexible 2FA/MFA support across various apps and authentication platforms.
Should you use unattended-upgrades on a production VPS?
Usually yes for security updates, provided the server is recoverable and the update scope is explicit. The decision is less about “automatic versus manual” than about blast radius and detection speed.
| Approach | Update scope | Reboot behavior | Observability and recovery | Best fit |
|---|---|---|---|---|
| Manual patching | Operator chooses each transaction; security fixes can wait for human availability. | Planned by the operator. | Potentially high during a maintenance session, but inconsistent if sessions are skipped; recovery depends on backups and console access. | Highly sensitive systems with staging and a staffed change process. |
| Unattended-upgrades | Security origins by default; normal and third-party origins require policy. | Disabled by default; can be configured with caution. | Daily logs, dry-run validation, email, and monitoring expose failures. | Most Ubuntu production VPSs that need continuous security coverage. |
| Livepatch plus package automation | Livepatch addresses eligible high- and critical-severity kernel vulnerabilities while the system runs; user-space packages still need updates. | Can avoid an immediate kernel reboot for covered fixes; other changes still require one. | Requires checking Livepatch status plus ordinary package logs and service health. | Systems where reducing kernel maintenance windows matters. |
| Managed patching service | Depends on the provider’s contract and tooling. | Provider policy; confirm approval and outage procedures. | Can add escalation and support, but does not replace independent backups or verification. | Teams that cannot operate patch monitoring themselves. |
Automation is unsafe when nobody receives failure alerts, the server has no tested restore path, or application owners cannot tolerate an unexpected restart. In those cases, improve the controls first rather than simply disabling updates.
SSH hardening without locking yourself out
Use a named administrator and least privilege
Create a personal, non-root administrator account and grant administrative rights only through the system’s supported privilege mechanism. Use root for the specific command that requires it, not for routine shell sessions. Keep a second tested administrator or an out-of-band console path before changing SSH settings.
Prefer strong, supported authentication
Use SSH keys rather than password-only login, protect private keys on administrator devices, and remove stale authorized keys. Ubuntu’s security guidance also points to smart-card authentication. A FIDO2/U2F hardware key can provide phishing-resistant authentication when your OpenSSH and PAM versions support the required method; verify compatibility in a non-production account before making it mandatory.
Restrict exposure
Use a firewall such as ufw or another supported firewall and allow only ports required by the application, monitoring, and administration. Apply the firewall change while an existing SSH session remains open, then test a new session from an approved network. Record the allowed source ranges and review them when staff or infrastructure changes.
Make SSH changes reversible
- Keep an active console session and a second SSH session.
- Validate the daemon configuration with the OpenSSH configuration test before reloading it.
- Reload rather than abruptly terminating the daemon.
- Open a fresh connection using the new account and authentication method.
- Only then remove root login, password fallback, or the old key, and retain the console until the change has survived a reconnect.
Reduce the software and trust surface
List installed packages and enabled services, then remove anything not required by the workload. An unused web server, database, compiler, dashboard, or daemon is still code that can contain a vulnerability and still creates update work. Disable services before uninstalling when you need a rollback window, and document why each remaining service exists.
Avoid casual PPAs and vendor repositories. If an application requires one, pin the purpose, owner, signing key, supported releases, and rollback method in your operations documentation. When an official Ubuntu package or a reproducible application image meets the requirement, it generally reduces long-term maintenance scope.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Backups, images, and recovery are part of patching
Frequent backups protect data; an image or infrastructure-as-code definition protects the operating environment. CISA’s StopRansomware guidance recommends frequent backups, including offline or cloud-to-cloud copies, and infrastructure-as-code for rapid redeployment. Apply that model to VPS snapshots, databases, object storage, secrets, firewall rules, and deployment templates.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Test what “recoverable” means
- Restore a recent backup into an isolated VPS or staging environment.
- Verify database consistency and application startup, not merely that files exist.
- Confirm DNS, certificates, firewall rules, scheduled jobs, and secret injection.
- Measure the time from a failed update to a working replacement.
- Keep at least one copy that a compromised VPS cannot overwrite.
A snapshot taken immediately before every update is useful but is not a complete backup strategy: snapshots can share a failure domain with the VPS, and they do not prove that application data can be restored.
Rank #3
- Security Key : Protect your online accounts against unauthorized access by using FIDO2 and U2F authentication with T110. It's the world's most protective security key that works with windows, Mac OS, Linux as well as Chrome, Firefox, Edge and many other major browsers.
- Certified with the new FIDO2 standard, T110 provides the benefit of fast login and strong protection against phishing, account takeover as well as many other online attactks.
- Works with : Bank of America, Github, Google, Microsoft, DUO, Twitter, Facebook, Dropbox, Apple, ebay, BINANCE, mor and more.
- Fits USB-A port : Insert the T110 security key into the USB-A port of each service and log in conveniently with one touch
- For the driver download and user guide, please visit TrustKey Solutions Home support page.
Reduce reboots and extend support responsibly
Ubuntu Pro ESM
Ubuntu documents that Extended Security Maintenance extends LTS coverage for Main packages from five years to ten years and now includes Universe packages. ESM can provide additional time to migrate, but it does not make an obsolete application or unsupported kernel configuration safe. Continue patching applications, reviewing configuration, and planning the eventual release upgrade.
Livepatch
Livepatch applies eligible high- and critical-severity kernel patches while the system is running, avoiding an immediate reboot for those covered fixes. It does not patch user-space libraries, application code, configuration errors, or every kernel change. Track Livepatch status and still schedule ordinary reboots when Ubuntu indicates they are required.
A maintenance cadence that avoids daily logins
| Cadence | Checks |
|---|---|
| Every day, automated | Unattended security transaction, repository reachability, disk-space alerting, and service monitoring. |
| Weekly | Review unattended-upgrades logs, failed units, held packages, pending reboot indicators, and unusual authentication events. |
| Monthly | Apply normal updates in a maintenance window or staging environment, test application health, and close obsolete repository entries. |
| Quarterly | Restore a backup, test redeployment from the image or infrastructure definition, rotate stale SSH keys, and review firewall rules and administrator access. |
| Before release end | Plan the Ubuntu release upgrade, ESM decision, application compatibility testing, and rollback route. |
This cadence turns patching into a small number of exception-driven checks: you log in when an alert or planned change requires you, not merely to ask whether yesterday’s update ran.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsTroubleshooting common failures
The dry run proposes unexpected packages
Inspect Allowed-Origins and every file under the APT sources directories. Remove an unintended PPA or correct the distribution suite, then repeat the dry run. Do not approve a broad origin merely to clear the queue.
An update failed partway through
Read the unattended-upgrades log and the package-manager error, check disk space, and identify held or conflicting packages. Keep the VPS console available, repair the package state during a controlled session, and rerun the dry test before resuming automation. If the application is unhealthy, restore or redeploy from the tested recovery path rather than repeatedly retrying blindly.
The server requires a reboot
Confirm which kernel or library triggered the requirement, check application shutdown behavior, notify affected users, and use the planned window. Validate SSH, firewall rules, storage mounts, scheduled jobs, and application endpoints after boot.
SSH stopped working after hardening
Use the provider console, inspect the daemon configuration and firewall rules, and restore the last known-good access method. Do not disable every control permanently; fix one change at a time and retest from a second session before closing the console.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →The practical decision rule
Enable automatic security updates when the VPS has a supported release, intentional repositories, monitored logs, a tested recovery path, and an administrator who can perform planned reboots. Keep normal updates and third-party origins under explicit policy, and treat Livepatch or ESM as maintenance aids rather than substitutes for complete patching. The result is fewer routine logins with more reliable security because exceptions remain visible and recoverable.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
