Introduction
This section covers prerequisites, installation, and general deployment guidance for PII Eraser. For platform-specific instructions, see:
- Running with Docker — Local development, testing, and single-host deployments.
- AWS Deployment — Production-grade CloudFormation reference implementation with ECS Fargate and EC2 support.
- Other Platforms — Kubernetes and other container orchestrators.
Architecture
PII Eraser runs as a single container with no external dependencies — no databases, caches, sidecars or GPU drivers. It loads its ML models into memory at startup and serves requests via a REST API on port 8000.
The container is fully stateless. No data is persisted between requests or across container restarts, and no conversation history or processing results are stored. This minimal architecture simplifies deployment, horizontal scaling, and security audits: you deploy a container, point traffic at it, and it scans for PII and other sensitive data, automatically handling different languages, even in the same input.
Prerequisites
Hardware
| Requirement | Minimum | Recommended |
|---|---|---|
| Architecture | x86-64 (AMD64) | x86-64 with AVX-512 VNNI or AMX |
| CPU Cores | 2 vCPUs | 4+ vCPUs |
| RAM | 7 GB dedicated to the container | 16 GB for production workloads |
ARM Support
PII Eraser currently supports x86 CPUs only. ARM support (including AWS Graviton) is on the roadmap and will be evaluated once next-generation ARM server processors such as AWS Graviton 5 are generally available. See Benchmarks & Hardware Selection for details.
CPU Generation Matters
Modern CPUs with AVX-512 VNNI (Intel Ice Lake+, AMD Zen 4+) or AMX (Intel Sapphire Rapids+) deliver 2–5× higher throughput than older processors. Choosing the right instance type is often the single biggest performance lever. See Benchmarks & Hardware Selection and Performance Tuning for guidance.
Software
- A container runtime: Docker Engine, or any OCI-compatible runtime (containerd, Podman).
- For orchestrated deployments: AWS ECS, Kubernetes, or an equivalent container orchestration platform.
Distribution
PII Eraser is available through:
- Private Container Repository — Available for customers with direct licensing agreements.
After obtaining access, we recommend mirroring the container image to your own private container registry (e.g., Amazon ECR, Azure ACR, or a self-hosted registry). This ensures:
- Reliability: No dependency on external registries during deployments or scaling events.
- Performance: Faster image pulls from a registry within your own network.
- Cost: Reduced data transfer charges.
- Compliance: Full control over the software supply chain.
Privacy by Design
PII Eraser is built for environments where data sovereignty is non-negotiable:
- No Telemetry: PII Eraser does not transmit usage statistics, diagnostics, error reports, or any other information back to PII Eraser or any third party. There are no "phone home" mechanisms of any kind.
- No External API Calls: The container makes no outbound network requests during normal operation. The only exception is marketplace metering for billing purposes when deployed via a marketplace subscription.
- Air-Gap Ready: PII Eraser is designed to operate in fully air-gapped environments with no internet access.
CPU-Only Inference
PII Eraser runs entirely on CPUs. While GPUs do accelerate ML workloads, they introduce significant operational and compliance complexity that is often undesirable in regulated environments:
| Consideration | GPU-Based Solutions | PII Eraser (CPU-Only) |
|---|---|---|
| Security Surface | GPU software stack, drivers, and container toolkits (e.g., NVIDIA Container Toolkit) each introduce CVE exposure and patching cycles. | Minimal dependency tree on a hardened Chainguard base image. |
| Compliance Approval | GPU software stacks are large and complex, increasing the scope and duration of security assessments. | Smaller attack surface accelerates vendor risk assessments and security reviews. |
| Infrastructure | Requires GPU-capable instances, which are more expensive, less available, and harder to procure in some regions. | Runs on standard compute instances available in every cloud region, that usually have greater spot instance availability. |
| Operational Overhead | Driver version pinning, CUDA compatibility matrices, and GPU health monitoring. | Standard container operations — no specialized tooling required. |
| Serverless Deployment | Limited and/or preview support on serverless container platforms. Requires dedicated GPU instances with specialized AMIs and drivers. | Natively compatible with serverless platforms (AWS Fargate, Azure Container Instances, Google Cloud Run) — no specialized instance provisioning required. |
Modern x86 CPUs with AVX-512 VNNI and AMX instruction sets deliver excellent throughput that is competitive with GPUs for the type of ML models that PII Eraser uses, particularly when spot instance availability is taken into account. See Benchmarks & Hardware Selection for detailed performance data, for example a 8 vCPU instance type can process over 5000 tokens/s.
Choosing a Deployment Method
| Method | Best For | Guide |
|---|---|---|
| Docker | Local development, testing, and single-host deployments | Running with Docker |
| AWS ECS (CloudFormation) | Production AWS deployments with auto-scaling, load balancing, and VPC isolation | AWS Deployment |
| Kubernetes / Other | Existing K8s clusters, Azure, GCP, or on-premises orchestrators | Other Platforms |