H33's Self-Hosted Commercial Model

Why Self-Hosted Matters for Regulated Industries

Every week, a security officer at a bank, hospital, or defense contractor asks us the same question: "Can we run H33 without sending data outside our network?" The answer has always been yes. H33 was built from the ground up to run self-hosted -- Docker containers, bare-metal Rust binaries, zero external dependencies. No phone-home telemetry. No cloud-only features gated behind a SaaS paywall. The same cryptographic engines that power our hosted API ship directly to your datacenter.

This is not a concession to enterprise sales cycles. It is the architecture. Regulated industries handle data that cannot leave their boundary under any legal interpretation -- biometric templates governed by BIPA, patient records under HIPAA, classified material behind ITAR controls, financial transactions auditable only within sovereign infrastructure. For these organizations, a SaaS-only cryptography vendor is not a vendor at all. It is a liability.

H33 exists to close the gap between post-quantum cryptographic capability and the deployment constraints of the real world. This post explains exactly how our self-hosted model works, what ships in the container, and why binary distribution of proprietary cryptographic engines is fundamentally different from downloading an open-source FHE library off GitHub.

The SaaS Problem

SaaS transformed how companies buy software, but it introduced a structural conflict for anyone handling sensitive data. When you call a third-party API, you are externalizing trust. Your plaintext biometric template, your patient's diagnosis, your client's legal strategy -- all of it transits a network you do not control, processes on hardware you cannot audit, and persists in memory you cannot wipe.

Three specific problems recur across every regulated enterprise we talk to:

Data sovereignty. Regulations like GDPR (Article 44), CCPA, and BIPA do not merely require encryption in transit. They require data residency. If a European patient's biometric template touches a U.S. server during an FHE computation, the data controller has a GDPR exposure -- even if the computation was encrypted. Self-hosted eliminates this category entirely. The data never moves.

Compliance boundaries. SOC 2 Type II audits, HIPAA Business Associate Agreements, and FedRAMP authorization all require documenting every system that touches protected data. Every SaaS API you call is another system in scope. Every additional system in scope is another vendor risk assessment, another penetration test, another auditor fee. Self-hosted collapses the boundary: H33 runs inside your existing perimeter, under your existing controls, inside your existing audit scope.

Vendor lock-in and continuity. What happens when your SaaS cryptography provider goes down? Gets acquired? Changes pricing? Sunsets an API? When the cryptographic engine runs on your metal, business continuity is in your hands. The binary does not phone home. It does not require an active license server. It runs.

H33's Approach: Binary Distribution, Zero Dependencies

H33 ships as compiled Rust binaries. Not source code, not Python wrappers, not JavaScript glue around a C++ library. Compiled, statically-linked Rust binaries that run on ARM (Graviton4, Apple Silicon) and x86-64 without a single runtime dependency on external FHE or ZK libraries.

Two deployment modes are supported:

Docker containers. Pull the image, configure your environment variables, run. The container includes all five cryptographic engines, the H33-74 substrate attestation layer, and a REST API surface that mirrors our hosted service exactly. Your application code does not change between SaaS and self-hosted -- the same endpoints, the same request format, the same response schema.

Bare-metal binaries. For environments where Docker is not permitted -- air-gapped networks, classified enclaves, embedded systems -- we ship standalone executables. Unpack, configure, execute. No container runtime, no orchestration layer, no package manager. The binary is the product.

In both modes, there are zero external calls. No license server ping. No telemetry beacon. No dependency on any third-party cryptographic library. All five engines are H33 proprietary code, written in Rust, compiled to native instructions for your target architecture. The binaries work fully offline from the moment they start.

What Ships in the Container: Five Proprietary Engines

Every H33 deployment -- SaaS or self-hosted -- includes the same five cryptographic engines. There is no "lite" self-hosted tier. You get the full stack:

1. BFV FHE Engine (H33-128 / H33-256). Integer-arithmetic fully homomorphic encryption. Batch 32 biometric authentications per ciphertext. Montgomery-form NTT with radix-4 butterflies. This is the engine that produces the 2,293,766 auth/sec benchmark on Graviton4.

2. CKKS FHE Engine (H33-CKKS). Approximate-arithmetic FHE for floating-point workloads -- machine learning inference on encrypted data, encrypted financial modeling, encrypted risk scoring. Same NTT core, different plaintext encoding.

3. TFHE Engine (H33-TFHE). Gate-by-gate FHE for boolean circuits. Purpose-built for bit-level operations: encrypted comparisons, encrypted lookups, encrypted conditionals. The sealed-tier TFHE enables SHA3-256 computation on encrypted bits without ever decrypting.

4. STARK ZKP Engine. Zero-knowledge proof generation and verification for lookup arguments, biometric matching proofs, and the H33-74 substrate attestation pipeline. AIR-based constraint system with DEEP-FRI commitment. Cached proofs verify in 71 microseconds.

5. Three-Key PQ Signer. Post-quantum digital signatures using three independent mathematical hardness assumptions: ML-DSA (lattice), FALCON (NTRU lattice), and SLH-DSA (stateless hash). A signature breaks only if all three families are simultaneously broken -- three independent mathematical bets against quantum adversaries.

All five engines ship in every container. All five are proprietary. All five have zero external dependencies.

Performance Parity: Self-Hosted Gets the Same Throughput

A common concern with self-hosted deployments is performance degradation. Vendors optimize for their own cloud, and the self-hosted binary is an afterthought. H33 works differently. The same binary that runs in our cloud runs on your metal. There is no cloud-only optimization path.

Our production benchmark on Graviton4 (192 vCPUs, ARM64):

These numbers are from the exact same binary a self-hosted customer receives. There is no "cloud edition" with additional optimizations. When you deploy on equivalent hardware -- Graviton4, or comparable x86-64 with sufficient core count -- you achieve the same throughput. The binary is the product; the product is the binary.

For customers running on different hardware, we provide architecture-specific builds. ARM64 builds use NEON SIMD intrinsics. x86-64 builds use AVX2/AVX-512 where available. The compiler targets are tuned per platform, not compiled to a lowest-common-denominator generic target.

Compliance Simplified

Self-hosted deployment does not merely satisfy compliance requirements -- it eliminates entire categories of compliance work. Here is how the self-hosted model simplifies each major framework:

HIPAA. No Business Associate Agreement required with H33. The cryptographic engine runs on your infrastructure, processes your ePHI, and never transmits data externally. H33 is a software vendor, not a business associate. Your covered entity boundary remains unchanged.

GDPR. No data transfer impact assessment. No Standard Contractual Clauses. No Schrems II analysis. Patient and user data stays in your jurisdiction, on your hardware, under your Data Protection Officer's control. Article 44 cross-border transfer obligations do not apply when data does not cross a border.

BIPA (Illinois Biometric Information Privacy Act). BIPA requires informed consent before collecting, storing, or transmitting biometric identifiers. When biometric templates are encrypted and processed entirely within your boundary using H33's FHE engine, the template never leaves your custody. The consent and data handling obligations remain straightforward because no third party ever possesses the biometric data.

CCPA / CPRA. No "sale" of personal information to a service provider. No third-party data sharing. The California Privacy Rights Act's service provider provisions are simpler when the cryptographic computation happens on premises.

SOC 2 Type II. Fewer systems in scope. No vendor risk assessment for H33's cloud infrastructure. No third-party penetration test of H33 servers. The audit boundary shrinks to your own infrastructure, which you already control and monitor.

IP Protection: Why Binary Distribution Matters

H33 is not open source. The cryptographic engines are proprietary, protected by 6 patents pending with 250+ claims covering the FHE parameter selection, batched attestation pipeline, and substrate compression.

Self-hosted customers receive compiled binaries. Not source code. Not obfuscated source code. Compiled native machine code. This is a deliberate architectural decision, not a limitation:

Patent protection with practical enforcement. Open-source FHE libraries publish their algorithms for anyone to read, fork, and reimplement. Patent claims against open-source code are notoriously difficult to enforce. Binary distribution keeps the implementation proprietary while delivering full functionality to the customer.

No dependency supply chain. Open-source FHE libraries depend on other open-source libraries, which depend on still others. Each dependency is an attack surface and a license obligation. H33's binaries have zero external cryptographic dependencies. The supply chain is H33.

Consistent security posture. When source code is available, customers inevitably modify it -- patching parameters, changing key sizes, disabling safety checks. Modified FHE parameters can silently destroy security guarantees. Binary distribution ensures every deployment runs the exact code H33 tested, benchmarked, and validated.

Our development infrastructure reflects this model. Public GitHub (github.com/H33ai-postquantum) hosts SDKs, CLIs, documentation, and integration examples. The cryptographic engine source lives on private GitLab, never mirrored externally. GitHub is the surface; GitLab is the moat.

The Digital SCIF Vision

Self-hosted H33 is not just a cryptographic library you bolt onto an existing application. It is the foundation for what we call the Digital SCIF -- a post-quantum cryptographic operating system that manages identity, documents, medical records, messaging, estate planning, key management, compliance, and fraud detection under a unified cryptographic boundary.

The Digital SCIF runs entirely on customer premises. Every operation -- identity verification via FHE-encrypted biometrics, document attestation via the three-key PQ signer, medical record access via encrypted search, secure messaging via hybrid PQ key exchange -- happens within the customer's infrastructure boundary.

The H33-74 substrate ties it together. Every computation produces a 74-byte attestation: 32 bytes on-chain, 42 bytes in the local cache layer. Three post-quantum signature families attest every operation. The substrate works identically in self-hosted mode -- same 74 bytes, same three-family attestation, same verification pipeline. No cloud dependency.

For defense contractors, this means a SCIF-grade cryptographic stack that runs inside their existing classified network. For hospitals, it means a HIPAA-compliant identity and records system where patient biometrics never leave the hospital's servers. For law firms, it means client privilege protected by post-quantum cryptography that runs on the firm's own infrastructure, auditable only by the firm.

The vision is not incremental. It is a complete re-architecture of how organizations protect their most sensitive operations. Instead of layering encryption on top of systems that were never designed for it, the Digital SCIF starts with the cryptographic boundary and builds upward. Every byte that enters the system is encrypted, attested, and verifiable from the moment of creation. Every operation produces a post-quantum proof that the computation happened correctly and was not tampered with. The entire stack runs on your hardware, under your control, within your legal jurisdiction.

Getting Started

H33 offers two licensing models:

API-based (SaaS). Call H33's hosted endpoints. Pay per operation. No infrastructure to manage. Ideal for teams that want post-quantum cryptography without running their own servers. See our pricing page for current plans.

Self-hosted license. Receive compiled binaries (Docker or bare-metal). Deploy on your infrastructure. Full performance parity. Enterprise terms, volume pricing, and dedicated support. Contact us to discuss your deployment.

To evaluate the self-hosted model for your organization:

1. Schedule a demo. We walk through the deployment process, benchmark on representative hardware, and map H33's engines to your specific use case. Schedule a demo here.
2. Architecture review. Our team reviews your infrastructure (ARM vs. x86, container vs. bare-metal, air-gapped vs. connected) and recommends the optimal deployment configuration.
3. Pilot deployment. Run H33 in a staging environment against your own workloads. Validate throughput, latency, and compliance posture before production.
4. Production rollout. Go live with ongoing support from H33's engineering team.

For questions, reach us at support@h33.ai.

Frequently Asked Questions