SSH access
The Lightsail instance is in the old Axxya AWS tenant. It is not in the tenant that runs nexgen_v3. If the Lightsail console shows no instances, you are signed in to the wrong account.
Connecting
The simplest route needs no key setup. In the AWS console, go to Lightsail, select the instance, and choose Connect using SSH. That opens a browser terminal already authenticated.
To connect from a local terminal instead, download the key from Lightsail > Account > SSH keys, then:
chmod 400 ~/Downloads/LightsailDefaultKey-us-east-1.pem
ssh -i ~/Downloads/LightsailDefaultKey-us-east-1.pem bitnami@<instance-public-ip>
The login user is bitnami, not ubuntu or ec2-user. The shell prompt shows the private hostname, for example bitnami@ip-172-26-11-45.
The instance also has a public EC2 hostname in the form ec2-<dashed-ip>.compute-1.amazonaws.com. It is useful for confirming whether you are hitting the origin directly rather than going through Cloudflare.
File paths
The Bitnami layout uses a persistent volume, so the WordPress files are symlinked:
- WordPress root:
/opt/bitnami/wordpress wp-config.php:/opt/bitnami/wordpress/wp-config.php, a symlink to/bitnami/wordpress/wp-config.php
Always edit /bitnami/wordpress/wp-config.php directly. Editing through the symlink path risks replacing the symlink with a regular file, which breaks the persistent volume layout.
wp-config.php is owned by bitnami:daemon, so editing needs sudo. It cannot be edited from wp-admin: the Appearance and Plugin file editors only reach files inside wp-content/.
Running WP-CLI
WP-CLI is bundled with the stack, but Bitnami wraps it in a script that requires elevation so it can switch to the correct user. Running wp without sudo fails with:
ERROR ==> Please run this script as a superuser, to be able to execute WordPress CLI with the proper user
Prefix commands with sudo and pass the WordPress path, since you will usually be in the home directory:
sudo wp --info
sudo wp --path=/opt/bitnami/wordpress option get siteurl
sudo wp --path=/opt/bitnami/wordpress option get home
The Bitnami wrapper handles user switching, so --allow-root is normally unnecessary. Add it only if a command errors with a root warning.
Restarting services
sudo /opt/bitnami/ctlscript.sh restart apache
sudo /opt/bitnami/ctlscript.sh restart php-fpm
Both are needed after a wp-config.php change, since PHP-FPM holds the old configuration in its worker processes.
Editing configuration safely
Always back up, validate, then restart. Skipping the syntax check risks taking the site down with a typo, and the resulting error will usually lock you out of wp-admin.
sudo cp /bitnami/wordpress/wp-config.php /bitnami/wordpress/wp-config.php.bak
sudo nano /bitnami/wordpress/wp-config.php
php -l /bitnami/wordpress/wp-config.php
php -l must print No syntax errors detected. Only then restart the services.
In nano, Ctrl+_ followed by a line number jumps straight to that line, and sudo nano -i disables auto-indent, which otherwise mangles pasted blocks.
To roll back:
sudo cp /bitnami/wordpress/wp-config.php.bak /bitnami/wordpress/wp-config.php
sudo /opt/bitnami/ctlscript.sh restart apache
sudo /opt/bitnami/ctlscript.sh restart php-fpm
Keep the SSH session open until the change is verified. If a configuration change causes a redirect loop or a fatal error, wp-admin will be unreachable and SSH is the only way back in.
Flushing caches
Yoast caches generated sitemaps in WordPress transients. After any change that affects sitemap or URL output, clear them:
sudo wp --path=/opt/bitnami/wordpress transient delete --all
This clears every plugin's transients, not just Yoast's. That is safe, because transients are caches that regenerate on demand, though the first few page loads afterwards are slightly slower.