Protect aaPanel Free Edition management access with HTTPS, a carefully tested panel-port change and SSH keys. This guide records our Ubuntu 22.04 lab results from 10 October 2026. It follows panel installation and web stack setup.
1. Keep a recovery route and back up configuration
Before changing access settings, keep your provider's recovery console available and an existing SSH session open. Save configuration backups off the server. Our lab has no snapshots, so we saved an off-server copy of the SSH, firewall, Nginx and panel configuration.
A configuration archive is not a complete website/database backup. aaPanel's Auto Backup Panel setting also states that it excludes website and MySQL data. A separate backup-and-restore exercise is required for those.
2. Check panel HTTPS
Open Settings → Panel SSL. The numbered screenshot shows HTTPS enabled, a trusted certificate and its expiry information:
Our panel already had a certificate that validated without bypassing browser warnings. Check your own hostname/IP, certificate status and expiry. The lab's IP certificate has a short lifetime; renewal still needs verification. Panel HTTPS and your website's HTTPS certificate are separate settings.
If your browser reports a certificate error, investigate it before sending login credentials. Enabling a switch alone is not proof that the certificate is valid for the address you use.
3. Change the panel port without locking yourself out
Changing the port can reduce routine scanning noise, but it does not replace strong authentication or access restrictions. We used 18443 as an example; choose an unused port appropriate for your setup.
Note the current panel port and keep the current SSH session open.
Allow the new TCP port in the server firewall and any provider security group first. Restrict management access to trusted sources when practical.
In Settings → Panel port → Modify, enter the new port.
Read the dialog, acknowledge that the new port is allowed, then confirm. The panel restarts.
Open the new HTTPS URL with the same private entrance path. Sign in through a fresh connection.
Only after the new connection works, remove the old management-port firewall rule.
Our new panel login succeeded before we removed the old firewall opening. Preserve the private entrance path and credentials in secure notes, not public screenshots. If access fails, use the still-open SSH session or provider console to restore the previous port/firewall configuration.
4. Test SSH key access
Generate a dedicated key on your own computer. An interactive key can use a passphrase:
Code:
ssh-keygen -t ed25519 -f ~/.ssh/aapanel_lab
Copy the public key to the correct server account. On a workstation with ssh-copy-id:
Windows OpenSSH users can add the public key through their existing authenticated session. Keep the private key on your computer; only the .pub key belongs in the server's authorized_keys file. Verify the server host fingerprint through a trusted route.
We tested fresh Ed25519 sessions before and after reboot. We retained password access during the disposable lab exercises. For production, plan a separate tested move to a sudo account and key-only authentication; do not disable a working recovery route before verifying its replacement.
5. Review the remaining protections
Our aaPanel Free 8.0.6 interface includes Google Authenticator and Authorized IP controls. We have not enabled them in this lab: authenticator enrollment needs the owner's device, and an allowlist needs a stable management address or VPN. Configure and test these for your environment without blocking legitimate access or certificate renewal.
Review optional phpMyAdmin and FTP exposure. MariaDB does not need a public database-port opening for a website running on the same server. Use encrypted file transfer and allow only the services you actually need.
Verified results and remaining checks
Our Ubuntu updates and reboot completed. Fresh SSH key access, panel login, Nginx, MariaDB and PHP-FPM recovered successfully. The local default website returned HTTP 200. The panel-port change and current certificate validation passed.
We also disabled phpMyAdmin’s separate public-access service and verified that the setting remained off. Its authenticated panel launch still needs troubleshooting; see the phpMyAdmin installation guide.
Certificate renewal, two-factor enrollment, a stable management allowlist and full website/database restore testing remain separate checks. This guide does not claim that every production-hardening task is complete.
Next: Add a website, connect its domain, issue its own HTTPS certificate and create its database.
Set up a PHP hosting stack in aaPanel Free Edition using Nginx, MariaDB, PHP and optional phpMyAdmin. This is the second tutorial, following panel installation on Ubuntu 22.04.
Tested on 10 October 2026 with aaPanel Free 8.0.6, Ubuntu 22.04.5, 2 vCPU and 4 GB RAM. The screenshots below are our original lab captures with numbered AdminsForum annotations.
Individual installation tutorials
Use this overview to choose the stack, then follow the separate service guides:
Each guide includes its own original annotated screenshot, checks and troubleshooting. phpMyAdmin and FTP are optional; their guides identify the access/transfer checks that are still pending.
1. Choose Single WebServer model
After the first login, aaPanel offers a software-installation screen. In the screenshot, use the Single WebServer model on the right. This keeps the initial setup straightforward.
Select Nginx. We chose the 1.30 branch; the installer delivered Nginx 1.30.5. Choose one web server for this walkthrough. A multi-server configuration is a different deployment choice.
2. Choose your database and PHP
The second numbered box shows the supporting components:
MariaDB 10.11: shown under the MySQL selector as mariadb_10.11. It stores application data.
PHP 8.4: runs PHP applications. Check your application's PHP compatibility before choosing a version.
Pure-FTPd: optional FTP service. It was installed in our lab for a later file-transfer exercise. You can leave it unchecked if you use SFTP or File Manager.
A static HTML site only needs a web server. WordPress and many other PHP applications need PHP plus a database. Installing phpMyAdmin does not create an application database for you.
3. Leave DNS and Mail Server unchecked
The third box highlights DNS and mail options. We left both unchecked. You can manage your website's DNS through your domain or DNS provider without running a DNS server on this VPS. Mail hosting needs its own planning and configuration.
4. Start the installation
In the right-hand panel, select Quick install, then click that panel's One-click button. The fourth box highlights these controls.
Wait for the installation queue to complete. Avoid launching another package update or repeatedly starting the same task. If a task fails, inspect its log and fix the reported error before retrying that component.
5. Confirm the installed components
Open App Store → Installed. This is what our completed installation showed:
The numbered boxes highlight the Installed filter, installed software names, running-status indicators and Free Edition/version label.
Nginx 1.30.5
MariaDB 10.11.10
PHP 8.4 — CLI verification reported 8.4.26
phpMyAdmin 5.2
Pure-FTPd 1.0.49
Actual patch versions can differ when you follow this guide. The green running indicators and installed list are useful checks, but test the services too.
6. Verify from SSH
These commands apply to the paths and PHP branch used in our lab:
Expected results: a successful Nginx configuration test, version information, an active database service, a running PHP-FPM service and an HTTP response from Nginx. Our default local page returned HTTP 200. Change 84 and php-fpm-84 if you installed a different PHP branch.
We rebooted the lab and verified that Nginx, MariaDB and PHP-FPM recovered. These checks confirm the base stack; they do not prove that a PHP website or phpMyAdmin login works. Those application checks belong to the website/database tutorials.
Before hosting a real website
Review panel and phpMyAdmin access, firewall rules, HTTPS and backups. Do not expose the database port just because MariaDB is installed. Use a separate application database and user when creating the website.
FTP is optional. Prefer SFTP or a properly secured file-transfer configuration; installing an FTP server alone does not establish encrypted transfers.
Frequently asked questions Should I install Nginx and Apache together?
This walkthrough uses a single Nginx server. Select a different architecture only when your application or deployment requires it.
Which PHP version should I choose?
Use a version supported by your application and required extensions. Our PHP 8.4 selection is a tested example, not a compatibility guarantee for every application.
Do I need phpMyAdmin and FTP?
Both are optional administration tools. The web server, PHP runtime and database serve different roles from those tools.
Next: Secure panel/server access, then add your first website, domain, HTTPS certificate and database.
Install aaPanel Free Edition on a clean Ubuntu 22.04 VPS, sign in, and verify the dashboard before installing your website software. This walkthrough was tested on 10 October 2026 using Ubuntu 22.04.5 LTS and aaPanel Free 8.0.6.
Our lab has 2 vCPU, 4 GB RAM and a 40 GB disk. These are the tested specifications, not a universal sizing requirement. All screenshots are our own, annotated and branded AdminsForum.
Before you start
Use a clean VPS with root or sudo access. Do not install over another hosting panel or an existing production stack.
Keep access to your provider's recovery console and make an off-server backup of anything you need.
A domain is optional for panel installation. You will need DNS when setting up a named website later.
Review the downloaded script before running it as administrator:
Code:
less install_panel_en.sh
Press q to leave the viewer. If curl reports a TLS or download error, resolve that error instead of running an incomplete file or disabling certificate checks.
4. Install aaPanel Free Edition
Code:
sudo bash install_panel_en.sh forum
Confirm the installation directory when prompted. Our installation used /www. Wait for the installation-success message; the time needed depends on the server and download speed.
Save the generated panel URL, username and password privately. The URL includes a management port and a private entrance path. Use your own generated values; a different server's URL will not work. Installation logs can contain credentials, so redact them before asking for help.
5. Open the panel and verify the dashboard
Open the exact URL printed by your installer and sign in. If your provider has a separate firewall, allow the generated management port for your own management access. The panel's HTTPS certificate validated in our lab. If yours shows a browser certificate warning, investigate the certificate before proceeding.
The opening screenshot highlights:
The installed panel version: 8.0.6 in our test.
Server load, CPU, RAM and disk information.
Website, FTP and database counters. Zero counts are normal before creating your first site.
The dashboard can display Pro upgrade promotions. Our App Store explicitly reported FREE 8.0.6; no Pro subscription was required for this installation.
The first-login software selection is the next stage. Follow the separate web stack guide rather than installing every available component.
Troubleshooting Panel URL returns 404: Check that you included the private entrance path. In our test, requesting only the management-port root returned 404 as expected.
Connection times out: Check the server address, generated port, provider firewall and the server firewall. Do not open every port to solve a single access problem.
Package manager is busy: Wait for the current update or installation to finish. Do not delete package-manager lock files while a process is still using them.
Check panel services from SSH:
Code:
sudo /etc/init.d/bt status
Our panel and task services were running. We also completed a reboot and verified fresh SSH and panel access afterward.
Frequently asked questions Do I need a domain to install aaPanel?
No. You can install and access the panel using the server's generated management URL. A domain is useful when you create a website.
Does installing aaPanel also install PHP and a database?
The panel installation and web stack selection are separate stages. Choose compatible software for your intended application.
Is this the Free or Pro edition?
This guide uses aaPanel Free Edition. Paid plugins and Pro tutorials will be covered separately.
What do you need before installing aaPanel?
You need a clean supported Linux server, its IP address, SSH access and administrator privileges. A domain is optional for the initial installation, but you will need one you control for the domain-based website and trusted HTTPS tutorials. Prepare recovery access and backups before changing the server.
Review status: Official requirements checked on 9 October 2026. This is a preparation checklist. Our fresh-VPS walkthrough, exact tested versions and original screenshots will be added after testing.
1. A VPS or other suitable Linux server
aaPanel runs on the server; buying a domain alone does not provide a place to install it. A VPS is convenient for this tutorial series, but a suitable dedicated server can also be used. An ordinary shared-hosting account without server administration access is not equivalent.
Before choosing an image, check the current official aaPanel installation requirements for the OS release and architecture you intend to use. At this review date, Quick Start lists an installation minimum of 1 CPU core, 512 MB RAM and 1 GB storage. These figures are an installation floor, not a guarantee of capacity for a web server, database and live application.
Leave room for your application, PHP workers, database, logs, updates and backups. Record the actual CPU, RAM, storage and OS version. Do not install aaPanel over another hosting panel or an existing production stack without a supported migration plan.
2. Server IP, SSH and administrator access
Have the correct server IP and the initial username supplied by the provider. Check that SSH works and that you have root access or a sudo-capable account with the privileges required by the installer. Use an SSH client on your computer, such as its existing OpenSSH client.
Keep credentials in a password manager. Never publish passwords, private SSH keys, API tokens or the panel's private entrance URL. Keep a working session open while adjusting access rules.
3. Recovery console, updates and a baseline backup
Open and test the provider's recovery console before changing SSH or firewalls. Confirm how rescue mode and snapshot recovery work. Update the clean OS using its supported package manager, verify server time and plan any required reboot.
Take a baseline snapshot if available. If the server already contains data, make an independent backup and plan recovery or migration before installing anything. A snapshot in the same provider account is useful for rollback but is not an independent off-site backup.
4. A domain and DNS access for the website tutorials Do I need a domain to install aaPanel?
No. Initial installation can start with the server IP and SSH. Save the actual management address produced by your own installation; do not assume a port or entrance path from another tutorial.
When do I need a domain?
Use a domain you control when connecting a named website and setting up the hostname-based HTTPS examples. A subdomain of an existing domain is enough for the tutorial lab. For example:
Code:
lab.example.com test website
panel-lab.example.com panel management hostname
These are placeholders. You need access to the authoritative DNS provider, which may be different from the domain registrar. Preserve existing website, mail and verification records. Use a separate test hostname so the exercise does not move a live site's traffic.
Do I have to buy a second domain?
No. You can use suitable subdomains of one you already control, or a spare domain. Check which DNS records the chosen certificate validation method requires.
5. Access to both firewall layers
Be able to manage the provider/cloud firewall and the server firewall. Preserve your actual SSH port. After installation, restrict the actual panel management port to your management IP or VPN where practical. Public website ports and management access serve different purposes; do not open every port in an example list.
If using IPv6, verify the corresponding routing and access rules before publishing an AAAA record. Test a fresh administrative connection after changes while the recovery console remains available.
6. Know what website you plan to run
Decide whether the first test is static HTML or a PHP application. A static test does not require a database. For an application, check its supported PHP/database versions and required extensions before selecting the stack. Install only the services you need; mail, FTP and optional plugins do not have to be part of the first exercise.
Ready-to-install checklist
A clean server with an OS/architecture supported by the current aaPanel release.
CPU, RAM and disk capacity planned for the workload, not just the installer.
Correct IP, working SSH and the required administrator privileges.
Tested recovery-console access and a baseline snapshot or backup.
OS updates and server time checked.
Access to provider and server firewall controls.
A private place to store credentials and installation details.
For the website/HTTPS stages: a test hostname and authoritative DNS access.
A record of the OS and, later, aaPanel/web-server/PHP versions actually used.
Official source:aaPanel Quick Start. Recheck its current requirements before installing; supported releases and installer instructions can change.
Need help checking your setup? Share your OS version, CPU/RAM, intended website and whether you have DNS access. Leave credentials and private connection details out of your post.
Plesk is a commercial web hosting control panel for managing websites and hosting services through a browser. Plesk Obsidian is available for supported Linux distributions and Windows Server versions; the supported OS list and available components differ by platform.
Instead of managing every hosting task from the command line, you work with domains, subscriptions and user permissions in the panel.
Main features
Website management: organise domains, hosting settings and site files.
Hosting services: manage databases, email and DNS where those services are installed and enabled.
HTTPS: certificate management and integrations for securing websites.
WordPress: WP Toolkit offers WordPress management; advanced capabilities depend on your edition and licence.
Developer tools: extensions can add workflows such as Git or application runtime management.
Backups and migration: tools for protecting hosting data and moving supported workloads.
Check your chosen edition, operating system and extension licences before assuming a feature is included. Linux and Windows installations are not interchangeable feature for feature.
Domains, subscriptions and customers explained
Think of a domain as a website address, a subscription as a hosting allocation with resources and permissions, and a customer as the account that owns subscriptions. This helps you keep different clients' hosting organised instead of putting everything under one shared administrator login.
Who is Plesk for?
It is worth considering for agencies, developers and administrators who want a central interface for several sites or client hosting. If you need Windows hosting, compare the Windows-specific support matrix carefully. For a small hobby VPS, weigh the paid licence and optional extensions against what you actually need.
Frequently Asked Questions
Is Plesk free?
Plesk is a paid product. Trial availability, domain limits and included tools depend on current terms and edition. A provider may bundle a licence with its server; confirm that explicitly before ordering.
Can Plesk run on Linux and Windows?
Yes, on supported versions. Check the official current system requirements before choosing an OS image. Do not use an old tutorial's OS recommendation without checking its support status.
What VPS size should I choose?
Use the official hardware requirements for your platform as a starting point, then allow room for the database, web applications, mail and backups you plan to run. Screenshot testing with one small site is a different workload from production hosting.
Is Plesk the same as cPanel?
Both manage hosting, but their account organisation, interfaces, licensing and platform support differ. cPanel & WHM separates the website-account interface from the hosting administration interface. Choose around your workload, existing accounts and migration needs.
Can I install Plesk on my existing aaPanel server?
For a first test, use a separate clean VPS or reinstall an expendable test VPS after saving your work. Hosting panels manage overlapping services; do not combine them casually on a production server.
Does using Plesk replace server administration?
No. You still need updates, restricted access, monitoring and off-server backups. A backup job that reports success should also be tested by restoring data.
A sensible first test
Use a temporary domain and non-sensitive sample data. Confirm DNS, HTTPS, the intended PHP/runtime version and backup recovery. Plan any migration before changing live DNS, and keep the old server available until you have verified the destination.
Need help? Post your Plesk version, Linux distribution or Windows Server version, relevant extension and exact error. Redact credentials and personal information from logs and screenshots.
cPanel & WHM is a commercial web hosting control panel for Linux servers. It gives website owners and hosting administrators separate interfaces for their work.
cPanel vs WHM: the key difference
cPanel is the website owner's dashboard: manage a hosting account's websites, files, databases and email.
WHM (WebHost Manager) is the administrator/reseller interface: create hosting accounts and manage hosting packages. Server administrators also use it for server-wide configuration.
Having a cPanel login does not automatically give you root or full WHM access.
Main features
Websites and domains: domain management, redirects and file management.
Email: mailboxes, webmail, forwarders and related account tools.
Databases: database management and phpMyAdmin.
PHP: MultiPHP tools, where enabled by your host.
Backups: account backup tools; server backup policies are managed separately.
Applications: WP Toolkit and other integrations, depending on the hosting package.
Available tools depend on your host's feature list, server configuration and licensing. A third-party installer or premium extension is not automatically included.
Who is it for?
Website owners using shared hosting, resellers managing customer accounts, and administrators running a hosting business. For a single experimental website, compare the licence cost with the VPS cost before choosing it.
Frequently Asked Questions
Is cPanel free?
No. cPanel & WHM requires a licence. A hosting provider may include access in its package. For your own VPS, check the appropriate Cloud licence and current terms rather than assuming the VPS price includes it.
Can I install it on Windows?
It is a Linux hosting platform. Use the current official installation requirements to choose a supported operating system and version.
Is a cheap 2 GB VPS enough?
Do not buy based on RAM alone. Check the requirements for your selected OS, storage, networking and planned workload. An installation minimum is not a comfortable production sizing recommendation.
Does the panel make my server fully managed?
No. Updates, access control, monitoring, mail deliverability and tested recovery still need an owner. Keep an off-server backup and test restoring it.
Can I install it beside aaPanel or another hosting panel?
Use a separate clean server for testing. Combining hosting panels can create conflicting web, mail and database configurations. Back up before reinstalling a VPS.
Before your first setup
Confirm the licence, supported OS and provider networking requirements. Start with a test domain, verify DNS and HTTPS, and test a backup before moving important sites. Do not change production DNS until the destination works.
Need help? Start a thread here with your OS, cPanel/WHM version, exact error and relevant redacted logs. Never post passwords, API keys or private backup links.
My Ubuntu VPS shows Nginx 502 Bad Gateway after a PHP update. I do not know which PHP-FPM version is installed. What safe checks should I do first? Please do not suggest restarting services before checking the cause.
How do you put your first website online with aaPanel?
Create the site with the correct domain and document root, confirm DNS points to the intended server, and verify a simple HTTP page. Then issue a certificate for the configured names, test HTTPS, and enable redirects only after it works. Put a small website online, prove that the domain reaches the correct server, then enable HTTPS. Start with a test subdomain if your main domain already serves a live business.
New to the panel? Read our aaPanel introduction and FAQ. This walkthrough assumes aaPanel is already installed and reachable. Interface labels can vary by release. Documentation reviewed 9 October 2026. Fresh-VPS testing and original screenshots are pending; the existing images are vendor documentation examples, not evidence of a tested server. Record the exact aaPanel, OS, web-server and PHP versions when following this walkthrough.
1. Prepare before changing DNS
You need a domain you control, its DNS dashboard, your VPS public IP, and a working web server in aaPanel. For PHP applications, install a supported PHP version compatible with the application. A static HTML test does not need a database.
If replacing an existing site, record its current DNS values and back up files and databases first. Keep the old host working during the change. Changing DNS can send some visitors to the old host and some to the new host while caches expire.
2. Point the domain to the VPS
Edit records at the provider hosting your authoritative DNS zone; this may differ from the registrar where you bought the domain.
Code:
Type Name Value
A @ YOUR_VPS_PUBLIC_IPV4
CNAME www example.com
Replace example.com and the IP placeholder with your own values. Some providers require the full domain instead of @. Do not create a CNAME where other records already exist for that same hostname. Leave mail records alone.
Check both names from your computer, if dig is installed:
Code:
dig +short A example.com
dig +short A www.example.com
dig +short AAAA example.com
dig +short AAAA www.example.com
An AAAA record advertises IPv6. Keep it only when that address actually serves this website. An old IPv6 record can cause failures even when the A record is correct. With a CDN proxy, public answers may show the CDN rather than the origin; check the configured origin separately.
3. Create the site in aaPanel
Open Website → PHP Project → Add site → Create site. Enter your domain and, if needed, www on separate lines. Check the site-specific Website Path, choose the appropriate PHP version, and create FTP/database accounts only if needed. Confirm the form. For this staged test, leave Apply for SSL off until HTTP works.
Official aaPanel documentation example; your version may look different. The PHP selection shown is illustrative, not a requirement for your application.
4. Prove that the right files are being served
Open the site's directory through aaPanel Files. In a new empty test site, create index.html containing:
Code:
<!doctype html>
<html lang="en">
<meta charset="utf-8">
<title>My first website</title>
<h1>Website setup works</h1>
<p>This is my new VPS website.</p>
</html>
Do not overwrite an existing application's index file. Visit http://example.com and http://www.example.com and confirm the exact test text appears. If you see another page, fix DNS or the domain binding before requesting a certificate.
A response alone does not prove the correct site was served; also check the page content. Upload application files only to the intended site directory, following that application's deployment instructions. Keep backups, private keys and database exports outside the publicly served directory.
5. Issue the website certificate
Open the site's SSL → Let's Encrypt settings. Select the hostnames you actually configured, choose File verification and Apply. HTTP-01 needs public access on port 80, including through the provider firewall. HTTPS traffic needs port 443. Keep administration ports restricted; do not disable the whole firewall.
Official aaPanel SSL example. Despite wording visible in this example, HTTP file verification cannot issue wildcard certificates.
A wildcard requires DNS verification. Manual TXT verification needs ongoing renewal work; it is not automatically renewed by aaPanel's documented manual method. Automated DNS verification should use narrowly scoped credentials where supported. Never post those credentials in a support thread.
6. Test HTTPS before redirecting
Visit https://example.com and the www address. Verify the certificate covers both names and the correct content loads. Do not bypass a browser certificate warning to declare success.
These checks use normal certificate validation; do not add -k. Only after HTTPS works should you enable the site's Force HTTPS option, if available. Test again for redirect loops and insecure image/script requests. Delay HSTS until you understand its persistence and all affected hostnames reliably support HTTPS.
7. Troubleshooting without guesswork
Wrong site: Compare DNS answers, domain bindings and the selected document root. Opening the bare IP can show a default site instead of your domain's site.
Timeout: Check whether the web service is running and whether the provider and server firewalls allow the needed web ports. Keep your current administrative session open when adjusting rules.
403 or 404: Confirm the index file and public directory. Use the site's error log to diagnose permissions; do not use chmod 777 as a shortcut.
Certificate validation fails: Read the exact error. Check A/AAAA, port 80 reachability, proxy behavior and the challenge path. Fix the cause before retrying repeatedly, because issuance has rate limits.
Redirect loop: Check application URL settings and CDN/origin HTTPS configuration. Avoid competing redirect rules at several layers.
8. Make the setup maintainable
Confirm the renewal job is enabled and monitor expiry rather than assuming the first successful issuance guarantees renewal. Schedule backups, keep an off-server copy and test restoration into a separate destination. Record the domain, document root, application version and recovery steps without putting passwords in that note.
Done means: Both intended hostnames serve the correct site; HTTPS validates; redirects behave as intended; renewal is monitored; recovery has been tested.
Common questions Do I need a database for the first HTML test?
No. A static index.html page checks domain mapping and file serving without involving PHP or a database. Add those only when your application needs them.
Can HTTP file verification issue a wildcard certificate?
No. A wildcard needs DNS-01 validation. Follow the current certificate-provider and aaPanel instructions for the chosen method.
Why does the site work for me but fail for someone else?
Compare A and AAAA records, DNS caching and CDN origin settings. A stale IPv6 record can point some visitors to another server.
Canonical published its Ubuntu 26.10 security overview on 6 October 2026. For hosting administrators, the useful question is which changes could affect boot recovery, automation and encrypted connections—not simply whether the release has newer packages.
Checked 7 October 2026. This is a pre-release planning article: the official roadmap schedules the final release for 15 October. It is an interim release, with support through July 2027. Check final release notes and your panel's supported OS list before planning a production move.
What matters to a server operator Boot compatibility: Canonical describes a smaller signed GRUB build. Customized /boot layouts need review, particularly with Secure Boot. This does not mean those filesystems disappear from a running Linux system.
Automation compatibility: The remaining cp, mv and rm defaults move to Rust-based core utilities. Test scripts that depend on exact command behavior, especially backup, deployment and cleanup jobs.
TLS and SSH compatibility: The overview lists OpenSSL 4.0 and OpenSSH 10.5. Legacy OpenSSL ENGINE integrations need a provider migration path. curl gains revocation checking through upki. Applications using certificates or hardware-backed keys deserve specific tests.
Confinement: dbus-broker replaces dbus-daemon while retaining AppArmor mediation. Check application behavior rather than removing confinement when an unfamiliar error appears.
A practical staging checklist
These are suggested operational checks, not a claim that every panel supports 26.10.
1. Record your current OS, panel version, web server, PHP versions and database version. Get explicit compatibility guidance from the panel vendor. “Ubuntu supported” is not enough to establish support for this specific release.
2. Create an isolated test server with representative configuration and sanitized data. Stop it from sending real customer mail, running payment jobs or connecting to production services.
3. Capture a baseline. These read-only commands help on a typical Ubuntu server:
findmnt reports the filesystem containing /boot; it does not prove Secure Boot compatibility. Version commands describe the invoked tools, not every library used by every application. Avoid sharing configuration dumps containing secrets.
4. Test an ordinary website request, PHP execution, database access, outbound HTTPS calls, scheduled tasks and certificate renewal through the existing manager. Review failures individually. Do not work around certificate errors by disabling verification.
5. Keep provider-console access available. Prove a new SSH login, required sudo access and service recovery after a staging reboot. Run backup and restore tests against isolated destinations.
When should a production VPS move?
My operational recommendation is to keep a supported, working installation patched while you evaluate the new release. Move when a documented benefit outweighs the compatibility and maintenance cost, and the panel vendor supports the target.
Before any real migration, establish a verified recovery copy and maintenance window. Define success checks and how you will preserve new writes if a rollback becomes necessary. This article intentionally provides no production upgrade command: the correct path depends on the starting release, provider image and managed stack.
Discussion: Which hosting panel and OS do you run? If you test 26.10 in staging, share a reproducible compatibility result and sanitized error—not credentials or customer data.
Low “free” memory is not enough to diagnose a Linux memory problem. Look for available memory, sustained swapping, pressure and evidence of a killed process before changing limits.
1. Capture the symptom and baseline
Note whether the site is slow, an application exited or the whole VPS becomes unresponsive. On a systemd Linux server:
The first vmstat report reflects averages since boot; compare the later samples. RSS is in KiB in this ps format and shared memory can be counted across processes, so summing RSS is only a rough estimate. Avoid posting full process arguments, which can contain credentials.
2. Distinguish useful cache from pressure
Linux uses otherwise idle memory for filesystem cache. The available estimate is more useful than free alone. Swap in use may remain after an earlier spike; sustained swap-in/out with latency is more concerning. Check the workload over time, including backups, imports and scheduled jobs.
Do not routinely drop kernel caches to make a dashboard greener. It can increase disk reads and hide the real workload. Compare symptoms with memory pressure, process growth and application logs instead.
3. Investigate OOM and container limits
Kernel logs may identify an out-of-memory kill and the selected process. A container or systemd cgroup can reach its own limit even when the host has spare memory. Inspect the relevant service/container memory limit and restart history. systemd-oomd can also terminate workloads based on pressure; inspect its journal when present.
A database, PHP pool and background workers share the same VPS. Raising every concurrency setting at once can exhaust it. Find the time-correlated change: plugin deployment, traffic surge, import, larger database cache or leak.
4. Choose a measured correction
Reduce excessive workers, bound caches, stagger heavy jobs or optimize the expensive request. If memory grows steadily under a repeatable workload, investigate a leak before using scheduled restarts as a permanent solution. Leave headroom for updates, backups and spikes.
Swap can provide a safety cushion on supported filesystems, but disk-backed memory is slower and does not create more physical RAM. Confirm provider/filesystem support and existing swap/zram before adding another mechanism. Never run swapoff on a pressured production system without enough RAM to hold the swapped pages.
5. Test and monitor
Change one setting during a maintenance window, preserve the previous configuration and compare response time, errors, available memory and swapping under similar load. Observe long enough to catch recurring jobs. An absence of OOM messages alone does not prove performance is healthy.
Useful report: OS, RAM plan, container limits, affected service, baseline samples and sanitized OOM lines. Do not publish environment dumps or process command lines containing secrets.
References: Your installed man free, man vmstat and systemd resource-control documentation; PHP-FPM pool configuration for PHP workloads.
![[Image: Createsite.Bk5m6BH_.png]](https://www.aapanel.com/docs/assets/Createsite.Bk5m6BH_.png)
![[Image: Fileverification.1EuYUWO5.png]](https://www.aapanel.com/docs/assets/Fileverification.1EuYUWO5.png)
