This is every major CloudPanel feature in one place, grouped the way you'll use them, with real screenshots from our CloudPanel 2.5.4 server on Ubuntu 24.04. New to CloudPanel? Start with What is CloudPanel? Complete overview.
Quick summary
Sites: WordPress, PHP, Node.js, Python, static and reverse proxy, each with its own Linux user.
Stack: Nginx 1.30 (HTTP/3), PHP 7.1 to 8.5, MySQL or MariaDB, Redis, Varnish Cache, ProFTPD.
Per site: PHP settings, Nginx vhost editor, databases, free SSL, security rules, SSH/FTP users, file manager, cron jobs and logs.
Server: panel users and roles, events, services, remote backups, UFW firewall, Basic Auth, 2FA and a custom panel domain.
Automation: the
Code:
clpctl
command-line tool.
1. Sites and applications Six site types. Add a WordPress site, a PHP site, a Node.js site, a Python site, a static HTML site or a reverse proxy. Each runs in its own isolated environment under its own site user.
Application templates. For PHP sites you pick an application and CloudPanel writes a matching Nginx configuration: Generic, WordPress, WooCommerce, Laravel, Symfony, Magento, Shopware, Drupal, Joomla, TYPO3, Nextcloud, Moodle, PrestaShop and more. CloudPanel says it ships 30+ configured vhost templates.
One-click WordPress. Enter the domain, title and admin user, and CloudPanel creates the site user, database and a ready WordPress install, then shows all credentials once on one page.
Node.js and Python. Node.js 12 to 24 (LTS versions) and Python 3.12 (3.14 on Ubuntu 26.04 and Debian 13), served behind Nginx. The docs cover pm2 for Node.js and uWSGI for Python.
2. PHP Every PHP version from 7.1 to 8.5, each with its own PHP-FPM service, running side by side. Switch a site's version from a dropdown at any time.
Per-site PHP settings: memory_limit, max_execution_time, max_input_time, max_input_vars, post_max_size and upload_max_filesize, without editing php.ini.
3. Nginx vhost editor
Each site's Vhost tab shows its full Nginx configuration, so you can add redirects, headers or custom rules when you need to. CloudPanel fills in placeholders such as certificate paths for you.
4. Free SSL/TLS
Issue a free Let's Encrypt certificate from the SSL/TLS tab (including the www name and other aliases); CloudPanel renews it automatically. You can also import a certificate you bought elsewhere.
5. Databases and phpMyAdmin
Databases belong to a site. Add a database and user in one form, create extra users with Read and Write or Read Only access, and open phpMyAdmin with one click, already logged in. At install you choose MySQL (our server runs Percona Server 8.4) or MariaDB. Admins can also add a remote database server.
6. Varnish Cache
Built-in full-page caching for PHP sites, switched on per site, with a cache lifetime and excluded parameters. For WordPress, the CLP Varnish Cache plugin purges the cache when you publish. Great for content sites; test carefully on shops and member areas.
7. SSH, SFTP, FTP and File Manager
Each site user can log in over SSH/SFTP with a password or SSH keys. Add extra SSH or FTP users for developers without sharing the main login.
The browser File Manager lets you upload, create, edit, rename, compress and extract files and see owners and permissions.
8. Cron jobs and logs
Schedule cron jobs per site with ready-made schedule templates; they run as the site user. The Logs tab shows Nginx and PHP access and error logs right in the panel.
9. Security Per site: block IP addresses (IPv4 and IPv6), block bots by name, protect staging sites with Basic Auth, and allow traffic only through Cloudflare.
Server-wide: a UFW firewall with add/edit/delete rules (best practice: allow port 8443 only from your IP), Basic Auth in front of the panel, two-factor authentication for panel logins, and site isolation by Linux user. fail2ban was running on our server too.
10. Backups
Scheduled remote backups of every site's files and vhost to Amazon S3, Wasabi, DigitalOcean Spaces, Dropbox, Google Drive (Workspace), Hetzner Storage Box, SFTP or any Rclone remote. On supported clouds CloudPanel can also make whole-instance snapshots.
11. Server management
Dashboard monitoring: CPU, memory, disk and load average charts.
Instance: the status of MySQL, Nginx, every PHP-FPM version, Redis and Varnish, with restart buttons and a server reboot.
Users and roles: Admin (everything), Site Manager (all sites, no Admin Area) and User (only assigned sites).
Events: a history of actions taken in the panel.
Custom panel domain: move the panel from IP:8443 to a domain such as cp.example.com with a Let's Encrypt certificate.
Interface: dark mode and many interface languages.
12. Command line: clpctl
As root, the clpctl command-line tool can add sites, databases, certificates and users, manage vhost templates and toggle Basic Auth. The main commands:
What's not included
No mail server, no DNS hosting, no Apache/LiteSpeed, no app store and no Docker manager. CloudPanel leaves those to dedicated services on purpose.
What is CloudPanel? A complete overview of the free hosting control panel
CloudPanel is a free, web-based server control panel for Debian and Ubuntu. It turns a fresh VPS or cloud server into a tuned web hosting server for PHP, WordPress, Node.js, Python, static sites and reverse proxies, all managed from a clean browser interface on port 8443. It's built for one job: running websites and web apps fast, with as little to configure as possible.
Every screenshot in this guide comes from our own test server: CloudPanel 2.5.4 on Ubuntu 24.04 (4 vCPU, 8 GB RAM), set up in October 2026.
CloudPanel at a glance
Price: free. There are no paid tiers for the panel itself.
Current version: 2.5.4 (released 1 July 2026).
Operating systems: Ubuntu 22.04, 24.04 and 26.04; Debian 12 and 13.
Hardware: x86 and ARM64; at least 1 CPU core, 2 GB RAM and 10 GB disk.
Web server: Nginx 1.30, with HTTP/3 and the PageSpeed module.
Apps: WordPress, PHP, Node.js, Python, static HTML and reverse proxies.
Panel address:
Code:
https://YOUR_SERVER_IP:8443
, or your own domain.
What you can host
When you add a site, CloudPanel asks what kind of site it is and configures Nginx to match:
WordPress: a one-click install, ready to log in with no setup wizard.
PHP applications: with ready-made templates for Laravel, Symfony, Magento, Drupal, Joomla, WooCommerce, Shopware, PrestaShop, Nextcloud, Moodle, TYPO3 and many more, plus a Generic option.
Node.js apps (for example Ghost or Strapi) and Python apps, served through Nginx.
Static HTML/CSS/JS sites.
Reverse proxies to anything else running on the server, such as a Docker container.
How CloudPanel works 1. A complete, tuned stack out of the box. One installer sets up Nginx, PHP-FPM for every PHP version from 7.1 to 8.5, MySQL or MariaDB, Redis, Varnish Cache and ProFTPD. You don't choose or compile components; CloudPanel ships them pre-configured.
2. Every site is isolated. Each site gets its own Linux user (the "site user"), and its files live in
Code:
/home/SITE_USER/htdocs/YOUR_DOMAIN
. One compromised site can't simply read another site's files.
3. Everything about a site is on one page. Open a site and you get one row of tabs: Settings (domain, PHP version and limits), Vhost (the Nginx config), Databases, Varnish Cache, SSL/TLS, Security, SSH/FTP, File Manager, Cron Jobs and Logs.
4. The Admin Area runs the server. Users and roles, an Events log, Instance (services and restarts), remote Backups, Security (firewall and Basic Auth) and Settings (custom panel domain and database servers).
5. A command-line tool too.
Code:
clpctl
lets you add sites, databases, users and Let's Encrypt certificates from SSH, which is handy for scripts and automation.
Who CloudPanel is for
Developers and agencies hosting several PHP, WordPress or Node.js sites on their own VPS.
Anyone who wants a fast Nginx stack without configuring it by hand.
Teams on AWS, Google Cloud, Azure, Oracle Cloud, DigitalOcean, Hetzner, Vultr or similar, including ARM servers.
What CloudPanel doesn't do
CloudPanel is focused by design. Know these limits before you install:
No mail server. Use an external email service (Google Workspace, Microsoft 365, Zoho, etc.) and an SMTP service for sending.
No DNS hosting. Manage DNS at your registrar or Cloudflare.
No Apache or LiteSpeed. Nginx only.
No app store or Docker manager. Run containers yourself and put a reverse-proxy site in front.
Virtual machines only. LXC, LXD and OpenVZ containers aren't supported.
Needs a clean server and at least 2 GB of RAM.
Is CloudPanel right for you?
Choose CloudPanel if you mainly host websites and web apps and want speed, site isolation and a simple interface for free. If you need mail, DNS or many one-click apps on the same server, look at a broader panel; our CloudPanel vs aaPanel comparison in this forum covers that trade-off.
Before fine-tuning PHP-FPM, SQL or Nginx for a busy website, record a repeatable baseline. Measure response time and errors alongside server resources so later changes can be compared with the same workload.
Series introduction: This lesson records low-load observations on our aaPanel Free 8.0.7 lab. It does not stress-test the server, prove maximum visitor capacity or recommend universal tuning values. PHP-FPM, OPcache, database and caching tuning belong in separate measured lessons.
1. Describe the server and workload
Our lab VPS has two available CPUs, 3.8Gi RAM and a root/data filesystem reporting 39G capacity. Installed components include Nginx 1.30.5 and MariaDB 10.11.10. The PHP 8.5 CLI binary reports 8.5.11; a CLI version alone is not proof of a website's active PHP-FPM runtime.
Record the site's selected PHP version in aaPanel, application version, database implementation, URL, authentication state, cache state and any CDN/proxy. A cached anonymous homepage and a logged-in database-heavy request are different workloads. Identify representative pages before deciding what needs tuning.
2. Check server resources before the sample
From SSH:
Code:
nproc
uptime
free -h
df -h /www
Our snapshot showed load averages of 0.32, 0.18 and 0.11, about 2.7Gi available memory, no swap used and 30% disk usage. Those are observations at the time of testing, not permanent operating conditions. See VPS resource checks for interpretation.
For serious performance work, capture CPU, memory, swap and disk-I/O behavior across the same period as the workload. A single before/after snapshot does not establish peak resource use or rule out brief pressure.
3. Measure a normal HTTPS request
On Linux or macOS, a simple diagnostic command is:
Use a hostname you control and keep normal certificate validation enabled. Check the exit code as well as HTTP status; a timeout or TLS failure should count as a failed request rather than disappearing from the results.
How to read the measurements
HTTP status: check whether the response is expected; a fast error is not a fast successful page.
TTFB: curl's time_starttransfer is elapsed time until the first response byte, including connection-related work. It is not isolated PHP execution time.
Total: time until that single response transfer completes. It does not include rendering a browser page or downloading its complete asset graph.
Validate the response content once as well. Timing a redirect, error template or login page instead of the intended content creates a misleading comparison.
4. Repeat a small sequential sample
We sent ten separate sequential requests to the static lab homepage and ten to the WordPress lab homepage, with a short delay between requests. Each request used a fresh curl process. This was a small diagnostic sample, not a concurrent load test.
Measured lab results, rounded for readability. The image is a formatted transcript rather than a performance guarantee.
Our client-side results were:
Static lab: 10/10 requests returned HTTP 200. Median TTFB 149 ms; slowest total response 240 ms.
WordPress lab: 10/10 requests returned HTTP 200. Median TTFB 184 ms; slowest total response 424 ms.
These timings include the network path from our client. We did not independently isolate application cache state, PHP time or SQL time in this introductory sample. The ten-request sample is too small to make strong tail-latency or capacity claims.
5. Record enough information to repeat the test
Keep the timestamp and timezone, client location, exact URL, request count, whether requests are sequential/concurrent, timeout, status/exit results and software/configuration versions. Note whether the response came from a CDN/cache or the origin if you have verified that distinction.
Repeat from the same client using the same workload when comparing a tuning change. Also test the actual user workflow: anonymous content, logged-in pages, search and writes can have very different costs. Do not combine those outcomes into one unexplained average.
6. Choose the next investigation from evidence
PHP worker queues or saturation: inspect PHP-FPM status/slow logs and memory per worker before choosing pm.max_children.
Database-heavy requests: inspect slow queries, query plans, indexes and connection behavior before increasing SQL limits.
Repeated anonymous content: evaluate page caching with appropriate exclusions for private or changing content.
High I/O wait: investigate storage and query/file access rather than assuming more PHP workers will help.
Slow assets/rendering: measure browser/frontend behavior; an origin response test alone cannot explain it.
A worker limit should account for measured application memory use and RAM reserved for the database, operating system and other services. A database buffer setting must fit the real shared workload. Raising every limit can increase memory pressure instead of throughput.
7. Plan a controlled comparison
Back up the exact configuration before editing it. Change one meaningful setting at a time, validate configuration, repeat the same test and compare latency, error rate and resource use. Define rollback conditions before applying changes.
A later controlled load test should use an authorized lab target, bounded duration and concurrency, realistic requests and clear stop conditions. Do not infer requests-per-second capacity or supported monthly visitors from the small sequential sample in this guide.
What this guide verified
Two lab URLs each returned HTTP 200 for ten sequential client requests. We recorded client response timings and a server-resource snapshot. No PHP, database or Nginx tuning, stress test or production configuration change was performed.
AdminsForum performance series, lesson 1: baseline measurement. Later lessons will compare specific changes against documented workloads.
Before restarting services or increasing a VPS plan, check disk capacity, memory availability, CPU load and listening ports. These read-only SSH checks help identify the resource or component that needs closer investigation.
Tested: Ubuntu 22.04.5 on our aaPanel Free 8.0.7 lab VPS. Commands inspect the server; they do not delete files, kill processes or change firewall rules. The recorded numbers are a point-in-time snapshot, not a performance benchmark or capacity guarantee.
Formatted transcript of the lab's disk, memory, CPU and local application listener checks.
1. Check filesystem capacity
From your authorized SSH session:
Code:
df -h / /www
Read Size, Used, Avail and Use%. In our lab both paths are on the same /dev/vda2 filesystem, so two lines describe the same capacity rather than two separate disks. The snapshot showed 39G total, 11G used, 26G available and 30% usage.
Run the check against the actual filesystem holding your website, database and backups. A different mounted data disk can be full even when the root filesystem is not.
2. Check inode capacity too
Code:
df -i / /www
Inodes track filesystem objects. A workload with many small files can exhaust available inodes even when data space remains. Our snapshot showed 11% inode usage. If space or inodes are nearly exhausted, identify the source before deleting anything.
3. Inspect specific directory sizes
Code:
du -sh /www/backup /www/wwwlogs
Our results were 287M for backups and 9.2M for website logs. This command measures those directories, not every possible source of disk use. Use bounded paths first rather than scanning the entire VPS during a busy period; even read-only directory scans can consume I/O.
Do not delete active database files or blindly remove logs. Review backup retention and log rotation, preserve needed evidence and confirm a restore before discarding recovery copies. If df and du disagree, investigate causes such as deleted files still held open by a process or different mount scopes.
4. Read memory availability
Code:
free -h
Our lab showed 3.8Gi total memory, 2.7Gi available and a 1.0Gi swap area with no swap used at the time.
Look at available, not just free. Linux uses memory for buffers and cache, and some can be reclaimed for applications. A small free column alone does not prove a memory shortage. Conversely, one healthy sample does not rule out spikes or a memory leak.
Sustained low availability and swap activity warrant investigation alongside application latency and logs. Do not assume adding swap solves every workload problem.
5. Compare CPU count with load over time
Code:
nproc
uptime
Our snapshot reported two available processing units and load averages of 0.13, 0.08 and 0.09. Uptime lists the 1-, 5- and 15-minute load averages.
Load average is not CPU percentage: it includes runnable work and tasks waiting in uninterruptible sleep, including some I/O waits. Compare it with available CPUs and the workload trend, then investigate CPU and I/O behavior before concluding the server needs more cores.
6. Identify large processes without dumping arguments
Code:
ps -eo pid,user,comm,%cpu,%mem --sort=-%mem | head -8
This prints process ID, user, command name and reported CPU/memory percentages, sorted by memory percentage. We tested it and saw MariaDB, aaPanel and PHP-FPM among the larger processes.
The command-name field avoids dumping full arguments, which can contain credentials. This is a quick process summary, not a complete memory accounting report or instantaneous CPU profiler. Do not kill a database or panel process just because it appears near the top.
7. Check listening TCP ports
Code:
ss -lnt
This lists listening TCP sockets with numeric addresses. A focused application check in our lab was:
Code:
ss -lnt | grep -E ':3100|:3200'
The Node app listened on 127.0.0.1:3100 and Flask on 127.0.0.1:3200. These localhost listeners are reached through Nginx; they are not directly exposed on public interfaces.
A listener on 0.0.0.0 accepts connections on IPv4 interfaces at the socket level, but firewall and provider rules can still block traffic. A listening socket does not prove outside reachability, authentication or correct application content. Verify a real request separately. Review expected listeners and avoid posting your private management entrance or raw credential-bearing output.
8. Turn the findings into a targeted next check
Filesystem nearly full: inspect the actual mount, backups, logs and inode use; plan safe retention or capacity changes.
Memory pressure: inspect process trends, worker settings and relevant application errors.
High sustained load: compare CPU count, CPU use and I/O behavior rather than equating load with percent usage.
Expected listener missing: check the corresponding service's status and startup logs.
Resources look healthy but site fails: investigate DNS, TLS, upstream mapping and application errors.
What this lesson verified
We ran df, inode checks, bounded du, free, uptime, nproc, a process summary and TCP-listener checks on the lab. No service restart, cleanup, firewall modification or resource upgrade was performed. Repeat observations across the period when a problem occurs; one calm sample cannot prove peak-load capacity.
AdminsForum CLI series. Illustration is a formatted lab-result transcript and the values will change over time.
When a website fails, check the service that handles the failing request. aaPanel-installed Nginx, PHP-FPM and database services can have different names and paths from distribution packages. Inspect the installed service before copying a generic command.
Tested lab: Ubuntu 22.04.5 and aaPanel Free 8.0.7. We checked Nginx, MariaDB under the mysqld service name, and PHP-FPM 8.4/8.5. Nginx and both PHP-FPM configuration tests passed. This lesson tested diagnostic commands without restarting those services.
Formatted transcript summarizing actual status and configuration-test results from our lab.
1. Know which component you are checking
aaPanel: management dashboard, checked with bt status.
Nginx: handles website requests and proxies dynamic work.
PHP-FPM: executes PHP for sites configured to use that PHP version.
MySQL/MariaDB: stores database data; a running database process does not prove an application's credentials work.
Restarting aaPanel does not mean you restarted the website stack. Start with the bt CLI overview for panel-specific commands.
2. Find the installed service names
From an authorized SSH administrator session:
Code:
ls /etc/init.d/nginx /etc/init.d/mysqld /etc/init.d/php-fpm-*
Our lab had nginx, mysqld, php-fpm-84 and php-fpm-85. If your server uses Apache, another PHP version or a different database setup, inspect those actual names rather than assuming these apply. Missing paths are a reason to verify installation, not to reinstall the server stack blindly.
3. Check Nginx and validate configuration
Code:
/etc/init.d/nginx status
/www/server/nginx/sbin/nginx -t
The lab's status reported Nginx running. The syntax test reported that /www/server/nginx/conf/nginx.conf was valid and the test was successful.
A syntax test does not prove the site serves the right content. After a configuration change, check a real HTTP/HTTPS request as well. If validation fails, correct the reported file and line before reloading. Keep a backup of the changed configuration.
Reload versus restart
For a reviewed Nginx configuration change, a reload asks the running server to load the new configuration. A restart stops and starts the service and can interrupt requests. The installed init script supports service controls, but this guide did not execute a reload or restart:
These are operational examples, not commands to run merely because you are reading this guide. Validate first and choose the action that the maintenance requires.
4. Check the website's PHP-FPM version
Confirm the PHP version selected for the website in aaPanel. Our lab has two separate services:
Code:
/etc/init.d/php-fpm-84 status
/etc/init.d/php-fpm-85 status
Both reported running. Version-specific configuration tests were:
Both passed. Use the matching path for your installed version. Restarting 8.4 will not repair a site served by 8.5.
If maintenance genuinely requires restarting the website's PHP-FPM service, its installed service script provides the restart action. For example:
Code:
/etc/init.d/php-fpm-85 restart
We did not execute that restart in this lesson. It can affect every site using that PHP-FPM version. Afterwards check service status, recent logs and a meaningful PHP request.
The shell's php --version can identify a CLI default rather than the PHP-FPM version handling a specific website. Do not use it as the only evidence of the site's runtime.
5. Check MySQL or MariaDB
Code:
/etc/init.d/mysqld status
Our status output identified MariaDB and active (running), despite the service script being named mysqld. Both naming and installed implementation matter when interpreting commands.
A database restart can interrupt applications and active connections. Do not restart it as the first response to an authentication or missing-table error. Confirm the actual failure and plan maintenance before using a control action such as:
Code:
/etc/init.d/mysqld restart
This restart was not executed for the lesson. Before database maintenance, preserve an appropriate backup and recovery plan. Afterwards verify service readiness and an application connection through its normal secure configuration; do not put database passwords into public command examples.
6. Verify the website beyond status
A running process is one signal, not the whole result. Check:
The intended service and PHP version.
Configuration validation after edits.
The hostname's response with normal certificate validation.
A dynamic application action and database connection where relevant.
Recent relevant errors rather than old log entries.
For example, a PHP site can still return 502 when Nginx is running but its configured PHP-FPM socket is wrong. A site can connect to the web server but fail inside the application because its database credentials are incorrect.
Common mistakes
Using system package paths for software installed under /www/server.
Restarting every service instead of diagnosing the failing component.
Checking the CLI PHP version instead of the website's configured PHP-FPM version.
Treating mysqld as proof that the database implementation must be MySQL.
Reloading invalid configuration or assuming a successful syntax test proves application health.
Posting raw logs that contain tokens or database credentials.
What our lab verified
Nginx was running and passed its configuration test. MariaDB's mysqld service was active. Both PHP-FPM 8.4 and 8.5 were running and passed configuration tests. Service restart examples were explained, not executed or claimed as tested.
AdminsForum CLI series. The image is a formatted lab-result transcript; use the service names and paths actually installed on your own server.
aaPanel's file permission editor lets you change a selected file's access mode and owner. Understand who needs access before changing a number: the correct permission depends on the application user and the specific file.
Tested: aaPanel Free 8.0.7 on Ubuntu 22.04.5. We changed one disposable non-public file from 644 to 600 through the native Files permission dialog, verified owner access and denial for an unrelated user, then restored 644. No application directory was changed recursively.
1. Understand owner, group and others
Linux permission digits describe three classes in this order: owner, group and others. Each digit combines read (4), write (2) and execute (1).
6 = read + write.
4 = read only.
7 = read + write + execute.
5 = read + execute.
0 = no permissions for that class.
For a regular file, execute means it can be executed where other conditions permit. For a directory, execute permits traversal/search; read allows listing names, and write permits directory-entry changes subject to other rules. Parent directory access also matters.
Common modes, with their limits
644 file: owner reads/writes; group and others read. Suitable for some public source/static files, but not a universal choice for private configuration.
600 file: only the owner reads/writes under ordinary mode bits. Useful where just the intended owner needs access; it can break an app running as another user.
640 file: owner reads/writes and group reads. Requires the correct group membership and parent-directory access.
755 directory: owner can manage entries; group and others can list/traverse. It does not mean every directory should be public or writable.
777: gives every class write access. Do not use it as a general fix for application permission errors.
Privileged administrators can have access beyond ordinary mode bits. ACLs, filesystem attributes and other security controls can also affect the result, so test the actual application user.
2. Find the exact file in aaPanel
Open Files and navigate to the file's directory. Check the filename, full path and current PMSN/Owner value. Our test file was /www/af-composer-lab/af-protection-lab.txt, owned by www with mode 644.
Select the intended row, open its Operate menu and choose Permission. In our version this opened Set Permission with the full target path in the title.
3. Review the dialog before applying
The dialog shows read/write/execute controls, the numeric permission field, an Owner selector and Apply to subdir. Record the existing mode and ownership so you can restore them.
For a single-file test, leave Apply to subdir unchecked. Do not apply one identical mode recursively across files and directories: directories need traversal permissions, while ordinary text files usually do not need executable bits.
Native aaPanel permission dialog for the disposable file, with owner-only mode 600 entered.
We retained owner www, entered 600 and clicked Apply. The Files row updated to 600 / www.
4. Verify as the intended user
From an authorized SSH administrator session, our checks were:
The first command reported 600 www:www. The owner www read the harmless text successfully. The unrelated nobody account received Permission denied. Those accounts already existed; we did not create another login or grant access.
Use your actual application user when testing. A successful root read is not proof that PHP, Nginx or a Python worker can read the file.
5. Understand ownership before changing it
The Owner selector changes who owns the file. Do not choose www merely because this guide uses it: check the service or deployment user for your application. Different sites and services can use different users.
For this lesson we kept existing ownership unchanged. We inspected the owner control but did not claim a tested ownership migration. Changing ownership can allow one service to write files or prevent another service from accessing them, so review the intended account before applying it.
6. Restore and verify after the test
We reopened Operate → Permission, changed 600 back to 644 and applied it to the same file only. An SSH check confirmed 644 www:www, and the original harmless text was unchanged.
For real maintenance, verify the application action you intended to repair: reading configuration, uploading a file or creating a cache entry. Restore the previous settings if the change fails, then investigate the underlying user/path problem instead of widening access repeatedly.
Diagnose Permission denied
Check the exact target and every parent directory's traversal permissions.
Identify the process user and group instead of assuming it runs as root.
Check whether it needs read access, write access or directory-entry access.
Inspect ACLs and filesystem attributes if mode bits appear correct.
Check a read-only filesystem or service isolation where applicable.
Application behavior checked and rollback available.
AdminsForum lab-tested native aaPanel guide. The screenshot contains our own disposable file; ownership changes and recursive updates were not performed.
Linux's immutable file attribute can prevent a selected file from being modified while the attribute is set. On an aaPanel server, you can test this through SSH using chattr and lsattr, then remove the attribute before legitimate updates.
Scope: This is a Linux SSH method tested on our Ubuntu 22.04.5 VPS with aaPanel Free 8.0.7. It is not a walkthrough of aaPanel Pro's File Protection feature. In this Free installation, clicking a file's Unprotected control opened a Pro upgrade screen; we did not purchase or activate Pro and did not test its protection settings.
Formatted transcript of our disposable file test: protected write blocked, unlock succeeded, and original contents restored.
What this method protects
The immutable i attribute prevents normal modification of the protected file while set. It is separate from ordinary chmod read/write permissions. An authorized administrator with the relevant capability can remove it, so it is not protection against a fully privileged attacker and does not replace updates, least-privilege access or backups.
Do not apply it recursively across a running website. Uploads, cache files, databases, logs, certificate renewals and application updates need to write files. Start with one disposable file outside a public website root.
1. Choose a disposable file and confirm its path
Our test file was:
Code:
/www/af-composer-lab/af-protection-lab.txt
It contained only the text AdminsForum disposable file protection lab. It was owned by www with mode 644 and was not served as a public website file. The surrounding directory already existed; we did not change its application files.
Create your own harmless test file in a private lab directory. Verify its contents before proceeding:
Code:
cat /absolute/path/to/test-file.txt
ls -l /absolute/path/to/test-file.txt
lsattr /absolute/path/to/test-file.txt
The examples below use a placeholder path. Replace it with the exact file you intend to test, not a directory or wildcard.
2. Apply the immutable flag
From an authorized administrator terminal:
In our lab, chattr returned exit 0 and lsattr displayed the i flag. Other letters such as e may already be present; the significant change for this test is i.
If the command reports Operation not supported, investigate the filesystem and hosting environment. Containers, filesystem types and available capabilities can affect support. Do not claim protection is active without checking the result.
3. Verify a write is blocked
Attempt a harmless append only on that disposable file:
Code:
printf 'disposable write test
' >> /absolute/path/to/test-file.txt
Our administrator-side write attempt failed with Operation not permitted, and the original file content remained unchanged. Read it again to confirm the attempted text was not added. This test verifies one file's behavior; it does not establish protection for every path on the VPS.
If the append succeeds, stop and investigate the attribute and actual target path. Do not treat a successful chattr message alone as proof.
4. Remove protection before legitimate maintenance
Confirm the i flag is absent. On the disposable file, test the append again and read its contents. Our second write succeeded after unlocking. We then restored the original harmless text and checked that the final contents matched the original and the i flag remained absent.
For a real protected configuration file, plan the maintenance process: unlock only the intended file, perform the reviewed change, verify the application and then reapply protection if it is still appropriate. Keep a record of protected paths so future updates do not fail unexpectedly.
5. Understand the aaPanel UI boundary
The Files page in our panel has a Protected column and Unprotected controls. In this Free lab, using that control opened a Pro upgrade prompt rather than a protection dialog. That observation does not establish the internal mechanism or capabilities of the Pro implementation.
Do not assume an SSH chattr change will be fully managed or accurately represented by every panel protection screen. Use lsattr and an actual disposable write test for this method. A separate Pro tutorial should test the native UI, enable/disable behavior and compatibility with application updates on a licensed test server.
Troubleshooting
chmod does not make the file writable: check lsattr; ordinary permission changes do not remove immutable protection.
File editor or deployment cannot save: confirm whether the exact target is intentionally protected, then use the planned unlock process.
Operation not supported: check filesystem support and virtualization restrictions rather than repeatedly changing permissions.
Operation not permitted when changing attributes: check your administrative privileges and relevant capabilities.
Application updates fail: review whether protection was applied to files that must change; avoid bulk protection of a live app.
What our lab verified
One disposable non-public file was created with harmless contents.
chattr +i succeeded and lsattr showed i.
A write was blocked and original contents stayed unchanged.
chattr -i succeeded and a subsequent write worked.
Original contents were restored and the file was left unlocked.
AdminsForum lab-tested SSH tutorial. The illustration is a formatted result transcript; native aaPanel Pro File Protection remains a separate test.
When an aaPanel cron job does not do what you expect, inspect its actual output and result. In our aaPanel 8.0.7 lab, the log footer said Successful even when a shell script exited with code 7. A success label alone is not enough to verify a job.
Tested: Ubuntu 22.04.5 and aaPanel Free 8.0.7. We used only the disposable AdminsForum cron execution lab task. We reproduced a nonzero script exit, checked the generated execution file, restored the harmless timestamp script and left the schedule disabled. Existing jobs were not changed.
1. Find the exact task and check its status
Open Cron → Task Lists. Confirm its name, Running/Stopped status, execution cycle and intended execution user. Check the server timezone and whether the schedule has become due. For a first task, follow Create and Test a Scheduled Shell Script.
A Stopped task is not supposed to run automatically. A manual Execute action is a separate test and does not prove automatic scheduling is enabled.
2. Read current output, not just the footer
Click the task's Log link and use Refresh log. Match the newest timestamp to the run you are investigating. Check stderr messages, missing files, command errors and the output you expected the script to create.
This only prints a diagnostic message and returns a nonzero status. It does not delete data or alter a service. Use it only in a disposable test job, not as a replacement for your live script.
The log contains simulated failure output followed by a Successful footer in the tested panel version.
The generated wrapper in this lab printed its Successful footer without checking the preceding user script's exit result. Therefore the footer cannot, by itself, establish successful application work. This finding is scoped to our installed version and shell-task wrapper; we did not assume identical behavior for every task type or release.
3. Check whether an edited script actually reached the execution file
In this lab, editing the task while it was disabled saved the new content in the panel's task record, but its existing generated execution file still contained the older timestamp script. A manual run at that point produced old output.
We inspected only this lab task's generated file to confirm the mismatch. Re-enabling the disposable task regenerated its execution file, after which the failure text appeared in the log. Do not blindly enable a destructive or broken production script just to force regeneration. Review the command first, use a safe test copy and keep a stop/rollback plan.
If an edited disabled task runs old code on your version, compare the saved content with the actual execution file or use a newly created, isolated test task containing a harmless diagnostic. Do not edit unrelated aaPanel-generated files or apply a global scheduler reset without a diagnosed reason.
4. Check the interpreter, user and paths
Scheduled execution may not load the same shell startup files as your interactive terminal. Use absolute executable paths and the right application environment. Verify that the task user can read scripts and write only the intended output directory.
For Python, use the correct virtual-environment interpreter. For PHP, use the PHP version required by that website. If a command needs a working directory, explicitly change to it and stop if that fails. Do not solve Permission denied by making the entire website tree world-writable.
5. Make success and failure visible in your own script
For a real job, emit a clear marker only after its command and result checks pass. A pattern is:
Code:
if /absolute/path/to/your-command; then
printf 'JOB_OK: command completed
'
else
code=$?
printf 'JOB_FAILED: exit=%s
' "$code" >&2
exit "$code"
fi
This is a template, not an executable job until you replace the command. Add a check for the actual result as well: a backup file should be readable and restorable, an API operation should have the expected response, and a generated report should contain the expected data. A process exiting zero is not a complete business-result test.
6. Correct the cause and rerun safely
Save the reviewed script. Use Execute for a controlled manual run, then inspect fresh output. In our lab we restored:
Because the test task was active when the corrected content was saved, its generated execution file was updated. The next manual execution printed the expected timestamp rather than the simulated failure text.
The later log entry contains the recovered timestamp output. This concrete output proves our script correction took effect.
We then disabled the lab task and confirmed its status was Stopped. This recovery test checks manual execution after a script change. Automatic timestamp scheduling was verified separately in the introductory cron guide; it was not inferred from the manual run here.
Other common causes
No new entries: task disabled, wrong timezone, schedule not due or scheduler not running.
Command not found: wrong executable path or software not installed.
Missing environment: required variables or interpreter environment not provided to the scheduled job.
Old output after editing: check generated-script freshness and the log timestamp; do not assume a saved form means the next execution uses it.
Multiple overlapping runs: choose a realistic interval and use appropriate locking for jobs that must not overlap.
Disk full or unwritable output: inspect capacity and the specific directory permissions before rerunning.
For a support request
Provide panel version, task type, schedule, execution user, sanitized script and recent relevant log lines. Remove passwords, tokens, private keys and database secrets. State whether failure occurred in manual execution, automatic execution or both.
AdminsForum lab-tested troubleshooting guide. Screenshots show our own harmless test job; they document observed behavior rather than a claim that every cron task is broken.
aaPanel's Cron page lets you schedule a shell script and inspect its execution log. Start with a harmless timestamp task so you can prove both manual execution and the automatic schedule before using it for real maintenance.
Tested: aaPanel Free 8.0.7 on Ubuntu 22.04.5. We created a one-minute Shell Script task, executed it manually, observed its automatic run and then stopped the test schedule. Existing renewal, WordPress and backup tasks were left as configured.
1. Open Cron and choose the task type
Sign in to aaPanel and choose Cron in the left menu. In Add Task, choose Shell Script. Give it a clear name; our task is AdminsForum cron execution lab. A useful task name tells you what the job does when you return to the list later.
2. Choose a short test interval
Open Execute cycle, select N Minutes and set the interval to 1. In our version the summary states that execution starts at minute 0 of each hour and runs every minute. This short interval is for verification, not a recommendation to run backups every minute.
Other displayed cycle choices include Daily, N Days, Hourly, N Hours, Weekly, Monthly, N Second and Once. Read the resulting schedule summary and confirm the server's timezone before planning a real job. The lab logs use UTC; your local clock may differ.
3. Enter a harmless script
Paste this into Script content:
This prints a label and UTC time. It does not delete files, change passwords, restart services or contact an external website. The explicit date path avoids relying on an interactive shell's PATH. The percent signs are part of the shell-script content in aaPanel; this is not a raw crontab line to paste elsewhere.
Our disposable lab used the form's default root execution user for this timestamp-only script. For a real application job, select an existing user with only the permissions it needs, and verify file ownership and access. Do not assume a script that works in your own terminal will work under a different user.
Create a clearly named Shell Script task with a one-minute test interval and harmless timestamp output.
4. Add the task and verify its row
Click Add Task. In Task Lists, find the exact name and confirm its status is Running and its execution cycle is correct. Check the intended task rather than using a batch action against every row.
A running status means the schedule is enabled. It does not prove the script has successfully completed.
5. Test manual execution first
In that task's row, click Execute. Review the confirmation and click Confirm for this harmless script. After execution, click Log. Our first entry showed:
Code:
AdminsForum cron lab: 2026-10-14 07:51:45 UTC
Successful
Check that the log contains the expected output as well as a success marker. A generic success message alone does not prove a backup archive is usable or a maintenance operation achieved its goal.
6. Verify the automatic run separately
Keep the task enabled and wait for its next schedule boundary. Do not click Execute again during this check. In the log window, use Refresh log. Our next entry appeared automatically:
Code:
AdminsForum cron lab: 2026-10-14 07:52:01 UTC
Successful
The log shows the manual execution followed by an automatic execution at the next minute boundary.
This proves the scheduler executed the timestamp script without another manual click. The panel's Last execute time column can lag behind the latest log entry, so use the refreshed log and actual task result when verifying execution.
7. Stop the lab schedule
Close the log window. Click Running in this task's Status cell. The panel asks whether to deactivate the scheduled task; confirm. The row should change to Stopped.
The completed test task is stopped, so its one-minute schedule no longer keeps running.
We kept the disabled task and its log for reference instead of deleting them. For a real production job, leave it enabled only when its script, frequency and required permissions have been verified. A manual Execute action is a separate action from enabling automatic scheduling.
If the task does not run
No log output: confirm the task is enabled and that its schedule has actually become due in the server's timezone.
Manual run works, scheduled run fails: compare user permissions, absolute paths and required environment variables. Scheduled jobs do not necessarily load your interactive shell configuration.
Permission denied: inspect the specific file and execution user; do not grant broad permissions to the whole website tree.
Command not found: use the correct executable path and confirm that software is installed.
Long-running task: allow a realistic interval and use suitable locking if overlapping runs could cause problems.
Success marker but wrong result: make the script check its own result and return a nonzero exit status on failure. Verify the output artifact or application behavior separately.
For an SSH-level scheduler check on this Ubuntu lab, systemctl is-active cron reported active. This is an additional diagnostic; it does not replace checking the task itself. Other operating systems can use different service names.
What we verified
The task was added with the intended one-minute cycle.
Manual execution printed the expected timestamp.
Automatic execution produced a later log entry without another Execute click.
The test schedule was stopped after verification.
AdminsForum lab-tested guide. This lesson establishes basic scheduling and log verification; website/database backup schedules and retention belong in their own tutorials.
This is the starting point for our aaPanel CLI tutorials. Before using individual commands, see the complete bt menu and understand which jobs it can perform.
The full aaPanel CLI menu. Options shown here match the menu we inspected on our aaPanel Free 8.0.7 lab; labels and numbers can change between releases.
What is the aaPanel CLI?
CLI means command-line interface. aaPanel provides the bt command so an authorized server administrator can manage the panel from an SSH terminal, including when the browser dashboard cannot be reached. It is a panel maintenance tool, not a replacement for every Linux or application command.
How to open this menu
Connect to your VPS through SSH using your own authorized account. Then run:
Code:
bt
If your account requires administrator elevation, use sudo bt. The menu displays numbered actions and asks which one to run. Read the current label on your own server before entering a number. To leave without choosing a change, enter 0.
Everything shown in the menu
The list below follows the option numbers rather than the screenshot's two-column layout.
0 — Cancel
1 — Restart panel
2 — Stop panel
3 — Start panel
4 — Reload panel
5 — Change panel password
6 — Change panel username
7 — Forcibly change MySQL root password
8 — Change panel port
9 — Clear panel cache
10 — Clear login limit
11 — Turn on/off IP + User-Agent Authenticator
12 — Cancel domain binding limit
13 — Cancel IP access limit
14 — View panel default info
15 — Clear system rubbish
16 — Repair panel: check for errors and update panel files
17 — Toggle compression for log cutting
18 — Toggle automatic panel backups
22 — Display panel error log
23 — Turn off BasicAuth Authenticator
24 — Turn off Google Authenticator
25 — Save a copy when modifying files in the panel
26 — Keep/remove local backups when backing up to cloud storage
27 — Turn on/off panel SSL
28 — Modify panel security entrance
33 — Lift the panel's “explosion-proof” login limit
The menu has number gaps. Do not guess missing options or assume a number has the same meaning in a different aaPanel version. Some labels are awkward translations; the detailed reference explains the actual installed handlers, including what option 33 changes.
Which kinds of tasks are available?
Panel service control: start, stop, restart and reload.
Account and access recovery: credentials, port, domain/IP restrictions and login limits.
Security settings: authentication, SSL and the private security entrance.
Diagnostics and maintenance: error logs, cache/session cleanup, repair and system cleanup.
Recovery settings: automatic panel backups, local backup retention and saved file copies.
Opening the menu is different from executing an option. Changes to passwords, security restrictions, cleanup or repair need a planned purpose and recovery route. Option 14 can print private login details; never include its output in a public tutorial image.
Start with a status check
To inspect whether the panel processes are running without selecting a menu operation:
Code:
bt status
In our lab, this reported Bt-Panel and Bt-Task running. We also opened the menu and cancelled with 0. Credential changes and security-disable options were not executed merely to make this overview.
Next lesson: detailed commands and menu options How to Use the aaPanel bt Command: Complete Command and Menu Reference
That guide explains each service command and visible menu option, when it is useful, what it changes and how to verify the result. It also includes our tested panel restart output.
AdminsForum CLI series — begin with this menu overview, then use the detailed reference for the operation you actually need.
