Why my AWS Lightsail instance for WordPress site using Amazon stack keeps getting stopped
byu/DigitalSplendid inWordPress

---

When I first set up WordPress on AWS, I believed the Amazon Lightsail WordPress blueprint would be the easiest and most reliable option.

It wasn’t.

After struggling with downtime and repeated reboots, I revisited Bitnami WordPress stack—despite its painful migration process—and surprisingly found it more stable.

This post is a practical breakdown of:

• Why Bitnami feels painful during migration
• Why Lightsail Blueprint can be unreliable in practice
• Which one you should actually choose

👉 Inspired by:
Why Bitnami WordPress Stack Makes Migration Painful (Hard Lessons) (reference conceptually aligned article)

---

⚙️ Understanding the Two Approaches

1. Bitnami WordPress Stack

Bitnami provides a pre-configured stack with:

• Apache / Nginx
• PHP
• MySQL/MariaDB
• WordPress

Everything is tightly integrated under /opt/bitnami.

👉 Official guide:
Bitnami WordPress Documentation

👍 Pros

• Production-ready configuration
• Better default security & permissions
• Consistent environment across providers

👎 Cons

• Migration is complex
• Non-standard file paths
• Requires SSH familiarity

---

2. Amazon Lightsail WordPress Blueprint

Lightsail offers a one-click WordPress install with:

• Fixed pricing (₹ equivalent of $5–$20/month tiers)
• Simple UI
• Preinstalled WordPress

👉 Setup guide:
Deploy WordPress on AWS Lightsail (Step-by-Step)

👍 Pros

• Beginner-friendly
• Fast setup (2–3 minutes)
• Predictable pricing

👎 Cons

• Limited control
• Burstable CPU limitations
• Stability issues under load

---

⚠️ The Real Problem: Lightsail Blueprint Downtime

From practical experience (and widely reported cases), Lightsail WordPress instances can:

• Become unresponsive suddenly
• Require manual reboot or even hard shutdown
• Fail under moderate CPU usage

Example real-world issues:

• Users report needing daily reboots to restore site functionality
• Instances becoming completely unresponsive, requiring shutdown from console
• Performance drops due to CPU burst credit exhaustion

💡 Why This Happens

Lightsail uses a burstable CPU model:

• You get “credits” for CPU usage
• Once exhausted → performance throttles drastically
• Result → site slowdown or crash

👉 This is fine for:

• Small blogs
• Low traffic

👉 But problematic for:

• Dynamic WordPress sites
• Plugins-heavy setups
• Traffic spikes

---

🤯 Bitnami Migration Pain (Yes, It’s Real)

Bitnami is frustrating when you try to:

• Move hosting providers
• Change server structure
• Extract WordPress manually

Why it’s painful:

• Files are inside /opt/bitnami (non-standard)
• Permissions are tightly controlled
• Services are managed via custom scripts

But here’s the truth:

👉 That complexity is also why it’s stable.

---

⚖️ Bitnami vs Lightsail: Honest Comparison

Feature	Bitnami Stack	Lightsail Blueprint
Setup	Moderate	Very easy
Migration	Hard	Easy
Stability	High	Medium / inconsistent
Performance	Predictable	Depends on CPU credits
Control	Full	Limited
Downtime risk	Low	Higher

---

🧠 Key Insight (From Experience)

👉 Lightsail Blueprint is easy to start, hard to scale reliably
👉 Bitnami is hard to migrate, but stable once running

This creates a paradox:

The more “beginner-friendly” option may cost you more time in maintenance later.

---

🛠️ When to Choose What

✅ Choose Bitnami if:

• You want long-term stability
• You can handle SSH and configs
• You are building:
  • Business site
  • SaaS MVP
  • Blog with growth potential

---

⚠️ Choose Lightsail Blueprint if:

• You are just experimenting
• You want quick deployment
• Downtime is acceptable

---

🔧 Best Hybrid Approach (Recommended)

Here’s what works best in practice:

1. Start with Lightsail (for learning)
2. Move to:
   • Bitnami on EC2 OR
   • Custom LAMP stack
3. Add:
   • CloudWatch monitoring
   • Auto-restart scripts
   • CDN (Cloudflare)

---

🚀 Final Verdict

• Bitnami = Pain upfront, peace later
• Lightsail Blueprint = Easy upfront, pain later

If you’ve already experienced:

• Random downtime
• Frequent reboots
• Performance drops

Then your conclusion is valid:

👉 Bitnami is still the better choice for serious projects.

---

✍️ Closing Thought

In cloud hosting, simplicity is often an illusion.

The real goal is not:

“How fast can I launch?”

But:

“How long can it run without breaking?”

---

---

If you’ve ever hosted WordPress on Bitnami using Amazon Lightsail, you probably know how convenient it feels at the beginning.

One-click install.
Pre-configured stack.
Security and updates handled.

It looks perfect — until you try to migrate.

After personally struggling to move a Bitnami-based WordPress site to a new cloud server, I realized why so many users complain about this setup. Even popular migration plugins failed, and manual migration became a multi-day debugging exercise.

In this post, I’ll explain:

• Why Bitnami WordPress is hard to migrate
• What Reddit users are saying
• What actually works
• Whether you should use Bitnami at all

---

The Promise of Bitnami WordPress

Bitnami offers pre-built WordPress stacks for cloud platforms like:

• AWS Lightsail
• Azure
• Google Cloud
• VirtualBox

With Bitnami, you get:

✅ Apache/Nginx + PHP + MySQL
✅ Security patches
✅ Ready-made configuration
✅ Quick deployment

For beginners, it’s attractive. You can launch a website in minutes.

But Bitnami is not standard WordPress hosting.

And that’s where the trouble begins.

---

The Core Problem: Non-Standard Architecture

A typical WordPress server looks like this:

/var/www/html/
  └── wordpress/
      ├── wp-content/
      ├── wp-config.php
      └── wp-admin/

Bitnami looks like this:

/opt/bitnami/apps/wordpress/htdocs
/opt/bitnami/wordpress
/bitnami/wordpress

With heavy use of:

• Symbolic links (symlinks)
• Custom permissions
• Vendor-managed configs

Example:

wp-config.php → /bitnami/wordpress/wp-config.php
wp-content → /bitnami/wordpress/wp-content

When you move these files to another server…

➡️ Those paths no longer exist.
➡️ The links break.
➡️ WordPress crashes.

Most migration plugins cannot handle this.

---

Why Migration Plugins Fail on Bitnami

Many users (including myself) tried tools like:

• MigrateGuru
• UpdraftPlus
• WPVivid
• All-in-One Migration

They often fail on Bitnami because:

1. Broken Symlinks

When plugins archive your site, they copy links instead of real files.

On restore:

No such file or directory
Dangling symlink

Result: missing wp-content, missing config.

---

2. Permission Conflicts

Bitnami uses strict permissions:

daemon:daemon
bitnami:bitnami

After restore:

Unable to write wp-config.php
Permission denied

Plugins cannot fix this automatically.

---

3. Custom PHP & MySQL Setup

Bitnami bundles its own:

• PHP version
• MySQL/MariaDB version
• Config files

When moving to a normal Ubuntu server:

➡️ Collation errors
➡️ Charset mismatches
➡️ Import failures

Example:

Unknown collation: utf8mb3_uca1400_ai_ci

---

What Reddit Users Are Saying

Bitnami WordPress stack and problems with migration
byu/DigitalSplendid inWordPress

A Reddit discussion about Bitnami migration highlights the same issues.

One user said:

“The folder structure and permissions tend to break normal migration plugins.”

Another commented:

“Manual move (export DB + copy wp-content) finally worked.”

A top commenter added:

“Bitnami went downhill after acquisition. Build your own stack.”

Others suggested alternatives like:

• Docker-based WordPress
• Custom VPS setups

This mirrors exactly what I experienced.

---

What Actually Works: The Manual Method

After all plugins failed, the only reliable solution was:

Step 1: Database Export

On Bitnami:

mysqldump -u root -p wordpress > db_backup.sql

---

Step 2: Copy Real Files (Not Symlinks)

Instead of /opt/bitnami/wordpress, use:

/opt/bitnami/apps/wordpress/htdocs

Copy:

wp-content/
wp-admin/
wp-includes/

---

Step 3: Rebuild on New Server

On new VM:

• Install Nginx/Apache
• Install PHP
• Install MySQL
• Create database
• Import SQL
• Recreate wp-config.php manually

---

Step 4: Fix URLs

After migration:

UPDATE wp_options
SET option_value='https://yourdomain.com'
WHERE option_name IN ('siteurl','home');

Without this, redirects break.

---

Step 5: Fix Permissions

chown -R www-data:www-data /var/www/wordpress
chmod -R 755 /var/www/wordpress

This step is critical.

---

Why Bitnami Feels “Locked In”

Bitnami is convenient, but it creates soft vendor lock-in.

You depend on:

• Their directory structure
• Their update system
• Their stack versions

Upgrading PHP, MySQL, or switching stacks is harder than normal.

As one Redditor said:

“You can’t easily upgrade PHP or MySQL.”

This limits long-term flexibility.

---

Better Alternatives in 2026

If you want fewer migration headaches, consider:

---

1. Standard VPS Setup (Recommended)

Install yourself:

• Ubuntu
• Nginx
• PHP-FPM
• MySQL/MariaDB
• WordPress

This is what you’re running now.

Pros:
✅ Portable
✅ Plugin-friendly
✅ Easy migration
✅ Full control

---

2. Docker WordPress

Using Docker:

docker-compose up

Everything runs in containers.

Pros:
✅ One-command migration
✅ Same environment everywhere
✅ No dependency issues

---

3. Managed Hosting

Providers like Hostinger, Kinsta, or Cloudways handle migration.

Pros:
✅ Support team
✅ Automatic backups
❌ Less control

---

Should You Use Bitnami at All?

Use Bitnami If:

✅ You’re testing
✅ You’re learning
✅ Short-term project
✅ No migration planned

---

Avoid Bitnami If:

❌ You plan to scale
❌ You plan to migrate
❌ You manage multiple sites
❌ You want flexibility

For serious projects, it’s better to start clean.

---

My Final Verdict

Bitnami WordPress is:

✔️ Great for beginners
✔️ Fast to deploy
❌ Painful to migrate
❌ Hard to customize long-term

Migration is possible — but only with manual work.

If you know you’ll move servers someday, skip Bitnami and build a standard stack from Day 1.

It will save you days of frustration later.

---

Useful Resources

Here are some helpful links:

• Bitnami WordPress:
  https://bitnami.com/stack/wordpress
• WordPress Manual Migration Guide:
  https://wordpress.org/support/article/moving-wordpress/
• Certbot SSL:
  https://certbot.eff.org
• Docker WordPress:
  https://hub.docker.com/_/wordpress
• AWS Lightsail:
  https://aws.amazon.com/lightsail/

---

Conclusion

My migration journey showed me one thing clearly:

Convenience today can become complexity tomorrow.

Bitnami makes WordPress easy to start — but hard to leave.

If you’re building a serious site, invest early in a clean, portable setup. Your future self will thank you.

---