Managed WordPress hosting for sites on AWS Lightsail.
A Lightsail WordPress instance is almost always a Bitnami stack, and Bitnami puts everything somewhere a normal migration does not look.
What makes a Bitnami instance different.
The site is ordinary WordPress. Everything around it is in its own prefix, run by its own scripts.
Files under /opt/bitnami
WordPress, Apache and MySQL all live in Bitnami's own prefix rather than a standard docroot, so a migration that looks in /var/www finds an empty directory.
Services with their own controls
Apache and MySQL are managed by the stack's control script rather than systemd, so ordinary service commands do not stop or start them.
Cron on the instance
Certificate renewal and backups are usually crontab entries. No WordPress export can see them, so they are read directly and recreated here.
The static IP
A Lightsail static IP released early leaves the old site unreachable during exactly the window you might still want it. It goes last, not first.
The Bitnami banner
Removed through the stack's own configuration tool rather than by deleting files, which is what leaves broken references behind.
Know the stack before copying it.
Most failed Lightsail migrations are a tool assuming a standard LAMP layout and quietly copying almost nothing.
- Stack layout confirmed before the export
- Crontab and certificates captured
- Cutover at a time you choose
- Instance and static IP kept until you confirm
Off a single small instance.
A Lightsail box runs the web server, the database and everything else on one set of shared resources. Splitting those out is most of the gain.
What we change when a site arrives from Lightsail
These are the specific things a Bitnami-based instance needs, and most of them are about where things are rather than what they are.
| Setting | What we do | Why |
|---|---|---|
| File locations | Export written against Bitnami's prefix rather than a standard docroot | The stack keeps WordPress, Apache and MySQL under its own directory tree, so a tool assuming /var/www copies nothing and reports success. |
| The Bitnami banner | Removed with the stack's configuration tool, not by deleting files | Deleting the assets by hand leaves references behind that then error; the stack has a supported command for exactly this. |
| Service control | Handled through the stack's control script during the export | Apache and MySQL are not systemd units here, so the usual service commands neither stop nor start them. |
| Instance cron | Read from crontab and recreated as platform jobs | Certificate renewal and backups on a Lightsail box are cron entries that no WordPress export can see. |
| Static IP | Released only after the move is confirmed | Detaching it early makes the old site unreachable during the window you are most likely to still need it. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Why do normal migration plugins struggle with Lightsail?
How do I stop the services to take a clean copy?
What about the Bitnami banner on my site?
Should I delete the instance once the site is live here?
Do I need to know how the instance was built?
Move off Lightsail without fighting the stack layout.
Free migration that knows where Bitnami puts things, and an instance you retire on your own schedule.