Skip to main content
VisualSign can be deployed in several ways, each with different trade-offs around security guarantees, infrastructure requirements, and integration complexity. This guide helps you choose the right approach.

Decision tree

Comparison

Deployment models

Turnkey Hosted

Turnkey operates the VisualSign parser in AWS Nitro Enclaves. You send transactions to their API and verify the attestation documents they return. You handle:
  • Calling the Turnkey API
  • Verifying attestation documents
  • Displaying parsed output to users
Turnkey handles:
  • Enclave infrastructure
  • Scaling and availability
  • Enclave updates and PCR management
Get started with Turnkey Hosted →

Self-Hosted TEE

Run your own VisualSign parser as a Turnkey Verifiable Cloud (TVC) app. You own the app and the operator keys that approve its deployments, and you choose the parser image and configuration. Turnkey runs the AWS Nitro Enclave and QuorumOS runtime underneath it. Every response carries an attestation that any client can verify end to end. You handle:
  • Choosing, pinning and deploying the parser image
  • Approving deployments with your operator keys
  • PCR and manifest allowlist management
  • Verifying your deployment
Turnkey handles:
  • Enclave infrastructure and the QuorumOS runtime
Best for:
  • Organizations with strict compliance requirements
  • Control over the parser version and its configuration
  • Custom attestation verification workflows
Get started with Self-Hosted TEE →

Library Integration

Embed the VisualSign parser directly in your application. Available as Rust crates that can be compiled into your application. Trade-offs:
  • No attestation (you trust your own process)
  • No network latency
  • Smallest deployment footprint
Get started with Library Integration →

gRPC Server

Run the gRPC parser service without TEE infrastructure. The same gRPC API as the TEE deployments, but without enclave isolation or attestation. Use cases:
  • Development and testing
  • Internal services on trusted networks
  • Environments where TEE isn’t available
Trade-offs:
  • No attestation verification
  • Relies on network security
  • Same API as TEE deployments (easy migration path)
Get started with gRPC Server →

Security considerations

When you need attestation

Attestation provides cryptographic proof that:
  1. The parser code hasn’t been tampered with
  2. The parsing happened inside a secure enclave
  3. The output hasn’t been modified
You should use a TEE deployment (Hosted or Self-Hosted) when:
  • Users are signing high-value transactions
  • Regulatory requirements mandate tamper-evident processing
  • You need to prove parsing integrity to auditors or users

When attestation isn’t required

Library or gRPC Server deployments are appropriate when:
  • Parsing happens on the user’s own device (browser extension, mobile app)
  • The service runs on internal infrastructure you fully control
  • You’re building development or testing environments
  • The threat model doesn’t include compromised parsing infrastructure

Next steps

Choose your deployment model and follow the getting started guide: Regardless of deployment model, you’ll want to understand: