Static publishing without a large exporter host
Scale static WordPress publishing with Lambda workers
The WordPress server can stay focused on serving the source site, while the exporter coordinates the job and Lambda workers handle the processing phases that can be split into batches.
WordPress origin
↓ pages
Exporter coordinator
├→ Lambda render workers
├→ Lambda asset workers
├→ Lambda rewrite workers
└→ Lambda deploy workers
↓
S3 workspace → target S3 → CloudFront
Execution boundary
The coordinator does not have to do the heavy processing itself
Static Publisher already keeps crawl and deployment work outside WordPress/PHP. With Lambda delegation enabled, the exporter can go one step further and hand page rendering, asset fetching, final HTML rewriting and deployment to separate Lambda workers.
WordPress / source origin
│
│ serves requested frontend pages
▼
Exporter coordinator
│ owns queue, safety, incremental decisions,
│ manifests, retries, logs and final job state
│
├─ render batches ─────→ Lambda + Chromium ─┐
├─ asset batches ──────→ Lambda ────────────┤
├─ rewrite batches ────→ Lambda ────────────┤→ S3 workspace
└─ deploy batches ─────→ Lambda ────────────┘ │
└→ target S3 → CloudFront
What still limits page rendering Render workers still request pages from the WordPress origin. Increasing Lambda fan-out therefore does not make the origin infinitely fast: the source site, Lambda quotas and downstream capacity still bound effective parallelism. Asset, rewrite and deploy phases do not need to put the same load on WordPress.
Publishing flow
Use compute only while a publish job is running
The worker model separates the always-on editorial system from the short-lived processing capacity needed for publishing.
- Queue the publish from WordPress — WordPress stores configuration and the job request. PHP does not run the Node exporter or proxy the deployment traffic.
- Let the exporter coordinate the job — The coordinator resolves the work, applies safety and incremental rules, tracks retries and progress, and requests bounded parallel processing.
- Delegate processing in batches — Lambda workers can render pages, fetch assets, rewrite workspace objects and copy the completed output to the deployment target. Render batches can reuse a warm Chromium process across several pages.
- Keep completed output in S3 — With full delegation, rendered HTML and downloaded assets remain in the worker S3 workspace for rewrite and direct S3-to-S3 deployment instead of being downloaded and staged again by the coordinator.
When Lambda delegation changes the infrastructure choice
Delegate processing
Useful when publishing creates short, parallel compute peaks
- You do not want to size the exporter VM for the largest publish job.
- The site has enough pages or assets for parallel render, fetch, rewrite or deploy batches to matter.
- You prefer AWS compute costs to follow actual publish work instead of keeping extra exporter capacity running continuously.
Run processing locally
Keep the simpler model when one exporter host is already sufficient
- The site is small and publish duration is already acceptable.
- The source WordPress origin cannot benefit from more parallel page requests.
- You prefer one long-running worker host and do not need a separate Lambda worker stack.
Practical questions
Lambda delegation in Static Publisher
Does Lambda delegation remove load from WordPress completely?
No. Page-render workers still request the frontend from the WordPress origin. The delegated processing removes exporter-side work, while the origin must still serve the pages being rendered.
Does the exporter still matter after delegation?
Yes. It remains the coordinator: it owns job queues, safety and incremental decisions, compact manifests, retries, logging, invalidation and the final job state.
Does every publish need a powerful VM?
No. The coordinator can stay comparatively light because the delegated phases use Lambda only while work is running. The exact cost and throughput still depend on the configured workers, AWS limits and source-site capacity.
What happens to the generated files during full delegation?
Rendered HTML and downloaded assets stay in the S3 worker workspace. Rewrite can operate there, and deployment can copy the finished objects directly from S3 to the target S3 location.
Static Publisher architecture
Keep WordPress as the source, not the publishing worker
Static Publisher separates the editorial WordPress site, the publishing coordinator and optional Lambda processing. The product page shows how this works together with full, incremental and targeted publishing.