Generating PDF documents from HTML templates is a recurring challenge in business applications: invoices, financial reports, certificates, contracts. Each document can vary drastically in size and volume, from a few kilobytes to hundreds of megabytes, and traffic often arrives in unpredictable bursts. Faced with this, many architectures fall into the temptation of replicating the stack of a large corporation: Redis, Kafka, Kubernetes, multiple coupled services. However, for small teams or startups that need custom applications, there is a more efficient way: an HTML-to-PDF API based on Postgres, Chromium, and nothing else. This minimalist approach, which prioritizes operational simplicity and controlled scalability, has become a de facto standard for those who understand that every extra dependency is a potential point of failure.
The key is to use the same Postgres that already stores the application's data as an asynchronous job queue, thanks to tools such as pg-boss. You don't need Redis or BullMQ; A single database supports both transactional data and rendering task scheduling. This dramatically reduces complexity: a single source of truth, a single system to monitor and back up. For a small team, that means fewer nights on call and more time to focus on the business. When the volume of requests is asymmetrical—for example, 10,000 generation requests in a minute but only the capacity to process 60 PDFs per second—the queue acts as a natural buffer, decoupling the ingestion rate from the processing rate. No peak is lost; jobs are consumed at their own pace.
Memory management is another critical point. A 400 MB document cannot be loaded in RAM without risk. The solution is to use Chromium's streaming mode (ReturnAsStream) in conjunction with a read buffer of, for example, 1 MB. As Chrome renders, Node.js extracts chunks and uploads them directly to S3 storage via multipart upload. This way, the peak memory per document remains constant (~20 MB) regardless of the final size. There is no accumulation; if S3 slows down, the flow backspreads the pressure, preventing collapses. This backpressure streaming pattern is essential to ensure stability in real production, beyond controlled demos.
From a security perspective, sensitive data (names, addresses, amounts) must be protected at rest and in transit. A best practice is to encrypt payloads with AES-256-GCM before storing them temporarily, using keys derived with HKDF from a master secret and a random salt for each document. Thus, even if the database were compromised, there would be no key table to expose. In addition, the generated artifacts must have a short shelf life: previews that are deleted within 24 hours and final documents within a few days. The best mitigation of a breach is if the data no longer exists. In addition, notification webhooks must be signed with HMAC-SHA256 and validated with constant-time comparison to avoid timing attacks.
From a business perspective, the classic dilemma arises: build or buy. If PDF generation isn't the core of your business, but a means of issuing invoices or reports, a managed API that charges cents per document may be the most cost-effective option. You save on Chromium maintenance, security updates, storage management, and ongoing operation. However, when volumes are so high that the cost per document becomes significant, or when legislation prevents data from leaving your infrastructure, or when you need very specific rendering capabilities (custom fonts, complex scripts), then building your own API with Postgres and Chromium becomes the right decision. That's the time to apply this blueprint.
In this context, having a technology partner that understands the subtleties of cloud architecture and cost optimization is key. AWS and Azure cloud services offer the elasticity needed to handle peaks in demand without oversizing, but they require careful design so as not to multiply complexity. Systems such as PostgreSQL manage both the main database and the job queue, while S3 (or equivalent) provide durable storage for the generated PDFs. Integration with AI tools can add value: for example, automatically classify documents, extract data using OCR, or customize templates based on user profiles. Likewise, cybersecurity must be present from the design, protecting each layer of the pipeline.
Practical implementation is often combined with modern frameworks such as SvelteKit or Hono for the API, and pg-boss as a queue embedded in Postgres. A Kubernetes cluster is not needed; a few replicas of workers sharing a pool of connections to Chromium are enough. Monitoring is simplified: a single database, a single log system. For teams developing custom software, this type of architecture allows you to iterate quickly, deploy in small environments, and scale out when the business requires it, without dragging unnecessary technical debt.
In terms of performance, load tests show that a shared VM (e.g., 9 out of 24 threads) can ingest on the order of 5,900 documents per second into the queue, while rendering stabilizes at about 63 PDFs per second, limited by the Chromium pool. That 90-fold lag is intentional: the queue absorbs the burst and workers process at their natural pace. P95 latency under saturation can be around 5 seconds, perfectly acceptable for batch processes. The key is not to couple the acceptance rate with the processing rate, a typical mistake in more coupled designs.
Finally, the decision to build an in-house PDF API should align with the company's overall strategy. If you already have a team that masters Postgres and Node.js, adding Chromium and S3 is not a huge leap. But if the core of the business is different, outsourcing PDF generation to a specialized service frees up resources to innovate in the main product. In any case, understanding the principles of this blueprint—simplicity, streaming, embedded queues, security by design—provides a solid foundation for evaluating any solution, whether it's your own or third-party.
At Q2BSTUDIO, we help companies design and implement this type of architecture, combining process automation with good practices in cloud, artificial intelligence and cybersecurity. From building custom applications to integrating business intelligence services like Power BI, to implementing AI agents that optimize document generation, our approach is pragmatic: fewer dependencies, more control, and a clear roadmap to scalability. Because in the end, the best system is the one you can operate with a small team, maintain with confidence, and scale when the time comes.
