CyberPanel Post-Install Checklist: Security, Cache & Backups

This checklist starts after CyberPanel is installed and the first website can be reached. It focuses on reducing attack surface, confirming the OpenLiteSpeed/LSPHP runtime, validating cache and database behavior, creating recoverable backups, monitoring the server and changing performance settings only when measurements justify them.

If you still need to provision the server or run the installer, use the main CyberPanel + OpenLiteSpeed Installation Guide. Keeping installation and post-installation work separate prevents these two pages from competing for the same search intent.

Last verified: September 25, 2026.

---

1. Record the Current Software Baseline

Before changing configuration, record what is actually installed.

cat /etc/os-release
uname -a
systemctl status lscpd --no-pager
systemctl status lsws --no-pager
php -v 2>/dev/null || true
ss -lntup
df -h
free -h

Also record the CyberPanel version from the panel/current CLI information and compare it with the current changelog. As of September 25, 2026, the latest changelog entry checked is v3.0.6, dated September 7, 2026.

---

2. Review CyberPanel Upgrade and Security Status

CyberPanel v3.0.5 was explicitly published as an API two-factor security update, followed by v3.0.6. That makes version review a security task, not only a feature task.

For a production upgrade:

1. read the release notes;
2. take a provider snapshot or verified full backup;
3. confirm an off-server copy exists;
4. schedule a maintenance window;
5. run the current official upgrade workflow;
6. validate panel login, websites, databases, SSL, mail and backup jobs afterward.

sh <(curl https://raw.githubusercontent.com/usmannasir/cyberpanel/stable/preUpgrade.sh || wget -O - https://raw.githubusercontent.com/usmannasir/cyberpanel/stable/preUpgrade.sh)

Do not schedule blind unattended upgrades without a recovery plan.

---

3. Secure Administrator and SSH Access

• use strong unique CyberPanel credentials;
• enable/use current multifactor capabilities where they fit your administration model;
• remove unused panel users and API access;
• use SSH keys where appropriate;
• restrict root login only after an alternative privilege path is tested;
• limit panel/SSH access by trusted source IP, VPN or another appropriate control where practical;
• keep provider-console recovery access available.

Do not lock yourself out while hardening the server.

---

4. Review Firewall Exposure Against Enabled Services

CyberPanel includes firewall management, but server/provider firewalls can exist outside the panel too. Compare what is listening with what should be reachable.

ss -lntup

Typical public services may include web traffic and intentionally enabled DNS/mail/FTP. CyberPanel administration on port 8090 should be treated as privileged access. Redis and database services should generally remain private.

---

5. Inventory Optional Services and Disable What You Do Not Need

Every daemon adds resource use and maintenance surface. Review whether this VPS actually needs:

• authoritative DNS;
• mail services;
• FTP;
• Redis;
• Memcached;
• Docker applications;
• other optional integrations.

If the server exists only to host WordPress sites, do not operate unrelated services by default.

---

6. Verify Website, Virtual Host, DNS and SSL Mapping

For every important website, confirm:

• DNS points to the expected server;
• the correct CyberPanel website/domain exists;
• the expected document root is active;
• the correct OpenLiteSpeed virtual host serves requests;
• the intended LSPHP version is active;
• the certificate covers the hostname;
• HTTP → HTTPS behavior is correct;
• certificate renewal is actually working.

Do not repeatedly reissue certificates while DNS or vhost routing is wrong.

---

7. Understand the CyberPanel Custom OpenLiteSpeed Stack

CyberPanel now documents a custom OpenLiteSpeed integration. Matching OLS, CyberPanel module and ModSecurity builds matter.

Do not mix a stock OpenLiteSpeed binary with CyberPanel's custom modules—or replace modules individually—unless the current CyberPanel documentation for your exact release says to do so.

This is especially important when following older third-party tutorials written for stock OpenLiteSpeed rather than CyberPanel's current bundled stack.

---

8. Identify the Active LSPHP Mode Before Tuning Concurrency

Do not assume every LiteSpeed PHP environment uses the same concurrency relationship.

LiteSpeed's current documentation also describes checking the real-time PHP wait queue. Sustained queueing can indicate insufficient PHP capacity, but increasing concurrency only helps when CPU, RAM and database throughput can support the extra work.

---

9. Do Not Copy Universal LSPHP or PHP Memory Values

A value copied from another VPS does not know your workload.

Size PHP concurrency and memory around:

• actual PHP process memory;
• available RAM and swap;
• CPU saturation;
• request duration;
• database throughput;
• cache hit rate;
• dynamic concurrency;
• other services on the server.

Similarly, memory_limit=512M is neither universally good nor universally bad. A large per-process ceiling can magnify memory exhaustion when many dynamic requests run concurrently.

---

10. Validate LiteSpeed Cache Before Enabling Advanced Optimization

Start with server/page-cache correctness, then test frontend optimizations one group at a time.

After significant LiteSpeed Cache changes, test:

• anonymous pages;
• logged-in areas;
• menus/search;
• forms;
• analytics/consent;
• WooCommerce cart/checkout/account if applicable;
• scheduled/cache purge behavior.

Do not enable CSS/JS delay/minification combinations all at once and then guess which setting caused a regression.

---

11. Treat Redis as an Optional Object Cache

Redis can reduce repeated WordPress/database work on suitable dynamic workloads, but it is not a substitute for full-page cache and is not mandatory for every site.

If Redis is enabled:

• keep it on loopback/private networking unless a secured remote architecture is intentional;
• do not expose port 6379 publicly;
• set an intentional memory budget;
• monitor memory and evictions;
• verify the WordPress object-cache integration is actually active;
• measure whether it improves the workload you care about.

For the architecture difference, use the Redis vs Memcached Object Caching Guide.

---

12. Review Database Health Together With PHP Capacity

Raising PHP concurrency can create more simultaneous database work.

Track:

• CPU and memory;
• active connections;
• slow queries;
• lock waits;
• disk I/O;
• WordPress autoloaded options;
• errors/timeouts.

A web-server concurrency change that simply moves the bottleneck to MariaDB is not an optimization.

---

13. Configure an Off-Server Backup Destination

A backup on the same VPS does not protect against complete server loss or destructive compromise.

CyberPanel currently documents full backups, scheduled backups, incremental backups, Google Drive, SFTP/remote destinations and other backup options. Use at least one independent destination appropriate for the site's risk level.

For scheduled local/SFTP backups, CyberPanel's documentation notes that creating a schedule is not enough—you must also add the sites to the schedule.

---

14. Test a Full CyberPanel Restore

CyberPanel's current full backup/restore guide says the Restore Backup page detects CyberPanel backup archives under /home/backup.

A safe validation drill:

1. create a completed backup;
2. copy it off-server;
3. take a fresh snapshot/backup before destructive testing;
4. place the archive under /home/backup on the restore target;
5. open Backups → Restore Backup;
6. select the archive and run restoration;
7. verify website files;
8. verify database and application login;
9. verify DNS/SSL;
10. verify file ownership and WordPress write behavior;
11. retain the original backup until validation is complete.

CyberPanel 3.0.x release notes include multiple backup/restore reliability and security changes, so restoration should be tested on the actual release you operate.

---

15. Understand Incremental Restore Scope

CyberPanel's incremental backup documentation separates website data, email, databases and metadata into restore points.

That means restoring one component does not necessarily restore every other component. In particular, current documentation notes that database restoration does not automatically change database passwords, while restoring metadata can recreate missing objects and alter stored credentials from that point in time.

Test the exact recovery mode you intend to depend on rather than assuming “incremental backup” means a complete server image.

---

16. Monitor the Server Outside CyberPanel

Use independent monitoring for important workloads.

Track:

• website availability;
• TLS expiration;
• CPU, RAM and swap;
• disk capacity and I/O;
• OpenLiteSpeed errors;
• LSPHP errors/queueing;
• database health;
• backup-job success;
• a periodic recovery test.

For external uptime monitoring, see the Uptime Kuma guide.

---

17. Establish a Performance Baseline Before Changing Limits

Record:

• cached response behavior;
• uncached/dynamic response behavior;
• CPU;
• RAM/swap;
• LSPHP processes;
• PHP process memory;
• database load;
• error rate;
• real dynamic concurrency.

Secure
  ↓
Backup + Restore-Test
  ↓
Measure Baseline
  ↓
Identify Bottleneck
  ↓
Change One Variable
  ↓
Validate
  ↓
Measure Again
  ↓
Keep or Roll Back

CyberPanel and OpenLiteSpeed do not guarantee sub-100ms TTFB, perfect Core Web Vitals or a fixed performance gain.

---

18. Common Post-Installation Mistakes

• tuning an outdated/unpatched panel before reviewing the current release;
• leaving port 8090 broadly exposed without considering access restrictions;
• disabling the only working SSH/recovery path;
• running DNS/mail/FTP services the site does not use;
• mixing stock/custom OpenLiteSpeed modules;
• copying PHP-FPM settings into an LSPHP environment;
• using a universal Max Connections value;
• enabling every LiteSpeed Cache optimization at once;
• exposing Redis/database services publicly;
• keeping backups only on the VPS;
• never testing restore;
• changing several performance layers simultaneously.

---

19. CyberPanel Post-Installation Checklist

---

Related Digital Bhatti Guides

• Installation pillar: CyberPanel + OpenLiteSpeed Installation Guide
• Hosting selection: Best Hosting for CyberPanel
• Object caching: Redis vs Memcached
• Wildcard SSL: Wildcard SSL Guide
• TTFB diagnosis: TTFB & Server Response Time

Frequently Asked Questions

Should I merge this page with the CyberPanel installation guide?

No. The installation URL should own provisioning and first-site setup. This page should remain focused on work that starts after CyberPanel is already running: security review, LSPHP/caching, Redis/database health, backup restore testing and monitoring.

Should Max Connections always equal PHP_LSAPI_CHILDREN?

Only in the relevant configuration. Current LiteSpeed documentation says non-suEXEC ProcessGroup mode uses Instances = 1 with Max Connections matching LSAPI_CHILDREN, while Worker and PHP suEXEC environments use different controls.

Should every CyberPanel WordPress site use Redis?

No. Redis is useful only when persistent object caching benefits the real workload and the service is configured securely.

Where does CyberPanel Restore Backup look for full archives?

The current CyberPanel backup/restore guide says the Restore Backup workflow detects completed archives under /home/backup.

Does a successful CyberPanel backup mean recovery is guaranteed?

No. A backup job proves an archive/job completed, not that the website can be recovered. Periodically perform a representative restore and verify files, database, SSL and application behavior.

Does CyberPanel guarantee a specific TTFB?

No. Response time depends on network path, cache state, application execution, database work, external services, server load and the request itself.