Why Zunavi Is On-Premise First: Semiconductor Drawings Don't Leave the Building

The Assumption Baked Into Most Drawing-Management Tools

Almost every modern SaaS product for engineering document management is built cloud-first: sign up, your files go to their infrastructure, and “on-premise” — if it exists at all — is an enterprise add-on bolted on after the fact, usually expensive and usually a second-class experience. For a lot of software categories that’s a completely reasonable default.

It’s the wrong default for the audience Zunavi is built for. Semiconductor and precision manufacturers work with drawings that are confidential by definition — 半導体は機密 (semiconductor is confidential) isn’t a compliance checkbox for this industry, it’s the starting assumption. A tool that quietly requires drawings to transit through a third party’s servers before an engineer can view them is disqualifying for a meaningful share of this market, no matter how good the feature set is.

Making On-Premise a First-Class Deployment Mode, Not a Fallback

The way this shows up in Zunavi’s architecture is a field on the tenant record itself: Tenant.deployment, which is either ONPREM or CLOUD. This isn’t a support-ticket-driven exception path — it’s a first-class value the rest of the system is designed around. On-premise tenants get cloud-dependent capabilities turned off by default, not because they’re being restricted, but because the default posture for a confidential-by-nature workload should be “data doesn’t leave the building” unless someone explicitly says otherwise.

That “explicitly says otherwise” part matters. Any feature that would mean sending drawing data to an external service sits behind its own consent flag, separate from the general feature-flag system we’ve written about separately. Turning on a cloud-dependent capability is a decision a tenant administrator has to make on purpose — it doesn’t happen implicitly because a feature got enabled for some other reason.

Storage: Local Filesystem by Default, S3-Compatible When You Ask For It

File storage follows the same logic. Zunavi’s storage layer is driven by a STORAGE_DRIVER setting: local filesystem by default, S3-compatible object storage as an explicit option. For an on-premise install, drawings, DXF/DWG/STEP files, and generated thumbnails sit on infrastructure the manufacturer already controls — no bucket in a region they didn’t choose, no third-party storage provider added to their vendor risk assessment by default. Cloud object storage is there for teams that want it — a lighter-weight setup, a demo environment, a smaller shop without server infrastructure to manage — but it’s opt-in, not the architecture’s baseline assumption.

“Confidential” Isn’t a Vague Adjective in This Industry

半導体は機密 isn’t marketing language borrowed to justify an architecture choice — it describes a real regulatory reality semiconductor engineers operate under. Under U.S. export control rules, a “deemed export” occurs when controlled technical data — which explicitly includes semiconductor design information and manufacturing know-how — is shared with a foreign national, even inside the exporting company’s own building; that’s treated the same as physically shipping controlled goods overseas, and companies are expected to run access controls and screening procedures accordingly (Kharon, on AI and semiconductor export controls compliance). Lawmakers have gone as far as proposing to restrict remote cloud access to export-controlled chip designs entirely, treating cloud transit itself as a control point (Kharon). Security checklists written specifically for evaluating cloud PDM tools in regulated sectors now tell buyers to verify audit logs, permissions, external sharing behavior, and — critically — to get explicit clarity on what a vendor secures by default versus what the customer has to configure themselves (CAD Rooms, cloud PDM security review checklist). Against that backdrop, “cloud by default, on-premise if you ask nicely” isn’t just a UX preference mismatch — it’s an architecture that puts the compliance burden on exactly the customers who can least afford to get it wrong.

Even the Job Queue Respects the Constraint

This is the detail that’s easy to miss but says the most about how seriously “on-premise first” is being taken: Zunavi’s background job processing — OCR extraction, thumbnail generation, CAD file conversion, similarity-search embeddings — defaults to a PostgreSQL-based queue, using FOR UPDATE SKIP LOCKED for safe concurrent job pickup, rather than requiring Redis out of the box. Redis is available as an option for teams running under heavier load, but it’s not a hard dependency for a minimal on-premise install.

That might sound like a small implementation detail, but it changes what “installing Zunavi on our own servers” actually requires. Every additional required service is another piece of infrastructure an on-premise customer’s IT team has to provision, patch, and justify to security review. A drawing management platform that needs PostgreSQL and nothing else to run its core workflow is a fundamentally easier “yes” for a manufacturer whose security posture treats every new service as something to be interrogated.

Why Cloud-First SaaS Is a Structural Mismatch Here

None of this is a knock on cloud-first architecture in general — for a huge range of software, it’s the right call, and Zunavi supports CLOUD deployment as a real, supported mode for teams that want it. The mismatch is specific: a tool that treats “your files live on our servers” as a fixed assumption, with on-premise as a bolted-on enterprise tier, is optimizing for a deployment model that a meaningful part of the semiconductor and precision manufacturing world can’t default to. Building on-premise as the default deployment mode — not a downgrade path, not a special SKU — means the architecture has to actually support it cleanly from the start: local storage that isn’t a compatibility shim, a job queue that doesn’t assume a managed Redis instance is one click away, and cloud features that stay behind consent, not convenience.

Where the Established PDM Vendors Land on This

We’re not the first to notice this split. Autodesk’s own product line illustrates it: Vault remains the on-premises product for “teams committed to on-premises deployment — due to data residency requirements, air-gapped network environments, or IT governance” — while Autodesk’s newer cloud PLM offering, Fusion Manage, has no on-premises version at all (DemystifyingPLM, on Autodesk’s cloud-first shift; KETIV, on Vault deployment options). That’s the industry pattern in miniature: on-premise support tends to live in the older, less actively developed product line, while new investment goes to cloud-only tools — which is exactly the gap a semiconductor manufacturer that needs both modern tooling and data residency falls into. It’s also a gap that matters more in Japan specifically than the digitization narrative usually suggests: Japan’s 2025 METI White Paper on SMEs found 64.8% of small and medium manufacturers still sit at the lowest two stages of digital maturity, with only 3.2% at the most advanced stage — and separate industry commentary notes that high-mix, low-volume manufacturing environments, where every job has different drawings and specs, are specifically where that bar rises and digitization efforts stall (METI, 2025 White Paper on SMEs; The Worldfolio, on drawing-centered DX for Japanese manufacturing SMEs). A platform aimed at this market that also demands a cloud migration as a precondition is asking a shop to solve two hard problems — going digital, and going to the cloud — at once, when the whole point is to make the first one tractable on its own.

The Japanese-Specific Detail Generic Tools Miss

There’s a second, quieter market-fit problem generic Western engineering tools tend to have with this audience: encoding and localization. A lot of drawing data in Japanese manufacturing environments — legacy CAD exports, older DXF files, titleblock text — is Shift-JIS encoded rather than UTF-8, and a viewer that assumes UTF-8 either mangles the text or refuses to render it. Zunavi’s CAD viewer builds on a forked, Japanese-patched viewer with Shift-JIS decoding support and IPAexGothic font rendering baked in, so drawings with Japanese titleblocks and annotations display correctly instead of showing garbled characters — a detail that sounds minor until it’s the reason a tool doesn’t actually work for the drawings a shop has been producing for twenty years.

Where This Stands Today

Zunavi is still in active development, and none of this is a claim that the platform is deployed anywhere today — it isn’t, and we’re not putting a release date on it. What we can say concretely is what the architecture commits to: on-premise as the default deployment posture, not an enterprise afterthought, for an industry where that default is the whole point.

---

Related: why Zunavi’s certain/optional feature flags matter for trustworthy engineering data, why we’re rebuilding the drawing ledger from scratch, and the original introduction to Zunavi. If on-premise deployment for confidential engineering data is a requirement you’re navigating, we’d like to compare notes — [email protected].