When your application needs to generate PDFs from HTML, you face a fundamental architectural decision: should you run a self-hosted rendering solution on your own infrastructure, or should you use a cloud PDF API? Both approaches have merit, and the right choice depends on your scale, team, budget, and specific requirements. Let us break down the trade-offs.
The Self-Hosted Approach
Self-hosted PDF generation typically means running a headless browser (Puppeteer, Playwright) or a specialized tool (wkhtmltopdf, WeasyPrint) on your own servers. You control the entire rendering pipeline.
Popular Self-Hosted Tools
- Puppeteer / Playwright — Node.js libraries that control a headless Chromium instance. They offer the highest rendering fidelity since they use the same engine as Chrome.
- wkhtmltopdf — A command-line tool that uses WebKit for rendering. Lighter weight but with older CSS support and known rendering quirks.
- WeasyPrint — A Python library that renders HTML/CSS to PDF without a full browser. Good for simple documents but limited in JavaScript and modern CSS support.
- Gotenberg — A Docker-based API that wraps Chromium and LibreOffice, providing a self-hosted API interface.
Pros of Self-Hosted
- Full control — You own the infrastructure and can customize every aspect of the rendering pipeline.
- Data stays on your servers — Sensitive documents never leave your network. This can be a hard requirement for certain regulated industries.
- No per-render cost — Once the infrastructure is set up, you pay only for the compute resources, not per document.
- No vendor dependency — You are not dependent on a third-party service's uptime or pricing changes.
Cons of Self-Hosted
- Infrastructure management — You need to provision servers, manage container orchestration, handle health checks, and ensure uptime.
- Resource consumption — Chromium is a memory-hungry beast. A single instance can consume 200-500 MB of RAM. Running multiple concurrent renders requires significant resources.
- Scaling complexity — Handling traffic spikes means auto-scaling browser workers, managing job queues, and dealing with cold starts.
- Font and dependency management — You need to install and maintain fonts, keep Chromium updated, and handle dependency conflicts.
- Security surface — Running a full browser engine that processes potentially untrusted HTML creates security risks. Sandboxing and isolation require careful configuration.
- Developer time — Your team spends time maintaining the rendering infrastructure instead of building product features.
The Cloud API Approach
Cloud PDF APIs like TongoRender provide managed rendering infrastructure accessible via HTTP endpoints. You send HTML, you get a PDF. Everything else is handled by the provider.
Pros of Cloud APIs
- Zero infrastructure management — No servers to provision, no containers to orchestrate, no browser instances to manage.
- Instant scaling — Cloud APIs handle traffic spikes automatically. Whether you need 10 or 10,000 renders per minute, the API scales transparently.
- Consistent rendering — The provider ensures that fonts, Chromium versions, and rendering settings are consistent and up-to-date.
- Global availability — Good APIs have edge infrastructure that reduces latency regardless of where your users are.
- Security — The provider handles sandboxing, isolation, and security patching. Each render runs in an isolated environment.
- Fast integration — A single HTTP call replaces hundreds of lines of browser management code.
Cons of Cloud APIs
- Per-render cost — You pay for each document generated. At very high volumes, this can become expensive.
- Data leaves your network — Your HTML content is sent to a third-party server for rendering. For highly sensitive documents, this may not be acceptable.
- Vendor dependency — You rely on the API provider's uptime, pricing stability, and feature roadmap.
- Latency — Network round-trips add latency compared to local rendering, though this is typically negligible (50-200ms).
Cost Analysis at Different Scales
Let us compare the real costs at different volumes, assuming a typical self-hosted setup on AWS:
Small Scale: 1,000 renders/month
| Approach | Monthly Cost | Notes |
|---|---|---|
| Self-hosted (t3.medium) | ~$35/month + DevOps time | Server cost only; excludes engineer time for setup and maintenance |
| Cloud API (TongoRender Starter) | $19/month | Up to 5,000 renders included |
Winner: Cloud API. At this scale, self-hosted infrastructure costs more than a cloud API, and you still need to maintain it.
Medium Scale: 25,000 renders/month
| Approach | Monthly Cost | Notes |
|---|---|---|
| Self-hosted (c5.xlarge + worker scaling) | ~$150/month + DevOps time | Needs auto-scaling, monitoring, queue management |
| Cloud API (TongoRender Growth) | $49/month | Up to 25,000 renders included |
Winner: Cloud API. The cost advantage is clear, and you avoid the operational complexity of scaling browser workers.
Large Scale: 500,000 renders/month
| Approach | Monthly Cost | Notes |
|---|---|---|
| Self-hosted (multi-instance cluster) | ~$500-800/month + dedicated DevOps | Requires container orchestration (ECS/K8s), monitoring, on-call rotation |
| Cloud API (TongoRender Enterprise) | Custom pricing | Volume discounts, dedicated infrastructure |
Winner: Depends. At this scale, the raw compute cost of self-hosted may be lower, but the DevOps time to maintain a reliable rendering cluster is significant. Many teams find that the cloud API is still more cost-effective when you factor in engineer salaries.
When to Use Each Approach
Choose Self-Hosted When:
- Your documents contain highly sensitive data that cannot leave your network (financial records, medical data, classified information).
- You have very specific rendering requirements that require a custom Chromium build or specialized configuration.
- You are generating millions of documents per month and have a dedicated infrastructure team.
- Regulatory compliance mandates that all data processing happens on your own servers.
Choose a Cloud API When:
- You want to add PDF generation without infrastructure overhead.
- Your team is small and does not have dedicated DevOps resources.
- You need reliable scaling without managing browser workers.
- You value fast iteration speed and want to focus on product development.
- You generate fewer than 500,000 documents per month.
Migration Path: Self-Hosted to Cloud
If you are currently running a self-hosted solution and considering a move to a cloud API, here is a practical migration path:
- Audit your current usage — Count your monthly renders, measure average latency, and document any custom configuration you rely on.
- Test with a pilot — Start by routing a small percentage of renders to the cloud API. Compare output quality, latency, and reliability.
- Abstract the rendering layer — Create a rendering service interface in your code that can switch between self-hosted and cloud backends. This makes migration low-risk.
- Gradual rollout — Increase the percentage of cloud-routed renders over time, monitoring cost and quality.
- Decommission — Once you are confident in the cloud API, shut down your self-hosted infrastructure and enjoy the reduced operational burden.
Conclusion
For most teams, a cloud PDF API is the right choice. It is faster to integrate, cheaper to operate at low-to-medium scale, and eliminates the operational burden of managing headless browser infrastructure. Self-hosted solutions make sense for organizations with strict data residency requirements or very high volume use cases with dedicated infrastructure teams.
TongoRender offers the best of both worlds: a fast, reliable cloud API for most use cases, with enterprise plans that include dedicated infrastructure and data processing agreements for regulated industries.
Start with TongoRender free — No infrastructure to set up, no dependencies to install. Just send HTML and get PDFs.