AdminsForum
Guide aaPanel Complete Setup Guide for a New VPS - Printable Version

+- AdminsForum (https://adminsforum.com)
+-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels)
+--- Forum: aaPanel (https://adminsforum.com/Forum-aapanel)
+--- Thread: Guide aaPanel Complete Setup Guide for a New VPS (/Thread-guide-aapanel-complete-setup-guide-for-a-new-vps)

aaPanel Complete Setup Guide for a New VPS - DEV - 10-07-2026

How do you set up aaPanel on a new VPS?
Prepare a clean supported Linux server, install aaPanel from its official source, secure management access, install only the required web stack, and create your website. Verify DNS, HTTPS, service access and a backup restore before moving live traffic.

Review status: Documentation reviewed on 9 October 2026. A fresh-VPS installation run and original screenshots are pending. This is a preparation guide, not a claim that a specific aaPanel/OS release has been tested. Record your OS, aaPanel, web-server and PHP versions when following it.

Scope: A fresh VPS, one small PHP/static website and DNS you control. aaPanel versions, supported operating systems, installer URLs and menu labels change. Check the linked official documentation for your release before installation. This guide does not install mail, FTP or every available plugin by default.

Before starting: Keep the provider console available, verify your SSH access and take a baseline snapshot. Do not install over an existing hosting panel or production web/database stack without a supported migration plan. Never post installer output containing panel credentials or the private entrance URL.

1. Prepare a supported, clean server
Use the current aaPanel Quick Start to confirm supported OS/architecture and resource requirements. Treat the listed minimum as an installation floor, not sizing advice for your workload. Budget RAM and disk for PHP workers, the database, logs, upgrades and backups.

Read-only checks on Linux:
Code:
cat /etc/os-release uname -m free -h df -h sudo ss -lntup
Patch the OS using its supported package manager and reboot if required before installing the panel. Confirm the clock is synchronized. Record which ports already have listeners. Start with the basics in 15 Things to Do After Buying a New VPS.

2. Install from the official source
Open aaPanel Quick Start and choose the intended edition and supported installation method. Read the installer prompts and any feature/licensing terms before accepting them. Use only the official installer source; do not reuse an old command copied from a blog.

Safer download handling: Download over HTTPS with certificate verification enabled, inspect the saved script and use any vendor-provided integrity/signature checks. Avoid curl -k, wget --no-check-certificate and unreviewed curl-to-shell pipelines. If TLS verification fails, check time, CA certificates and the destination rather than disabling validation. Execute a reviewed installer only on the intended server with the privileges it requires.

Save the resulting panel URL, actual port, entrance path and initial credentials in a password manager. Treat the output as sensitive. Do not assume every installation uses port 8888 or 7800.

3. Establish panel access without broad exposure
Allow the actual panel port through the provider and guest firewalls only from your management IP/VPN where practical. Preserve SSH access. Do not open a vendor example's whole port list if you are not deploying all those services.

Use the full installation-generated URL, including the entrance path. A refused connection, timeout and wrong-path 404 have different causes. Read the troubleshooting section below before changing security settings.

A first installation may use a self-signed panel certificate. Do not enter credentials through an unexplained certificate warning or switch the panel to plain HTTP. Establish trust through a verified certificate procedure or deploy a valid certificate using the vendor-supported process. Independently verify server identity and certificate details through the trusted console/provider path. Keep panel access restricted during setup.

4. Secure panel settings and trusted HTTPS
After trusted access is established, replace initial credentials with a unique password and enable supported two-factor authentication. Keep recovery information privately. Disable panel API access unless needed and scope any API credentials carefully. Configure a sensible session timeout and available security alerts.

Use a dedicated hostname such as panel.example.com with a correct DNS-only A record; publish AAAA only if management access works over IPv6. aaPanel documents Panel SSL under Settings and certificate management under Domains. Deploy a certificate matching the panel hostname, keep the chain/key private and verify renewal.

Panel SSL and website SSL are separate deployments. A certificate on your website does not automatically secure the panel. Binding a panel domain can restrict access to that hostname and block the IP path; do not enable that restriction until DNS, TLS and recovery are proven. Check the current domain access guide for your version. Avoid introducing a reverse proxy/CDN until direct access is stable; ports and real-client-IP handling matter.

5. Install only the required web stack
For a typical PHP website, choose a supported LNMP stack (Nginx, database and PHP) or LAMP if your application specifically needs Apache behavior. Select supported runtime/database versions compatible with the application. Install only necessary PHP extensions and plugins. Do not blindly choose an old PHP release to match an outdated tutorial.

Wait for installation jobs to finish and review failures in the panel. Confirm the web server, PHP-FPM and database are running. Avoid installing a second OS-packaged web/database service over the panel-managed one; conflicting listeners and paths make troubleshooting harder.

6. Create the website and application database
In Website, add the intended domain(s), choose the root directory and runtime. If needed, create a database and a dedicated application user. Save its credentials privately and give that user only the required database access; do not configure the application to use the database administrator account.

Upload trusted application files through a supported secure method. Set the running/document root to the application's public directory where required. Keep environment files, database dumps, archives and private keys outside public access. Use the application's recommended ownership/permissions, never recursive chmod 777.

Choose the supported rewrite template for your framework/CMS. Nginx does not read Apache .htaccess rules. Verify a simple static page first, then an application route and database connectivity. If you create a temporary PHP diagnostic page, restrict it and remove it after testing because it reveals configuration details.

7. Point DNS and deploy website HTTPS
Set the site's A record to the correct public IPv4 address and add AAAA only after IPv6 testing. Preserve existing mail and verification records. Read DNS Records Explained if unsure.

Verify resolution from your workstation:
Code:
dig +short A example.com dig +short AAAA example.com
Use Website SSL or the Domains certificate manager as supported by your version. Choose a validation method you can complete. HTTP validation needs public access to the challenge path; DNS validation needs the exact TXT record or appropriately scoped DNS API access. Wildcards require DNS validation. Check CAA if issuance is denied.

After issuance, test every hostname in the certificate, the chain and automatic renewal. Enable Force HTTPS only after HTTPS works. Check for mixed content and redirect loops, particularly if a CDN is involved. Do not repeatedly retry issuance without reading the error; CA rate limits can slow recovery.

8. Expose only the intended services
A basic website generally needs public TCP 80/443. Keep management restricted and database/cache ports private. If you do not need FTP or mail, do not install them or open their ports. Review provider and panel/guest firewall rules together, including IPv6. Docker-published ports require separate review if you later add containers.

Check listeners:
Code:
sudo ss -lntup
Test a new SSH/panel session and an external website request after changes. Do not disable the entire firewall to solve a single missing rule.

9. Configure backups, jobs and alerts
Schedule both website-file and application-consistent database backups. Include required configuration, and verify the scope of aaPanel's panel/Backup Restore features rather than assuming every plugin and dependency is included. Local backups consume disk and disappear with the server; send an encrypted copy off-site with retention and limited credentials.

Restore to an isolated temporary server before relying on the backup. Check files, database contents, runtime/extensions and application behavior. Inspect overwrite warnings carefully; never test a restore by overwriting the only live copy.

Add only required application cron jobs using the intended runtime/user. Monitor disk/inodes, failed jobs, uptime, certificate expiry and backup age. Test notification delivery. Keep panel, plugins, runtime and application updates on a documented maintenance schedule.

10. Final acceptance checks
  • Fresh SSH and trusted panel login work through the intended management path.
  • The site works over HTTPS, including application routes, uploads and database operations.
  • Only intended ports are publicly reachable over IPv4/IPv6.
  • Certificate renewal and scheduled jobs are configured and monitored.
  • An off-site backup has been restored and checked.
  • A planned reboot preserves the expected services, access rules and schedules.

Troubleshooting
  • Panel timeout: Check the actual port, provider firewall, guest rules and listener through the console. Confirm your source IP still matches any allowlist.
  • Panel 404: Confirm the full entrance path and any bound-domain requirement. Do not share that path publicly.
  • Website shows a default page: Check DNS/proxy behavior, domain mapping and the active site's document root.
  • Static page works but PHP returns 502: Check the site's selected PHP version, FPM status and Nginx upstream/error log. See the Nginx 502 troubleshooting guide.
  • 403 or permission error: Inspect the exact log, index/document-root settings, ownership and security policy. Avoid blanket permission changes.
  • Database connection fails: Check the application host/socket, database name/user and permissions. Keep the database private while fixing it.
  • Certificate fails: Read the validation log and verify DNS, challenge reachability and CAA before another attempt.

Official documentation
For help, include aaPanel version, OS, chosen stack, the step that failed and a redacted error. Never include panel passwords, database credentials, API tokens, private keys or full installer login output.

Common questions
Can I install aaPanel alongside another hosting panel?
Use a clean supported server. Existing panels and web/database stacks can conflict; use a separate server or a supported migration plan.

Does website SSL also secure the aaPanel login?
No. Website certificates and the panel management certificate are separate. Verify the panel hostname and its certificate independently.

Which panel port should I open?
Use the actual port from your own installation output. Restrict it to your management IP or VPN where practical; do not assume a tutorial's port is correct.

Related aaPanel guides