Skip to content

Deploy a WordPress Site

AidiPanel can provision WordPress, its database, database user, configuration, and administrator account as one workflow.

Before you start

  • Install AidiPanel using the Installation guide.
  • Point the domain's A record at the server.
  • Choose a unique WordPress administrator password.

1. Create and provision WordPress

The panel provides the simplest workflow: open Sites → Add Site, select WordPress, and complete every required WordPress field.

The equivalent CLI command reads the password from stdin:

bash
printf '%s\n' 'StrongPassword123!' |
sudo aidipanel site:add \
  --domain example.com \
  --user example \
  --type wordpress \
  --wp-title 'Example Site' \
  --wp-admin-user admin \
  --wp-admin-pass-stdin \
  --wp-admin-email admin@example.com

Avoid placing a real password directly in the command because shell history and process inspection can expose it.

The workflow creates:

  • the dedicated no-login Linux user example;
  • /home/example/htdocs/example.com;
  • an isolated PHP-FPM pool;
  • the Nginx vhost;
  • WordPress files and wp-config.php;
  • a dedicated database and database user;
  • the initial administrator account.

If provisioning fails, AidiPanel rolls back resources created by the incomplete WordPress transaction rather than leaving a half-installed site.

2. Verify DNS and the site

bash
dig +short example.com

Open http://example.com and sign in at /wp-admin/. New sites allow HTTP initially and use a temporary self-signed certificate for HTTPS until a trusted certificate is installed.

3. Install a trusted certificate

Once DNS returns the server's public IP:

bash
sudo aidipanel ssl:install --domain example.com --email admin@example.com

After the trusted certificate is active, enable force HTTPS and HSTS in the site's SSL tab when appropriate.

4. Enable cache deliberately

Page cache is off by default. For a public blog or brochure site:

bash
sudo aidipanel cache:enable --domain example.com --install-nginx-helper

Check two anonymous requests:

bash
curl -I https://example.com/
curl -I https://example.com/

The first cacheable request normally reports MISS; the next should report HIT. Logged-in sessions, administration paths, carts, checkout pages, query strings, and non-GET requests must bypass page cache.

WooCommerce

Review Multi-PHP & WooCommerce Cache before enabling page cache for a store. Never continue if logged-in, cart, or checkout requests report HIT.

5. Configure operations

The site detail page also provides:

  • file management and archive operations;
  • databases and isolated phpMyAdmin sign-on;
  • WordPress real-cron management;
  • PHP version and runtime settings;
  • local backups and scheduled S3-compatible remote backups;
  • opt-in jailed SFTP;
  • Basic Auth, IP blocking, and Cloudflare-only origin access.

Existing WordPress sites

Do not use the fresh WordPress provisioning flow when migrating an existing filesystem and database. Create a generic PHP site, transfer the existing files, import the database, then update wp-config.php. Follow Migrating from Another Panel.