Here's something that bothered me for years working inside enterprise environments: the moment you need to generate a PDF, someone has to explain to Legal why your customer's invoice data is travelling to a third-party server in a region you've never heard of.
The vendor's answer is always "we're SOC 2 compliant." Which is fine. But SOC 2 doesn't mean your data didn't leave your building. It just means someone organised around that fact.
We built VaultPDF because we thought there was a better answer, one where the question never comes up in the first place.
The Problem We Kept Running Into
Before this, I spent years implementing document generation for mid-to-large enterprises: construction companies, financial services firms, and legal practices. The same cycle repeated almost everywhere.
A business user needs a new document type. Say, a site inspection report with photos, QC notes, and a signature block. They go to IT. IT evaluates options. Then one of three things happens.
Option A: SSRS or Crystal Reports. A developer spends two weeks building a report. The template is rigid. Any nested data, say, inspection items grouped by location with sub-items under each, requires subreports that are fragile and slow. Six months later the business wants a small change: add a computed total, update the logo. Back to the developer queue. The template lives inside SQL Server Reporting Services or a legacy app server, and nobody knows which version of the template produced which document anymore.
Option B: Word mail merge. Someone builds a .docx template with merge fields. It works for simple letters. The moment the data has variable-length line items, or you need totals that aren't pre-calculated in the source system, it falls apart. Word doesn't compute. Word merges. If the payload has 40 line items one day and 2 the next, the table formatting breaks. If a field is null, the layout corrupts. Someone ends up manually fixing PDFs before they go out.
Option C: A SaaS PDF API. There are plenty, and they come in two flavours.
The first accepts a JSON payload and returns a rendered PDF. Fast to integrate, decent templates. But your invoice payload, which contains your customer's name, order details, and pricing, now travels to a third-party server. For a construction company generating safety reports with site photos, that data lives on someone else's infrastructure, even briefly. Legal and compliance teams are not enthusiastic.
The second accepts an HTML document and uses a headless browser to render it to PDF. This approach feels appealing at first because you can style documents with CSS and the integration looks familiar. The problem is non-determinism. Run the same HTML through the same tool twice and you may get subtly different output: slightly different line breaks, misaligned table columns, or fonts that render at minutely different point sizes depending on which version of the headless browser is running. In a document that carries a digital fingerprint for compliance, or one that two people are comparing side-by-side to resolve a dispute, "almost identical" is not good enough. You cannot confidently say two documents are the same without generating them again and hoping.
The result in every case: fragile documents, high maintenance costs, and a compliance conversation that never quite goes away.
What We Actually Wanted
We wanted something specific:
- The rendering engine runs inside the customer's subscription. Not ours. Theirs. A VaultPDF Edge Engine they deploy to their own Azure region. A storage account they own. The data never leaves.
- Templates that a business analyst can edit. Not a developer. Someone who understands the document but doesn't want to write SSRS expressions or fiddle with Word field codes.
- Real support for nested data. Not a workaround. Not subreports. A table that can render orders, line items, and serial numbers with subtotals at each level, styled consistently, and without page break issues.
- Version control that works. Templates as
.vpdffiles, portable JSON that you can commit to Git, export from the Designer, import anywhere, and know exactly which version produced which document.
That's it. That was the whole brief.
The no-egress Decision
The no-egress architecture wasn't a marketing decision. It came from a specific conversation with a client in the construction sector who asked, before signing anything: "Can you guarantee that our site photos never touch a server we don't control?"
The honest answer with any SaaS PDF API is no. You can say the data is encrypted in transit. You can say it's deleted after processing. But you can't say it never arrived somewhere else.
With VaultPDF, the entire processing chain, The Dispatcher, The REFRACT Engine, the template files, the generated PDFs, and the audit logs, all live inside the customer's Azure subscription. We never see the data. We can't. We're not in the loop.
A .vpdf template file looks like this:
{
"templateId": "site-inspection-report-v3",
"templateSettings": {
"locale": "en-GB",
"dateFormat": "DD MMM YYYY",
"timezone": "Europe/London"
},
"theme": {
"primaryColor": "#0D3B66",
"accentColor": "#0077B6",
"fontFamily": "Roboto"
},
"layoutSchema": { "...": "component tree defining what appears in the document" },
"hierarchyRules": { "...": "per-level styling and computed fields for nested tables" }
}
It's a JSON file. Commit it to Git. Diff it. Roll it back. The rendering topology that processes it sits entirely inside your subscription:
Customer's Microsoft 365 Tenant
│
├── VaultPDF Compute Node ←── The REFRACT Engine (deployed to customer subscription)
├── SharePoint ←── Templates, payloads, generated documents
└── Azure Blob Storage ←── Archive, audit logs
The source system drops a payload into SharePoint. The Dispatcher picks it up, fetches the template, passes it to The REFRACT Engine, and writes the PDF back to SharePoint. All of it runs in the customer's subscription. The only thing that crosses the boundary is the initial deploy, and that's just a configuration package.
Why This Matters More in 2026
A few years ago, the conversation about data residency was mostly limited to regulated industries: financial services, healthcare, and government. That's changed.
Construction firms are generating safety audit documents with geo-tagged photos that are legally sensitive. Legal practices are producing contract packs with clauses that can't touch external servers without explicit client consent. Mid-market manufacturing companies are under pressure from their enterprise customers to demonstrate supply chain data governance.
The regulatory pressure is real. GDPR enforcement has become more aggressive, not less. Sector-specific frameworks in the UK and EU are tightening. And the reputational risk of a data incident involving customer documents, even a brief transit through a third party, has become something boards actually talk about.
The "just use a SaaS API, it's fine" answer gets harder to defend every year.
What We Decided to Build
We didn't try to out-feature every PDF library on the market. We focused on the specific problems that kept causing pain in enterprise environments.
Layout that holds under real data. The REFRACT Engine is deterministic. Whether a table has 2 rows or 2,000, whether a field is null or overflows to multiple lines, the output is byte-for-byte consistent across every run. We spent a disproportionate amount of time on page break logic, because "the table split awkwardly across pages" is genuinely the most common complaint about auto-generated documents in enterprise environments.
Nested data as a first-class problem. The Hierarchical Table renderer handles five or more levels of nesting with per-level styling, conditional field visibility, computed subtotals at each level, and group headers. It's the part of the product we're most proud of technically, and it's the part most PDF tools handle worst.
Templates that don't require a developer to change. The Designer lets a business analyst adjust column widths, change fonts, add a logo, and reorder sections, then export a new .vpdf file that goes straight back into SharePoint. No code deployment. No developer queue.
Audit trails that satisfy compliance review. Every render writes a structured event to the tenant's audit log: template ID and version, timestamp, payload hash, who triggered it, and where the output was stored. Not because we needed to build it, but because the first enterprise customer asked where they could prove what was generated and when.
Read the follow-up post for a technical look at what The REFRACT Engine actually produces, from the .vpdf format and Hierarchical Tables to Signature Zones, Supplementary Annexes, and audit-grade output.
If you're evaluating document generation options and the data residency question is on your list, we're happy to walk through the architecture. Reach us at [email protected].