Bitnami

WordPress updates can fail on Bitnami stacks when the web server process lacks write permission to the wp-content directory. Correcting ownership and group-write permissions resolves the issue.

Prerequisites

• SSH access to the Bitnami server
• sudo privileges

Steps

1. Set the correct ownership so both the bitnami user and the daemon group own the WordPress content directory:

sudo chown -R bitnami:daemon /opt/bitnami/apps/wordpress/htdocs/wp-content

2. Grant group-write permission so the web server can write files during updates:

sudo chmod -R g+w /opt/bitnami/apps/wordpress/htdocs/wp-content

3. Restart Apache to apply the changes:

sudo /opt/bitnami/ctlscript.sh restart apache

Verify

Log in to the WordPress admin dashboard and retry the update. The update should complete without a permission error.

Notes

• On Bitnami, the Apache process runs as the daemon group. Files owned by bitnami:daemon with group-write enabled allow both the SSH user and the web server to manage content.
• If the problem recurs after a future Bitnami upgrade, rerun both commands.

Bitnami restricts phpMyAdmin to localhost by default for security. The recommended approach is to access it through an SSH tunnel rather than opening it to the public internet.

Prerequisites

• SSH access to the Bitnami AWS instance
• The Bitnami SSH key file (.pem)

Steps

1. On your local machine, create an SSH tunnel that forwards local port 8888 to the phpMyAdmin port on the server:

ssh -N -L 8888:127.0.0.1:80 -i /path/to/your-key.pem bitnami@YOUR_SERVER_IP

2. Open a browser on your local machine and navigate to:

http://127.0.0.1:8888/phpmyadmin

3. If you need to allow remote access (not recommended for production), edit the phpMyAdmin Apache config:

sudo nano /opt/bitnami/apps/phpmyadmin/conf/httpd-app.conf

Locate the access restriction block and replace it with:

Require all granted

4. For Nginx-based Bitnami stacks, edit:

sudo nano /opt/bitnami/apps/phpmyadmin/conf/nginx-app.conf

5. Restart the web server after any config change:

sudo /opt/bitnami/ctlscript.sh restart apache

Verify

Access http://127.0.0.1:8888/phpmyadmin in your browser. You should see the phpMyAdmin login page.

Notes

• Always prefer the SSH tunnel method. Exposing phpMyAdmin publicly is a significant security risk.
• The default phpMyAdmin credentials on Bitnami are username root and the application password shown on first boot or in /home/bitnami/bitnami_credentials.

Bitnami WordPress sets conservative default upload limits. Increase them by editing both the Apache app config and the PHP-FPM pool config.

Prerequisites

• SSH access with sudo privileges
• Knowledge of whether your stack uses PHP-FPM (most modern Bitnami stacks do)

Steps

1. Edit the Apache application config to raise the upload limit (replace 80M with your desired size):

sudo nano /opt/bitnami/apps/wordpress/conf/httpd-app.conf

Update or add these lines:

php_value upload_max_filesize 80M
php_value post_max_size 80M

2. If your stack uses PHP-FPM (check for the file below), also edit the PHP-FPM pool settings:

sudo nano /opt/bitnami/apps/wordpress/conf/php-fpm/php-settings.conf

Update or add:

php_value[upload_max_filesize] = 80M
php_value[post_max_size] = 80M

3. Restart Apache and PHP-FPM to apply changes:

sudo /opt/bitnami/ctlscript.sh restart apache
sudo /opt/bitnami/ctlscript.sh restart php-fpm

Verify

In the WordPress admin dashboard, go to Media > Add New and attempt to upload a file larger than the previous limit. Alternatively, check phpinfo() to confirm the new values.

Notes

• post_max_size must be equal to or greater than upload_max_filesize.
• The global PHP ini is at /opt/bitnami/php/etc/php.ini, but editing the app-level configs above is preferred to avoid affecting other apps on the same server.

When WordPress prompts for FTP credentials to install plugins or perform updates, you can bypass this by defining FTP constants directly in wp-config.php or by configuring an FTP server on the Bitnami instance.

Prerequisites

• SSH access with sudo privileges
• An FTP user account on the server (create one with adduser if needed)

Steps

1. Open wp-config.php for editing:

sudo nano /opt/bitnami/apps/wordpress/htdocs/wp-config.php

2. Add the following constants above the /* That's all, stop editing! */ line. Replace values with your actual FTP credentials:

define('FS_METHOD', 'ftpext');
define('FTP_BASE', '/opt/bitnami/apps/wordpress/htdocs/');
define('FTP_USER', 'your_ftp_user');
define('FTP_PASS', 'your_ftp_password');
define('FTP_HOST', '127.0.0.1');
define('FTP_SSL', false);

3. Restart Apache and PHP-FPM:

sudo /opt/bitnami/ctlscript.sh restart apache
sudo /opt/bitnami/ctlscript.sh restart php-fpm

Verify

Go to WordPress Admin > Plugins > Add New and install any plugin. WordPress should install it without prompting for FTP credentials.

Notes

• The PHP configuration file is located at /opt/bitnami/php/etc/php.ini.
• Using FS_METHOD = 'direct' is an alternative if the web server process has write access to the WordPress directory (which it does after the permission fix in the Fix WordPress Update Failures guide).
• Never commit wp-config.php with plaintext passwords to version control.

Bitnami stacks display a small banner in the lower-right corner of the site by default. Remove it with the bnconfig utility or by excluding the banner config from Apache.

Prerequisites

• SSH access with sudo privileges

Steps — Method 1: bnconfig utility (recommended)

Run the following command to disable the banner:

sudo /opt/bitnami/apps/wordpress/bnconfig --disable_banner 1

Then restart Apache:

sudo /opt/bitnami/ctlscript.sh restart apache

Steps — Method 2: Comment out the banner include

1. Open the WordPress Apache app config:

sudo nano /opt/bitnami/apps/wordpress/conf/httpd-app.conf

2. Find the line that includes the banner config and comment it out by adding a # at the start:

#Include "/opt/bitnami/apps/wordpress/conf/banner.conf"

3. Restart Apache:

sudo /opt/bitnami/ctlscript.sh restart apache

Verify

Visit your WordPress site in a browser. The Bitnami banner should no longer appear in the lower-right corner.

Notes

• Method 1 is preferred because Bitnami upgrades may overwrite httpd-app.conf, reverting Method 2.
• If bnconfig reports an error, confirm the path — it may vary slightly between Bitnami versions.

Bitnami uses two Apache config patterns for applications — the prefix model and the virtual host model. Understanding which one your installation uses is essential before editing SSL configuration.

Key Config File Locations

• Main Bitnami Apache config: /opt/bitnami/apache2/conf/bitnami/bitnami.conf
• App prefix includes: /opt/bitnami/apache2/conf/bitnami/bitnami-apps-prefix.conf
• App vhost includes: /opt/bitnami/apache2/conf/bitnami/bitnami-apps-vhosts.conf
• WordPress prefix config: /opt/bitnami/apps/wordpress/conf/httpd-prefix.conf
• WordPress vhost config: /opt/bitnami/apps/wordpress/conf/httpd-vhosts.conf
• Bitnami SSL certs: /opt/bitnami/apache2/conf/bitnami/

Steps — Determine which model is active

1. Check which include is active in the apps prefix config:

cat /opt/bitnami/apache2/conf/bitnami/bitnami-apps-prefix.conf

If you see an uncommented Include line for WordPress, the prefix model is active.

2. To switch to the virtual host model (required for SSL with a custom domain), comment out the prefix include:

sudo nano /opt/bitnami/apache2/conf/bitnami/bitnami-apps-prefix.conf

#Include "/opt/bitnami/apps/wordpress/conf/httpd-prefix.conf"

3. Enable the virtual host include instead:

sudo nano /opt/bitnami/apache2/conf/bitnami/bitnami-apps-vhosts.conf

Include "/opt/bitnami/apps/wordpress/conf/httpd-vhosts.conf"

4. Restart Apache:

sudo /opt/bitnami/ctlscript.sh restart apache

Notes

• SSL certificates installed via Lego/Let's Encrypt are stored in /opt/bitnami/letsencrypt/ by default.
• Always test Apache config before restarting: sudo /opt/bitnami/apache2/bin/apachectl configtest

Bitnami WordPress requires specific file and directory ownership and permissions so that Apache can serve files and WordPress can write to its directories.

Prerequisites

• SSH access with sudo privileges

Key File Locations

• WordPress root: /opt/bitnami/apps/wordpress/htdocs/
• PHP config: /opt/bitnami/php/etc/php.ini
• Apache vhosts config: /opt/bitnami/apps/wordpress/conf/httpd-vhosts.conf
• Apache web root index: /opt/bitnami/apache2/htdocs/index.html

Steps

1. Set correct ownership on the WordPress directory tree:

sudo chown -R bitnami:daemon /opt/bitnami/apps/wordpress/htdocs

2. Set files to 664 (owner and group read/write, world read):

sudo find /opt/bitnami/apps/wordpress/htdocs -type f -exec chmod 664 {} \;

3. Set directories to 775 (owner and group read/write/execute, world read/execute):

sudo find /opt/bitnami/apps/wordpress/htdocs -type d -exec chmod 775 {} \;

4. Ensure the bitnami user belongs to the daemon group:

sudo usermod -aG daemon bitnami

5. Restart Apache:

sudo /opt/bitnami/ctlscript.sh restart apache

Verify

Attempt a WordPress plugin installation or file upload to confirm write access is working. Check ownership with:

ls -la /opt/bitnami/apps/wordpress/htdocs/wp-content/

Notes

• Never set files to 777. The 664/775 pattern gives the web server group write access without opening files to all users.
• After Bitnami stack upgrades, recheck permissions as they may be reset.

Bitnami does not configure outgoing mail by default. Use ssmtp or a WordPress SMTP plugin to enable reliable email delivery from your WordPress installation.

Prerequisites

• SSH access with sudo privileges
• SMTP credentials from your mail provider (e.g., Gmail, SendGrid, Mailgun)

Steps — Configure ssmtp

1. Install ssmtp if not already present:

sudo apt-get install -y ssmtp

2. Edit the ssmtp configuration file:

sudo nano /etc/ssmtp/ssmtp.conf

3. Add your SMTP provider settings (example for Gmail):

root=your@email.com
mailhub=smtp.gmail.com:587
AuthUser=your@gmail.com
AuthPass=your_app_password
UseTLS=YES
UseSTARTTLS=YES
hostname=your-server-hostname

4. Enable PHP's sendmail_path to use ssmtp. Edit the PHP ini:

sudo nano /opt/bitnami/php/etc/php.ini

Add or uncomment:

sendmail_path = "env -i /usr/sbin/sendmail -t -i"

5. Restart both Apache and PHP-FPM (restarting Apache alone is not sufficient):

sudo /opt/bitnami/ctlscript.sh restart apache
sudo /opt/bitnami/ctlscript.sh restart php-fpm

Verify

Use WordPress's built-in email test (via a plugin such as WP Mail SMTP) or send a test email from the command line:

echo "Test email body" | mail -s "Test Subject" recipient@example.com

Notes

• Gmail requires an App Password if 2FA is enabled — do not use your account password directly.
• For production use, a dedicated transactional email service (SendGrid, Mailgun, SES) is more reliable than Gmail SMTP.
• Restarting only Apache without restarting PHP-FPM will not apply PHP ini changes.

Force all HTTP traffic to HTTPS by adding a rewrite rule to the Bitnami Apache configuration. This ensures visitors always use the secure connection.

Prerequisites

• A valid SSL certificate installed for your domain
• SSH access with sudo privileges

Steps

1. Open the main Bitnami Apache config:

sudo nano /opt/bitnami/apache2/conf/bitnami/bitnami.conf

2. Add the following rewrite rules inside the <VirtualHost *:80> block:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP_HOST} !^(localhost|127\.0\.0\.1)
RewriteRule ^/(.*) https://%{SERVER_NAME}/$1 [R=301,L]

3. If your site uses a www-to-non-www (or vice versa) redirect combined with HTTPS, use this expanded ruleset instead:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,NE,R=301]

4. Test the Apache configuration:

sudo /opt/bitnami/apache2/bin/apachectl configtest

5. Restart Apache:

sudo /opt/bitnami/ctlscript.sh restart apache

Verify

Use curl to confirm the redirect is working:

curl -I http://yourdomain.com

You should see 301 Moved Permanently with a Location: https://yourdomain.com/ header.

Notes

• Excluding localhost and 127.0.0.1 from the redirect prevents loops during local testing.
• Use R=301 for permanent redirects (browser-cached). Use R=302 temporarily during testing.

Varnish is a caching HTTP reverse proxy that can dramatically improve WordPress performance. On Bitnami, Varnish is available but disabled by default.

Prerequisites

• SSH access with sudo privileges
• Bitnami WordPress stack installed

Steps

1. Check if Varnish is available in your Bitnami stack:

sudo /opt/bitnami/ctlscript.sh status varnish

2. Enable Varnish by editing its configuration file. Set the backend to point to Apache (typically port 8080):

sudo nano /opt/bitnami/varnish/etc/varnish/default.vcl

Confirm the backend block points to Apache:

backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

3. Configure Apache to listen on port 8080 instead of 80 so Varnish can take port 80:

sudo nano /opt/bitnami/apache2/conf/httpd.conf

Change Listen 80 to Listen 8080.

4. Update the WordPress wp-config.php to handle HTTPS headers forwarded through Varnish:

sudo nano /opt/bitnami/apps/wordpress/htdocs/wp-config.php

Add above the WordPress settings:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

5. Start Varnish and restart Apache:

sudo /opt/bitnami/ctlscript.sh start varnish
sudo /opt/bitnami/ctlscript.sh restart apache

Verify

Check response headers for the Varnish X-Varnish or Via header:

curl -I http://yourdomain.com

Notes

• Varnish caches pages aggressively. Logged-in WordPress users should bypass cache — configure this in default.vcl using cookie-based bypass rules.
• See the Fix Too Many Redirects with Varnish guide if you encounter redirect loops after enabling SSL with Varnish.

Mixed content warnings occur when a WordPress page served over HTTPS includes resources (images, scripts, stylesheets) loaded over HTTP. This guide covers the common causes and fixes on Bitnami.

Prerequisites

• SSH access with sudo privileges
• Admin access to the WordPress dashboard
• WP-CLI or phpMyAdmin access for database search-and-replace

Steps

1. Run a database search-and-replace to update hardcoded HTTP URLs to HTTPS using WP-CLI:

cd /opt/bitnami/apps/wordpress/htdocs
wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --all-tables

2. If the insecure links come from Jetpack Photon (URLs containing i0.wp.com or i1.wp.com), disable Photon in the Jetpack settings:

WordPress Admin > Jetpack > Settings > Performance > Disable "Speed up image load times"

3. For avatar-related insecure content, go to Settings > Discussion in WordPress admin and save the settings to regenerate avatar URLs with the correct scheme.

4. Add HTTPS enforcement in wp-config.php to prevent future mixed content:

sudo nano /opt/bitnami/apps/wordpress/htdocs/wp-config.php

define('FORCE_SSL_ADMIN', true);

5. Clear any WordPress caches (object cache, page cache plugins) after making changes.

Verify

Use your browser's developer tools (Network tab, Console) to confirm no resources are loading over HTTP. The padlock icon should appear in the address bar without warnings.

Notes

• Plugins that store absolute URLs in the database (sliders, page builders) are a common source of mixed content after migrating to HTTPS.
• The Really Simple SSL plugin can automate some of these fixes but may conflict with Bitnami's URL structure — see the Fix Really Simple SSL Plugin Error guide.

Bitnami uses htaccess.conf instead of .htaccess for security and performance. WordPress permalink rewrites will not work until you configure Apache to read this file correctly.

Prerequisites

• SSH access with sudo privileges

Steps

1. Enable the AllowOverride All directive so Apache processes rewrite rules. Edit the WordPress app config:

sudo nano /opt/bitnami/apps/wordpress/conf/httpd-app.conf

Change:

AllowOverride None

to:

AllowOverride All

2. Ensure the WordPress htaccess.conf file contains the standard WordPress rewrite rules:

cat /opt/bitnami/apps/wordpress/htdocs/htaccess.conf

If the file is missing or empty, add the default WordPress rewrite block:

sudo nano /opt/bitnami/apps/wordpress/htdocs/htaccess.conf

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

3. Ensure mod_rewrite is enabled in Apache:

grep -i "mod_rewrite" /opt/bitnami/apache2/conf/httpd.conf

The line LoadModule rewrite_module modules/mod_rewrite.so should be uncommented.

4. Restart Apache:

sudo /opt/bitnami/ctlscript.sh restart apache

5. In the WordPress admin, go to Settings > Permalinks and click Save Changes to regenerate rewrite rules.

Verify

Navigate to a WordPress post or page using its permalink (e.g., https://yourdomain.com/sample-page/). It should load correctly instead of returning a 404.

Notes

• Bitnami uses htaccess.conf (not .htaccess) as the access file. WordPress writes to .htaccess by default — you may need to copy the content manually.
• Check the Apache error log for rewrite-related errors: tail -f /opt/bitnami/apache2/logs/error_log

Activating the Really Simple SSL plugin on Bitnami WordPress can cause a fatal error related to the flush_rules() method. This is caused by a hook timing issue that can be resolved with a small code change.

Prerequisites

• SSH access with sudo privileges
• The Really Simple SSL plugin installed (but not yet activated, or recently causing errors)

Steps

1. Locate the plugin admin class file:

find /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/really-simple-ssl -name "class-admin.php"

2. Open the file and find the line (around line 97) that contains:

add_action('admin_init', array($this, 'maybe_flush_rewrite_rules'));

Change it to use the init hook instead of admin_init:

add_action('init', array($this, 'maybe_flush_rewrite_rules'));

3. Alternatively, update the Really Simple SSL plugin to the latest version, as this bug is fixed in recent releases:

cd /opt/bitnami/apps/wordpress/htdocs
wp plugin update really-simple-ssl

4. If the site is inaccessible due to the fatal error, deactivate the plugin via WP-CLI:

cd /opt/bitnami/apps/wordpress/htdocs
wp plugin deactivate really-simple-ssl

Verify

Activate the plugin again from the WordPress admin. You should no longer see the fatal error, and the plugin should complete activation and redirect to HTTPS.

Notes

• On Bitnami, HTTPS redirect is better handled via Apache config (see the Redirect HTTP to HTTPS in Bitnami Apache guide) rather than a WordPress plugin, which avoids this class of conflicts entirely.
• After SSL activation, clear your browser cache and test with a private/incognito window.

A 500 Internal Server Error when editing pages with Elementor on Bitnami is typically caused by Apache's internal redirect limit being exceeded or insufficient PHP memory. Both can be resolved by editing the WordPress Apache config.

Prerequisites

• SSH access with sudo privileges
• Access to the Apache error log

Steps

1. Check the Apache error log to confirm the cause:

tail -50 /opt/bitnami/apache2/logs/error_log

Look for messages like: AH01075: Error dispatching request or Cannot allocate memory.

2. Edit the WordPress htaccess config to increase the internal redirect limit:

sudo nano /opt/bitnami/apps/wordpress/htdocs/htaccess.conf

Add inside the <IfModule mod_rewrite.c> block:

LimitInternalRecursion 30

3. Increase PHP memory limit for Elementor. Edit the PHP-FPM pool config:

sudo nano /opt/bitnami/apps/wordpress/conf/php-fpm/php-settings.conf

Add or update:

php_value[memory_limit] = 256M

4. Also increase memory in the WordPress app config:

sudo nano /opt/bitnami/apps/wordpress/conf/httpd-app.conf

php_value memory_limit 256M

5. Restart Apache and PHP-FPM:

sudo /opt/bitnami/ctlscript.sh restart apache
sudo /opt/bitnami/ctlscript.sh restart php-fpm

Verify

Open a page in Elementor editor. The editor should load and save without a 500 error.

Notes

• Elementor recommends a minimum of 256MB PHP memory. Set it to 512MB for large sites.
• Also add define('WP_MEMORY_LIMIT', '256M'); to /opt/bitnami/apps/wordpress/htdocs/wp-config.php as a WordPress-level override.

WordPress Multisite allows you to run a network of sites from a single WordPress installation. Bitnami requires additional configuration steps to make Multisite work correctly, including domain mapping and cookie handling.

Prerequisites

• SSH access with sudo privileges
• A separate domain name for each site in the network (subdomain or separate domains)
• DNS A records pointing each domain to your server IP

Steps

1. Enable Multisite in wp-config.php:

sudo nano /opt/bitnami/apps/wordpress/htdocs/wp-config.php

Add above the /* That's all, stop editing! */ line:

define('WP_ALLOW_MULTISITE', true);

2. Log in to WordPress admin, go to Tools > Network Setup, choose your network type (subdomains or subdirectories), and follow the setup instructions.

3. Add the generated network constants to wp-config.php as instructed by the setup wizard. They will look similar to:

define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'yourdomain.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

4. Enable AllowOverride All in the WordPress Apache config to support per-site rewrite rules:

sudo nano /opt/bitnami/apps/wordpress/conf/httpd-app.conf

Set AllowOverride All.

5. Update the htaccess.conf with the Multisite rewrite rules as provided by the WordPress network setup wizard.

6. Restart Apache:

sudo /opt/bitnami/ctlscript.sh restart apache

Verify

Access the Network Admin at https://yourdomain.com/wp-admin/network/. Add a new site and verify it loads correctly.

Notes

• If you get a "Cookies are blocked" error, ensure each site has a unique domain and that cookies are not being blocked by domain mismatch.
• Subdomain Multisite requires a wildcard DNS entry (*.yourdomain.com) pointing to your server.
• Bitnami recommends using separate domain names rather than xip.io for production Multisite installations.

On some Bitnami AWS instances, running service sshd restart or systemctl restart sshd results in a "Connection timed out" error. This is caused by systemd's D-Bus connection being unavailable in the current shell session.

Prerequisites

• An active SSH session to the server
• sudo privileges

Steps

1. If you see the following error when restarting sshd:

Failed to retrieve unit: Connection timed out
Failed to restart sshd.service: Connection timed out

2. Re-execute the systemd manager in the current session to restore D-Bus connectivity:

sudo systemctl daemon-reexec

3. After the daemon-reexec completes, retry the sshd restart:

sudo systemctl restart sshd

4. If the server shows a 503 error after a reboot, the Bitnami services may not have started. Start them manually:

sudo /opt/bitnami/ctlscript.sh start

Verify

Open a new SSH session to the server to confirm sshd is accepting connections. Check service status:

sudo systemctl status sshd

Notes

• This issue typically occurs after a package upgrade that updates systemd or the init system.
• For reloading sshd config without dropping connections (e.g., after editing /etc/ssh/sshd_config), use sudo systemctl reload sshd instead of restart.
• Always keep a second SSH session open when restarting sshd to avoid being locked out.

Browser caching instructs visitors' browsers to cache static assets (images, CSS, JavaScript) locally, reducing load times on repeat visits. On Bitnami, add Expires headers via Apache's mod_expires in the htaccess.conf file.

Prerequisites

• SSH access with sudo privileges
• Apache mod_expires enabled (included in Bitnami by default)

Steps

1. Edit the WordPress htaccess config:

sudo nano /opt/bitnami/apps/wordpress/htdocs/htaccess.conf

2. Add the following block before the # BEGIN WordPress section:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresDefault "access plus 2 days"
</IfModule>

3. Verify mod_expires is loaded in Apache:

grep -i "mod_expires" /opt/bitnami/apache2/conf/httpd.conf

If the line is commented out, uncomment it:

LoadModule expires_module modules/mod_expires.so

4. Restart Apache:

sudo /opt/bitnami/ctlscript.sh restart apache

Verify

Use curl to check the response headers for a static file:

curl -I https://yourdomain.com/wp-content/themes/yourtheme/style.css

You should see Expires and Cache-Control headers in the response.

Notes

• Run a Google PageSpeed Insights test before and after to confirm the improvement.
• If using a caching plugin (W3 Total Cache, WP Super Cache), it may also manage browser cache headers — avoid duplicate configuration.

Bitnami WordPress on AWS EC2 defaults to a 40MB PHP memory limit, which is too low for many themes and plugins. Remote GET failures are often caused by network restrictions or cURL timeouts. Both issues can be resolved with configuration changes.

Prerequisites

• SSH access with sudo privileges

Steps — Increase PHP Memory Limit

1. Edit the WordPress PHP-FPM pool settings:

sudo nano /opt/bitnami/apps/wordpress/conf/php-fpm/php-settings.conf

Add or update:

php_value[memory_limit] = 256M

2. Also set the memory limit in the Apache app config:

sudo nano /opt/bitnami/apps/wordpress/conf/httpd-app.conf

php_value memory_limit 256M

3. Add the WordPress-level memory override in wp-config.php:

sudo nano /opt/bitnami/apps/wordpress/htdocs/wp-config.php

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

Steps — Fix Remote GET / cURL Errors

4. If you see cURL error 28: Operation timed out, check that outbound HTTP/HTTPS is allowed in your AWS Security Group. Ports 80 and 443 outbound must be open.

5. Check AWS EC2 instance metadata service access. Some AMIs have strict IMDSv2 requirements. Verify your instance can reach external URLs:

curl -I https://api.wordpress.org/plugins/info/1.0/

6. Increase PHP cURL timeout via wp-config.php:

define('FS_TIMEOUT', 60);
define('FS_CONNECT_TIMEOUT', 30);

7. Restart services:

sudo /opt/bitnami/ctlscript.sh restart apache
sudo /opt/bitnami/ctlscript.sh restart php-fpm

Verify

Check the WordPress admin dashboard health status at Tools > Site Health. Memory and remote request items should show as passing.

Notes

• For demo data imports, 256MB is the minimum; 512MB is recommended.
• If the EC2 instance is in a VPC with no NAT Gateway, outbound internet access may be completely blocked — consult your AWS VPC configuration.

Use the mysqladmin utility bundled with Bitnami to change the MySQL root password, or follow the password reset procedure if the current password is unknown.

Prerequisites

• SSH access with sudo privileges
• The current MySQL root password (or access to stop MySQL for a reset)

Steps — Change a Known Password

Run the following command, replacing NEW_PASSWORD with your desired password. You will be prompted for the current password:

/opt/bitnami/mysql/bin/mysqladmin -p -u root password NEW_PASSWORD

Steps — Reset a Forgotten Password

1. Stop the MySQL service:

sudo /opt/bitnami/ctlscript.sh stop mysql

2. Start MySQL with the --skip-grant-tables option to bypass authentication:

sudo /opt/bitnami/mysql/bin/mysqld_safe --skip-grant-tables &

3. Connect to MySQL without a password:

/opt/bitnami/mysql/bin/mysql -u root

4. Reset the root password:

FLUSH PRIVILEGES;
ALTER USER 'root'@'localhost' IDENTIFIED BY 'NEW_PASSWORD';
EXIT;

5. Kill the skip-grant-tables MySQL process and restart MySQL normally:

sudo killall mysqld
sudo /opt/bitnami/ctlscript.sh start mysql

6. Update the WordPress database password in wp-config.php if the WordPress DB user password also changed:

sudo nano /opt/bitnami/apps/wordpress/htdocs/wp-config.php

Update the DB_PASSWORD constant.

Verify

Test the new password by connecting to MySQL:

/opt/bitnami/mysql/bin/mysql -u root -p

Notes

• The default Bitnami MySQL credentials are in /home/bitnami/bitnami_credentials.
• After changing the password, update any other applications or scripts that connect to MySQL with the root credentials.

Bitnami stores application configuration in per-app config files. To host a new domain, create a virtual host entry that points to the appropriate document root and configure Apache to serve it.

Prerequisites

• SSH access with sudo privileges
• A domain name with its DNS A record pointing to the server IP

Key Config File Locations

• App config files directory: /opt/bitnami/apps/wordpress/conf/
• Apache extra vhosts config: /opt/bitnami/apache2/conf/extra/httpd-vhosts.conf
• Bitnami vhosts include: /opt/bitnami/apache2/conf/bitnami/bitnami-apps-vhosts.conf

Steps

1. Open the WordPress vhosts config:

sudo nano /opt/bitnami/apps/wordpress/conf/httpd-vhosts.conf

2. Add a virtual host block for your new domain:

<VirtualHost *:80>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com
    DocumentRoot "/opt/bitnami/apps/wordpress/htdocs"
    <Directory "/opt/bitnami/apps/wordpress/htdocs">
        Options FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

3. Ensure the vhosts file is included in the Bitnami apps vhosts config:

sudo nano /opt/bitnami/apache2/conf/bitnami/bitnami-apps-vhosts.conf

Include "/opt/bitnami/apps/wordpress/conf/httpd-vhosts.conf"

4. Test the Apache configuration:

sudo /opt/bitnami/apache2/bin/apachectl configtest

5. Restart Apache:

sudo /opt/bitnami/ctlscript.sh restart apache

Verify

Visit http://yourdomain.com in a browser. The WordPress site should load.

Notes

• Bitnami app configs (httpd-app.conf, httpd-prefix.conf, httpd-vhosts.conf) are separate from the main Apache config to allow clean upgrades.
• For SSL, add a corresponding <VirtualHost *:443> block with the SSL certificate paths.

Bitnami supports system cron as a reliable alternative to WordPress's built-in WP-Cron. System cron ensures scheduled tasks run on time regardless of site traffic.

Prerequisites

• SSH access with sudo privileges

Steps — Verify Existing Cron Jobs

1. Check the crontab for the bitnami user:

crontab -u bitnami -l

Steps — Add a WordPress Cron Job

2. Disable WP-Cron's built-in scheduling (recommended when using system cron). Add to wp-config.php:

sudo nano /opt/bitnami/apps/wordpress/htdocs/wp-config.php

define('DISABLE_WP_CRON', true);

3. Edit the bitnami user crontab to run WP-Cron via system cron:

crontab -u bitnami -e

4. Add a line to trigger WP-Cron every 5 minutes:

*/5 * * * * /opt/bitnami/php/bin/php /opt/bitnami/apps/wordpress/htdocs/wp-cron.php > /dev/null 2>&1

Steps — Add a Custom Application Cron Job

5. For other Bitnami apps (e.g., EspoCRM), add their specific cron command to the crontab:

*/1 * * * * /opt/bitnami/php/bin/php /opt/bitnami/apps/espocrm/htdocs/cron.php cron:run 2>&1 >> /opt/bitnami/apps/espocrm/htdocs/var/log/espocrm-cron.log

Verify

After adding the cron job, wait 5 minutes and check the WordPress scheduled events with WP-CLI:

cd /opt/bitnami/apps/wordpress/htdocs
wp cron event list

Notes

• Use the full path to the PHP binary (/opt/bitnami/php/bin/php) in crontab entries — the bitnami user's PATH may not include it.
• Redirect cron output to a log file for troubleshooting instead of discarding it with /dev/null during initial setup.

Lego is an ACME client that can obtain and renew Let's Encrypt SSL certificates. Bitnami recommends Lego for SSL certificate management on servers without the Bitnami HTTPS Configuration Tool.

Prerequisites

• SSH access with sudo privileges
• Ports 80 and 443 open in the firewall/security group
• A domain name with DNS pointing to the server

Steps — Download and Install Lego

1. Download the latest Lego release:

cd /tmp
curl -Ls https://api.github.com/repos/go-acme/lego/releases/latest   | grep browser_download_url   | grep linux_amd64   | cut -d '"' -f 4   | wget -i -

2. Extract and move the binary:

tar xf lego_*.tar.gz
sudo mkdir -p /opt/bitnami/letsencrypt
sudo mv lego /opt/bitnami/letsencrypt/lego

Steps — Obtain a Certificate

3. Stop the web server so Lego can use port 80 for the ACME challenge:

sudo /opt/bitnami/ctlscript.sh stop

4. Request the certificate (replace email and domain with your values):

sudo /opt/bitnami/letsencrypt/lego   --tls   --email="your@email.com"   --domains="yourdomain.com"   --domains="www.yourdomain.com"   --path="/opt/bitnami/letsencrypt"   run

5. Copy the obtained certificates to the Bitnami SSL directory:

sudo cp /opt/bitnami/letsencrypt/certificates/yourdomain.com.crt     /opt/bitnami/apache2/conf/bitnami/certs/server.crt
sudo cp /opt/bitnami/letsencrypt/certificates/yourdomain.com.key     /opt/bitnami/apache2/conf/bitnami/certs/server.key

6. Start the web server:

sudo /opt/bitnami/ctlscript.sh start

Steps — Set Up Auto-Renewal

7. Add a cron job to renew the certificate monthly:

sudo crontab -e

0 2 1 * * /opt/bitnami/letsencrypt/lego --email="your@email.com" --domains="yourdomain.com" --path="/opt/bitnami/letsencrypt" renew && sudo /opt/bitnami/ctlscript.sh restart apache

Verify

Visit https://yourdomain.com and confirm the browser shows a valid certificate. Check the expiry date:

echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates

Notes

• Let's Encrypt certificates expire after 90 days — the renewal cron job is essential.
• The Bitnami HTTPS Configuration Tool (sudo /opt/bitnami/bncert-tool) is a simpler alternative if available on your stack.

Adding Expires and Cache-Control headers reduces page load time by instructing browsers to cache static assets. On Bitnami WordPress running on Google Cloud, configure these headers in the Apache app config or htaccess file.

Prerequisites

• SSH access with sudo privileges
• Apache mod_expires enabled (default on Bitnami)

Steps

1. Edit the WordPress htaccess config:

sudo nano /opt/bitnami/apps/wordpress/htdocs/htaccess.conf

2. Add the following Expires configuration before the # BEGIN WordPress section:

<IfModule mod_expires.c>
ExpiresActive On

# Images
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType image/x-icon "access plus 1 year"

# Fonts
ExpiresByType font/ttf "access plus 1 year"
ExpiresByType font/woff "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"

# CSS and JavaScript
ExpiresByType text/css "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"

# Default
ExpiresDefault "access plus 2 days"
</IfModule>

<IfModule mod_headers.c>
Header append Cache-Control "public"
</IfModule>

3. Confirm mod_expires is loaded:

grep "mod_expires" /opt/bitnami/apache2/conf/httpd.conf

4. Restart Apache:

sudo /opt/bitnami/ctlscript.sh restart apache

Verify

Inspect headers on a static file:

curl -I https://yourdomain.com/wp-content/themes/yourtheme/style.css

Confirm the response includes Expires and Cache-Control: public headers.

Notes

• Google Cloud CDN and Cloud Armor may also cache responses — ensure your CDN settings align with the Expires headers you set.
• Do not cache HTML pages (text/html) aggressively, as dynamic WordPress pages should not be served stale to logged-in users.

Cross-Origin Resource Sharing (CORS) is disabled by default on Bitnami WordPress. Enable it by adding CORS headers to the WordPress Apache configuration file.

Prerequisites

• SSH access with sudo privileges
• Apache mod_headers enabled (default on Bitnami)

Steps

1. Edit the WordPress Apache app config:

sudo nano /opt/bitnami/apps/wordpress/conf/httpd-app.conf

2. Add the following CORS headers inside the main <Directory> block:

<IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin "*"
    Header set Access-Control-Allow-Methods "GET, POST, OPTIONS, PUT, DELETE"
    Header set Access-Control-Allow-Headers "Authorization, Content-Type, X-Requested-With"
</IfModule>

3. For more restrictive CORS (allowing only a specific domain), replace "*" with your domain:

Header set Access-Control-Allow-Origin "https://app.yourdomain.com"

4. Handle OPTIONS preflight requests by adding a rewrite rule in htaccess.conf:

sudo nano /opt/bitnami/apps/wordpress/htdocs/htaccess.conf

RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]

5. Verify mod_headers is loaded:

grep "mod_headers" /opt/bitnami/apache2/conf/httpd.conf

6. Restart Apache:

sudo /opt/bitnami/ctlscript.sh restart apache

Verify

Test the CORS headers with curl from the allowed origin:

curl -I -H "Origin: https://app.yourdomain.com" https://yourdomain.com/wp-json/wp/v2/posts

The response should include Access-Control-Allow-Origin in the headers.

Notes

• Using "*" as the origin allows any domain. Restrict to specific origins in production.
• CORS headers on the WordPress REST API (/wp-json/) are commonly needed for headless WordPress or mobile app integrations.

When no virtual host is defined, HTTPS redirects can be configured in the WordPress prefix config for Apache, or in the Nginx server block config for Nginx-based Bitnami stacks.

Prerequisites

• A valid SSL certificate installed
• SSH access with sudo privileges

Steps — Apache (no virtual host defined)

1. If bitnami-apps-vhosts.conf does not define a virtual host for your domain, add the redirect to the prefix config:

sudo nano /opt/bitnami/apps/wordpress/conf/httpd-prefix.conf

2. Add these rewrite rules:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP_HOST} !^(localhost|127\.0\.0\.1)
RewriteRule ^/(.*) https://%{SERVER_NAME}/$1 [R=301,L]

3. Test and restart Apache:

sudo /opt/bitnami/apache2/bin/apachectl configtest
sudo /opt/bitnami/ctlscript.sh restart apache

Steps — Nginx

4. Edit the Nginx server config:

sudo nano /opt/bitnami/nginx/conf/nginx.conf

5. Add or update the HTTP server block to redirect to HTTPS:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$host$request_uri;
}

6. Test and restart Nginx:

sudo /opt/bitnami/nginx/sbin/nginx -t
sudo /opt/bitnami/ctlscript.sh restart nginx

Verify

curl -I http://yourdomain.com

Expect a 301 Moved Permanently with Location: https://yourdomain.com/.

Notes

• Confirm whether your Bitnami stack uses Apache or Nginx: sudo /opt/bitnami/ctlscript.sh status
• See the dedicated Redirect HTTP to HTTPS in Bitnami Apache guide for the virtual-host-based approach.

A 500 error on all WordPress pages except the home page is typically caused by the AllowOverride None setting in Apache, which prevents .htaccess / htaccess.conf rewrite rules from processing sub-page requests.

Prerequisites

• SSH access with sudo privileges

Steps

1. Check the Apache error log to confirm the cause:

tail -50 /opt/bitnami/apache2/logs/error_log

Look for: Request exceeded the limit of 10 internal redirects or LimitInternalRecursion messages.

2. Edit the WordPress Apache app config:

sudo nano /opt/bitnami/apps/wordpress/conf/httpd-app.conf

3. Find the AllowOverride None directive and change it to AllowOverride All:

AllowOverride All

4. If the error log shows internal redirect limit errors, also add LimitInternalRecursion to the htaccess.conf:

sudo nano /opt/bitnami/apps/wordpress/htdocs/htaccess.conf

LimitInternalRecursion 30

5. Test and restart Apache:

sudo /opt/bitnami/apache2/bin/apachectl configtest
sudo /opt/bitnami/ctlscript.sh restart apache

Verify

Navigate to a WordPress inner page (e.g., https://yourdomain.com/about/). It should now load correctly instead of returning a 500 error.

Notes

• This issue commonly occurs after modifying permalink settings or after a Bitnami upgrade that resets httpd-app.conf.
• The home page works because it maps directly to index.php without requiring rewrite rules.

Use Apache virtual hosts to serve multiple domains from a single Bitnami server. Each domain gets its own document root and optional SSL configuration.

Prerequisites

• SSH access with sudo privileges
• DNS A records for each domain pointing to the server IP
• Document root directories created for each site

Steps

1. Create the document root directories for your sites:

sudo mkdir -p /opt/bitnami/apache2/htdocs/site1.example.com
sudo mkdir -p /opt/bitnami/apache2/htdocs/site2.example.com
sudo chown -R bitnami:daemon /opt/bitnami/apache2/htdocs/

2. Open the Apache extra vhosts config file:

sudo nano /opt/bitnami/apache2/conf/extra/httpd-vhosts.conf

3. Add virtual host blocks for each site:

<VirtualHost *:80>
    ServerName site1.example.com
    ServerAlias www.site1.example.com
    DocumentRoot "/opt/bitnami/apache2/htdocs/site1.example.com"
    <Directory "/opt/bitnami/apache2/htdocs/site1.example.com">
        Options FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

<VirtualHost *:80>
    ServerName site2.example.com
    ServerAlias www.site2.example.com
    DocumentRoot "/opt/bitnami/apache2/htdocs/site2.example.com"
    <Directory "/opt/bitnami/apache2/htdocs/site2.example.com">
        Options FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

4. Ensure the vhosts file is included in the main Apache config:

grep "httpd-vhosts.conf" /opt/bitnami/apache2/conf/httpd.conf

If not present, add:

Include conf/extra/httpd-vhosts.conf

5. Test and restart Apache:

sudo /opt/bitnami/apache2/bin/apachectl configtest
sudo /opt/bitnami/ctlscript.sh restart apache

Verify

Visit each domain in a browser to confirm the correct site loads.

Notes

• For each WordPress site, also install WordPress in the respective document root and configure a separate MySQL database.
• Add corresponding <VirtualHost *:443> blocks with SSL certificate paths for HTTPS.

MySQL 5.7+ enables strict mode by default, which can cause errors with WordPress plugins and themes that insert invalid or zero datetime values. Disable strict mode in the MySQL config to restore compatibility.

Prerequisites

• SSH access with sudo privileges

Steps

1. Check the current SQL mode:

/opt/bitnami/mysql/bin/mysql -u root -p -e "SELECT @@GLOBAL.sql_mode;"

If you see STRICT_TRANS_TABLES or NO_ZERO_IN_DATE in the output, strict mode is active.

2. Edit the MySQL configuration file:

sudo nano /opt/bitnami/mysql/conf/my.cnf

3. Find or add the [mysqld] section and set sql_mode to remove strict settings:

[mysqld]
sql_mode = "NO_ENGINE_SUBSTITUTION"

4. Restart MySQL:

sudo /opt/bitnami/ctlscript.sh restart mysql

5. Verify the new mode is active:

/opt/bitnami/mysql/bin/mysql -u root -p -e "SELECT @@GLOBAL.sql_mode;"

Verify

Retry the WordPress action that was previously failing (e.g., importing data, saving a post with a zero date). It should now complete without a MySQL error.

Notes

• Disabling strict mode is a workaround. The proper fix is to update the plugin or theme to use valid datetime values.
• Common strict-mode errors in WordPress: Incorrect datetime value: '0000-00-00 00:00:00', Data truncated for column.
• If my.cnf is not at the above path, find it with: find /opt/bitnami/mysql -name "my.cnf"

Use Apache's RewriteRule directive to create a permanent 301 redirect from one domain (or URL) to another. Place the rule in the Bitnami Apache config file.

Prerequisites

• SSH access with sudo privileges
• The source and destination URLs for the redirect

Steps

1. Open the main Bitnami Apache config:

sudo nano /opt/bitnami/apache2/conf/bitnami/bitnami.conf

2. Add the following rewrite rules inside both the <VirtualHost *:80> and <VirtualHost *:443> blocks to redirect all traffic to the new domain:

# Permanent Redirect
RewriteEngine On
RewriteRule ^(.*)$ https://newdomain.com/$1 [R=301,L]

3. For a single URL redirect (not a full domain redirect), use a more specific rule:

RewriteEngine On
RewriteRule ^/old-page/?$ https://yourdomain.com/new-page/ [R=301,L]

4. Test the Apache configuration:

sudo /opt/bitnami/apache2/bin/apachectl configtest

5. Restart Apache:

sudo /opt/bitnami/ctlscript.sh restart apache

Verify

Test the redirect with curl:

curl -I http://olddomain.com

Expect: 301 Moved Permanently with Location: https://newdomain.com/.

Notes

• 301 redirects are cached by browsers and search engines. Use 302 for temporary redirects during testing.
• To redirect a specific path pattern, adjust the RewriteRule regex accordingly.
• Alternatively, use Apache's Redirect directive for simpler cases: Redirect 301 /old-path https://newdomain.com/new-path

A "too many redirects" error typically occurs when Varnish and WordPress are both configured to redirect to HTTPS, creating a redirect loop. The fix involves telling WordPress to trust the X-Forwarded-Proto header set by Varnish.

Prerequisites

• Varnish installed and running in front of Apache on Bitnami
• SSL terminated at Varnish or a load balancer
• SSH access with sudo privileges

Steps

1. Edit wp-config.php to make WordPress recognize HTTPS when the request comes through Varnish:

sudo nano /opt/bitnami/apps/wordpress/htdocs/wp-config.php

Add above the WordPress settings block:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

2. Ensure Varnish is passing the X-Forwarded-Proto header to the backend. Edit the Varnish VCL:

sudo nano /opt/bitnami/varnish/etc/varnish/default.vcl

In the vcl_recv subroutine, add:

if (req.http.X-Forwarded-Proto == "https") {
    set req.http.X-Forwarded-Proto = "https";
} else {
    set req.http.X-Forwarded-Proto = "http";
}

3. In Apache, ensure the HTTP-to-HTTPS redirect only applies when the request is genuinely not HTTPS (not when it comes from Varnish over HTTP internally). Update the redirect rule in bitnami.conf:

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

4. Restart Varnish and Apache:

sudo /opt/bitnami/ctlscript.sh restart varnish
sudo /opt/bitnami/ctlscript.sh restart apache

Verify

Visit your site in a browser. The page should load over HTTPS without a redirect loop.

curl -I https://yourdomain.com

Notes

• The redirect loop occurs because Apache receives HTTP from Varnish (internally) and keeps redirecting to HTTPS, which Varnish fetches over HTTP again.
• After resolving the redirect loop, verify Varnish is caching correctly with varnishstat or by checking for the X-Varnish header.

For Bitnami stacks using Nginx, configure HTTPS redirection in the Nginx server block rather than in Apache. This guide covers setting up the redirect in the Nginx config.

Prerequisites

• A Bitnami stack using Nginx (not Apache)
• A valid SSL certificate installed
• SSH access with sudo privileges

Steps

1. Open the Nginx configuration file:

sudo nano /opt/bitnami/nginx/conf/nginx.conf

2. Add or update the HTTP server block to perform a 301 redirect to HTTPS:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$host$request_uri;
}

3. Ensure your HTTPS server block is correctly configured with the SSL certificate:

server {
    listen 443 ssl;
    server_name yourdomain.com www.yourdomain.com;

    ssl_certificate     /opt/bitnami/apache2/conf/bitnami/certs/server.crt;
    ssl_certificate_key /opt/bitnami/apache2/conf/bitnami/certs/server.key;

    root /opt/bitnami/apps/wordpress/htdocs;
    index index.php;
    # ... other directives
}

4. Test the Nginx configuration:

sudo /opt/bitnami/nginx/sbin/nginx -t

5. Restart Nginx:

sudo /opt/bitnami/ctlscript.sh restart nginx

Verify

Test the redirect:

curl -I http://yourdomain.com

Expect: 301 Moved Permanently with Location: https://yourdomain.com/.

Notes

• The return 301 directive in Nginx is more efficient than a rewrite rule for simple domain-wide redirects.
• Bitnami Nginx configs may also include app-specific config files. Check /opt/bitnami/apps/wordpress/conf/nginx-app.conf for additional server directives.
• Confirm your stack uses Nginx: sudo /opt/bitnami/ctlscript.sh status nginx

This reference shows a complete Bitnami Apache virtual host configuration file for a WordPress site, including both HTTP and HTTPS server blocks with SSL, rewrite rules, and standard directory settings.

Key Config File Locations

• Bitnami main config: /opt/bitnami/apache2/conf/bitnami/bitnami.conf
• App vhosts config: /opt/bitnami/apps/wordpress/conf/httpd-vhosts.conf
• Extra vhosts config: /opt/bitnami/apache2/conf/extra/httpd-vhosts.conf
• SSL certs directory: /opt/bitnami/apache2/conf/bitnami/certs/

Example Virtual Host Configuration

# HTTP VirtualHost - redirect to HTTPS
<VirtualHost *:80>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com
    DocumentRoot "/opt/bitnami/apps/wordpress/htdocs"

    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^/(.*) https://%{SERVER_NAME}/$1 [R=301,L]
</VirtualHost>

# HTTPS VirtualHost
<VirtualHost *:443>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com
    DocumentRoot "/opt/bitnami/apps/wordpress/htdocs"

    SSLEngine on
    SSLCertificateFile    "/opt/bitnami/apache2/conf/bitnami/certs/server.crt"
    SSLCertificateKeyFile "/opt/bitnami/apache2/conf/bitnami/certs/server.key"

    <Directory "/opt/bitnami/apps/wordpress/htdocs">
        Options FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorDocument 503 /503.html

    # Include the WordPress app config
    Include "/opt/bitnami/apps/wordpress/conf/httpd-app.conf"
</VirtualHost>

Steps — Apply the Config

1. Place the above config in the appropriate file (e.g., /opt/bitnami/apps/wordpress/conf/httpd-vhosts.conf).

2. Ensure the file is included in the Bitnami vhosts include:

sudo nano /opt/bitnami/apache2/conf/bitnami/bitnami-apps-vhosts.conf

Include "/opt/bitnami/apps/wordpress/conf/httpd-vhosts.conf"

3. Test and restart Apache:

sudo /opt/bitnami/apache2/bin/apachectl configtest
sudo /opt/bitnami/ctlscript.sh restart apache

Notes

• Replace yourdomain.com with your actual domain throughout.
• For multiple sites, add additional <VirtualHost> blocks or create separate vhost config files for each site.
• The SSL certificate paths shown use the default Bitnami self-signed cert location. Replace with your Let's Encrypt or commercial cert paths as appropriate.