Vortex PDF

Have you ever wrestled with PDF generation libraries, fought with layout shifts, or struggled with font rendering issues? That’s the exact problem Vortex PDF was built to solve—a developer-friendly fix for a traditionally dev-unfriendly problem. Launched in summer 2025, Vortex PDF provides an enterprise-grade API that transforms HTML and web content into pixel-perfect PDFs with unmatched precision and reliability.

Why I built Vortex PDF

Rendering HTML into a PDF is surprisingly hard. Existing open‑source tools often produce unpredictable results – fonts are substituted, margins and layouts shift between pages, images become blurry or pixelated, and large files can crash servers. Many libraries leak memory or support only a subset of the CSS specification, and debugging a broken layout typically involves trial and error. These frustrations motivated me to build Vortex PDF, an enterprise‑grade PDF generation API that behaves more like a browser than a print driver.

Technology stack

I chose Elixir/Phoenix because it delivers high concurrency, fault tolerance and minimal latency. The API sits on top of Phoenix channels and an OTP‑based supervision tree that ensures processes crash gracefully and restart automatically. For rendering, headless Chrome is used instead of bespoke PDF libraries. A pool of Chrome instances runs with the remote debugging protocol enabled; requests are translated into Chrome commands that load the user’s HTML, execute JavaScript, wait for dynamic content, and print to PDF. Communication happens through the protocol channels and results are streamed back to Elixir. This design allows full CSS support and pixel‑perfect rendering while taking advantage of Chrome’s security sandbox.

Solving the pain points

Vortex addresses the issues I encountered with existing tools. By leveraging Chrome and controlling page lifecycle events, the API delivers:

• Pixel‑perfect rendering without surprising shifts.
• Full font support – custom and web fonts are rendered correctly and fallbacks are handled gracefully.
• Precision layouts and high‑DPI output that preserve margins and alignment.
• Optimized performance and memory efficiency, so large documents render quickly without crashing.
• Support for the full CSS spec, including flexbox and CSS grid.
• Developer‑friendly debugging with clear error messages and an interactive preview.

The API also exposes parameters to wait for dynamic elements to load, execute JavaScript in the page context, or control output encoding (binary vs base64), making the service behave predictably even for client‑side applications.

Developer experience

From the start I wanted Vortex to feel like a developer-first service. The homepage emphasises that integration takes minutes and shows a simple cURL request for rendering a “Hello world” PDF. A generous free tier and an interactive playground let developers experiment without entering a credit card. The API supports full HTML and CSS, matches exactly what you see in the browser, and provides rich documentation with examples. For those who don’t want to send raw HTML, the templates feature allows dynamic documents: you create an HTML template with Liquid placeholders and reference it by ID while passing a JSON context. Liquid syntax supports variables, filters, loops and control flow, and this separation of presentation and data improves maintainability and consistency.

Free tier, credit system and pricing

To make the service accessible, Vortex offers a free plan with unlimited development time and no credit card requirement. Paid plans (Launch, Scale and Pro) allocate monthly credit quotas and higher rate limits. API usage is metered: responses under 1 MB consume one credit, 1–5 MB consume two credits, 5–20 MB consume three credits, and larger than 20 MB consume five credits. When a plan’s credits are exhausted, overage is billed at $0.05 per credit for Launch, $0.03 for Scale and $0.02 for Pro. Rate limit headers (x‑rate‑limit‑limit, x‑rate‑limit‑remaining, x‑rate‑limit‑reset) are included in every response so clients can implement backoff strategies.

Synchronous vs asynchronous rendering

Vortex supports two modes. Synchronous processing returns the PDF immediately in the response, suited for small documents or interactive applications. Asynchronous processing queues the rendering job and returns instantly; the PDF is stored in your chosen cloud storage and a callback can notify you upon completion. Use asynchronous mode for large documents, batch processing, background jobs and high‑volume scenarios. The asynchronous queue automatically retries transient failures up to five times and can store results in AWS S3 or Google Cloud Storage with configurable bucket and path settings. Vortex provides default storage on its public bucket if you don’t specify a destination, with files auto‑deleted after 14 days. A callback URL can be supplied to receive a JSON payload upon success or failure.

Under‑the‑hood features

Distributed rate limiter

To enforce the rate limits mentioned above, I built a distributed rate limiter using Erlang’s ETS and gproc libraries. Each API node shares token‑bucket counters through a Phoenix PubSub channel. When a request arrives, the node checks and decrements the bucket; if tokens are exhausted, it returns a 429 response with the appropriate rate‑limit headers. This design allows rate limits to apply globally across a cluster rather than per‑server, ensuring fairness and preventing overload.

Metered billing and credits

The credit system described earlier is enforced by a metered billing engine built in Elixir. Each request pipeline calculates the generated PDF size and deducts the corresponding credits. Usage statistics are persisted in a Postgres database and aggregated for billing. The engine integrates with Stripe for monthly invoicing and supports pay‑as‑you‑go overage charges. An admin panel allows me to adjust credit balances, set plan limits and issue refunds.

Templates, admin panel and analytics

Managing templates requires more than API endpoints. I built a dashboard using Phoenix LiveView where users can create, edit and preview templates. The interface includes a code editor for editing HTML/Liquid and shows a live PDF preview by streaming the rendering results. The dashboard also displays analytics, plotting credits consumed over time, average processing time, error rates and top templates. These metrics help customers optimise their content and detect anomalies.

Feature flags and rollout

Releasing new functionality safely is crucial when a service is used in production. I implemented feature flags backed by PostgreSQL and ETS. Each flag can be toggled per user or globally, enabling canary releases or A/B tests. For example, when adding PDF/A compliance or a new rendering engine, I could roll it out to a subset of customers first and monitor error rates before enabling it for everyone.

Asynchronous queue and retries

The asynchronous API is backed by a distributed job queue. I chose Oban (a PostgreSQL‑backed job system for Elixir) to ensure persistence, retries and ordering. Workers fetch jobs from the queue, interact with Chrome to render PDFs and push results to the appropriate storage. If a job fails due to transient network or rendering errors, Oban retries it with exponential backoff up to the maximum of five attempts. Jobs are sharded across nodes to maximise throughput, and metrics are exported for monitoring.

Security and compliance

Because the service processes potentially sensitive documents, data privacy and compliance were priorities. Vortex runs in isolated cloud containers; incoming traffic is encrypted end‑to‑end and payloads are not stored after processing. The service complies with GDPR and CCPA, and the Pro plans include PDF/A output for long‑term archiving. When customers use asynchronous mode, they must authorise Vortex’s service accounts to write to their buckets, ensuring we never hold long‑term credentials.

Impact and next steps

Building Vortex PDF has been an exercise in combining solid engineering practices with a developer-centric product. The service removes the pain of PDF generation while giving developers powerful tools like templates, JavaScript evaluation, and asynchronous rendering. For now, my goal is to see if this product has legs. If I get some traction, I’ll continue improving it — adding new features, refining the developer experience, and exploring deeper integrations based on what users actually need.