The Problem: PDF Generation in 2026
The current landscape for PDF generation in 2026 often relies on a patchwork of tools: Puppeteer for browser automation, LiquidJS for templating, and S3 for storage. While functional, this approach leaves critical production challenges unaddressed. Documents can vary wildly in size, from a few kilobytes to hundreds of megabytes, demanding robust memory management. Traffic patterns are frequently bursty, with thousands of documents needing rendering simultaneously, pushing CPU resources to their limits. Furthermore, these documents often contain sensitive personal and financial information, necessitating strict security considerations. For a solo developer, the complexity of managing such a system is a significant hurdle.
Adrianani.com’s DocPenny project tackles these constraints head-on. Developed over twelve weeks by a single operator, the blueprint prioritizes a minimal, efficient stack designed for scalability and manageability.
The Minimalist Stack
The core of the DocPenny blueprint eschews common microservices orchestration and messaging patterns in favor of extreme simplicity. The chosen stack includes SvelteKit for the frontend framework, Hono for a lightweight web server, pg-boss for job queuing, PostgreSQL as the database, Chromium for rendering, and S3-compatible storage. Notably absent are technologies like Redis, Kafka, and Kubernetes, which often introduce significant operational overhead. Even a dedicated connection pooler was deemed unnecessary and subsequently removed after an initial trial.
The strategic choice of pg-boss is central to this minimalist approach. By leveraging PostgreSQL for asynchronous job management, the system consolidates application data and background processing into a single, familiar database. This eliminates the need for a separate job queueing service, simplifying deployment, monitoring, and maintenance. It’s akin to using a single, highly organized filing cabinet for both your active projects and your archived documents, rather than maintaining separate systems for each. This consolidation is key to the solo operator’s ability to manage the entire system effectively.
Core Components and Their Roles
PostgreSQL as the Unified Backend: PostgreSQL serves a dual purpose: storing application data and managing the job queue via pg-boss. This eliminates the need for a separate message broker. When a document generation request comes in, it's added as a job to PostgreSQL. Workers then pick up these jobs, process them, and store the resulting PDF in S3-compatible storage. The database handles concurrency and ensures job reliability.
Chromium for Rendering: For accurate HTML-to-PDF conversion, headless Chromium is the engine. It provides a full browser environment, ensuring that complex CSS, JavaScript, and modern web standards are rendered correctly. This is crucial for generating PDFs that precisely match the visual fidelity of a web page, a common requirement for invoices, reports, and certificates.
SvelteKit and Hono for the API Layer: SvelteKit handles the user-facing aspects and potentially the API definitions, while Hono provides a highly performant, minimal HTTP framework. This combination allows for rapid development and efficient request handling. The API exposes endpoints for submitting document generation requests and retrieving the status or the final PDF.
S3-Compatible Storage: PDFs are stored in S3-compatible object storage. This choice offers scalability, durability, and cost-effectiveness for storing potentially large files. The API can then serve these files directly or provide signed URLs for client access.
Handling Production Constraints
The blueprint directly addresses the four primary constraints identified:
- Document Size: By using a job queue, the system decouples the request from the rendering process. Long-running rendering tasks for large documents don't tie up API workers. The result is stored, and clients can poll for completion or receive a notification. Memory management is handled within the isolated Chromium rendering process, and the overall system architecture avoids accumulating large datasets in memory.
- Bursty Traffic: The job queue is the key here. When traffic spikes, new jobs are simply added to the PostgreSQL queue. Worker processes, which can be scaled independently, pick up jobs as they become available. This prevents the API from being overwhelmed by sudden surges in requests. The CPU-bound nature of rendering is managed by the number of worker instances processing the queue.
- Sensitive Data: Data is handled with care. Requests are processed in isolated environments. PDFs are stored securely in S3, and access can be controlled via signed URLs or other authentication mechanisms. The minimal stack reduces the attack surface, and PostgreSQL's robust security features are leveraged.
- Solo Operator Manageability: The radical simplification of the stack is the primary enabler. With fewer moving parts, there are fewer components to monitor, update, and troubleshoot. PostgreSQL is a well-understood and managed database for most developers. Headless Chromium is a standard tool. SvelteKit and Hono are modern, efficient frameworks. This focused approach makes the entire system maintainable by a single individual without requiring deep expertise in complex distributed systems.
The Unanswered Question: Scaling Workers
While the blueprint elegantly handles job queuing and storage, the practicalities of scaling the Chromium worker processes remain a point of careful consideration for any solo operator. How many worker instances are truly optimal for a given burst load? What is the cost-performance curve for adding more workers beyond a certain threshold? Without a complex orchestration layer like Kubernetes, managing and auto-scaling these workers efficiently requires a deep understanding of the specific workload and careful monitoring, potentially involving simple scripts or managed worker services that abstract away some of the complexity.
Beyond the Blueprint
This approach demonstrates that building a robust, scalable HTML-to-PDF service does not require a sprawling microservices architecture. By carefully selecting core technologies and understanding their capabilities, a developer can create a performant and manageable solution. The blueprint offers a compelling alternative for startups, small teams, or individual developers who need reliable PDF generation without the operational burden of heavier, more complex systems.