CDN: Static + S3
Local or staging WordPress, HTML on a host, media on S3 via CloudFront.
Best for: You edit WordPress on your computer or a private staging site, export HTML with Tivlo SSG, and publish those files to public hosting. Media (and CSS/JS) live in S3 and are delivered through CloudFront. WordPress does not need to stay online for visitors to see images.
This is the “laptop CMS, public brochure” story. HTML goes to a static host. Pictures go to a bucket. Your computer can go to sleep.
Why S3
CloudFront cannot use localhost as an origin. Media goes to S3; HTML
goes to your static host. If you skip S3, exported pages will still
point at your laptop — which the internet cannot visit, thankfully.
What you need outside WordPress
| Piece | Role |
|---|---|
| Static HTML hosting | Where exported pages live (S3 + CloudFront, Netlify, or any web host) |
| S3 bucket for media | Stores images copied from the media library |
| CloudFront distribution (media) | Serves images from the bucket — origin = S3, not WordPress |
| Optional: custom domain | For example cdn.example.com for media, www.example.com for pages |
Tivlo does not create these resources, and it does not upload HTML for you. There is no Netlify, Vercel, or WP-CLI deploy button.
Create an S3 bucket. Create a CloudFront distribution with that
bucket as origin (Origin Access Control if the bucket is private).
Note the CDN domain and Distribution ID. Create IAM keys with
s3:PutObject, s3:DeleteObject, and
cloudfront:CreateInvalidation if you use invalidation.
Plugin Settings — configure export scope as usual. If the
published site uses a different domain, set Public Base URL to
that address (for example https://www.example.com). Save.
CDN & Media Sync → CloudFront CDN:
- Rewrite media URLs to the CDN on
- Serve CSS & JS through the CDN on (exported pages must not point at an offline local site)
- CDN Domain and CloudFront Distribution ID
- Invalidate CloudFront when synced files change on
S3 Sync (optional):
- Sync the media library to an S3 bucket on
- Sync CSS & JS used by exported pages to S3 on
- Bucket, region, optional path prefix, AWS keys
- Delete from S3 when media is deleted usually on
- Test Connection, then Save CDN Settings
Sync Existing Media — keep the tab open until the progress bar completes. Failed files retry on the next run. Only successfully synced files get CDN URLs, so a failed upload cannot 404.
Build Console → Full Rebuild. CSS and JS are collected and uploaded during export. A URL is rewritten only after its file has reached S3.
Upload the contents of wp-content/tivlo-static/ to your static
host. Point the public domain at that hosting. Confirm the media
CloudFront distribution is live. Then you may close the laptop.
Day-to-day (Scenario 2)
| When you… | What to do |
|---|---|
| Edit content locally | Save/publish in WordPress as usual |
| Add new images | They upload to S3 automatically after you save the media |
| Change CDN or S3 settings | Save CDN Settings, then Full Rebuild, then redeploy static files |
| Replace an image | Re-upload to S3; CloudFront refreshes if invalidation is on |
| Delete an image | S3 copies are removed if Delete from S3 when media is deleted is on |
| Deploy updates | Full Rebuild, upload new static files, confirm new media has synced |
How is this guide?