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.

---

---

Amazon Lightsail makes it easy to deploy a WordPress website without needing deep cloud expertise. It bundles compute, storage, and networking into simple monthly plans — perfect for bloggers, startups, or small businesses who want a quick WordPress setup with predictable costs.

💳 Important Billing Notes Before You Start

• Lightsail is not included in the standard AWS Free Tier (unlike EC2 or S3). You must add a valid credit or debit card to your AWS account to launch an instance.
• Plans now start at just $5/month. Each plan includes a fixed amount of memory, CPU, storage, and data transfer.
• Some Lightsail plans are free for the first 90 days, giving you time to test the platform before paying.
• If you have a $100 promotional AWS credit, that balance will usually be more than enough to run your first WordPress instance for many months.

---

🛠️ Step-by-Step: Create a WordPress (Bitnami) Instance

Step 1 — Set up your AWS account

1. Sign up or log in at AWS Console.
2. Add your payment method in the Billing dashboard. This is required even if you intend to use credits.

Step 2 — Open Lightsail

1. From the AWS search bar, type Lightsail.
2. In the Lightsail console, click Create instance.

Step 3 — Choose your platform and app

1. Platform: Select Linux/Unix.
2. Blueprint: Choose WordPress (Bitnami). This comes pre-installed with WordPress, PHP, MySQL, and Apache.

Step 4 — Pick your instance plan

• Select the $5/month plan to start. This gives you enough resources for a small to medium WordPress site.
• If you’re eligible, you may see a 90-day free trial tag on some of the smaller plans.

Step 5 — Launch your instance

• Name your instance and click Create instance.
• Wait a few minutes for AWS to provision your WordPress server.

Step 6 — Retrieve your WordPress admin password

• In the Lightsail console, open the instance and click Connect using SSH.
• Run the following command: cat ~/bitnami_application_password
• Copy the password. Your username will be user.

Step 7 — Access WordPress

• Open http://<your-public-ip>/wp-admin in your browser.
• Log in with user and the password you retrieved.

Step 8 — Attach a static IP

• In the Lightsail console, go to Networking → Create static IP.
• Attach it to your instance so your IP address doesn’t change when you restart.

Step 9 — Connect your domain

• Point your domain’s A record to the Lightsail static IP. You can manage DNS either in Lightsail DNS zones or your registrar’s control panel.

Step 10 — Secure and manage

• Install SSL with Let’s Encrypt or Lightsail load balancer.
• Schedule snapshots for regular backups.
• Keep WordPress, plugins, and themes updated.

---

✅ Final Thoughts

Launching WordPress on AWS Lightsail is straightforward and cost-effective. With plans starting at $5/month, and many offering a 90-day free trial, plus an optional $100 promotional credit, you have plenty of room to test, build, and grow your site without worrying about surprise bills.

Lightsail is especially great for beginners who want the simplicity of shared hosting but the flexibility of the AWS cloud.

---