Self-Hosted Philter Reference Architectures

Self-hosted Philter is designed to run entirely inside your own cloud account, so sensitive text is detected and redacted where it already lives and never leaves your boundary. These reference architectures show where to place Philter and its detection models in AWS, Azure, and GCP, including a no-egress variant for environments that allow no outbound internet access and variants for the AWS and Azure government clouds.

They are starting points, not prescriptions. Treat the components as roles to fill rather than exact services, and size each tier to your own throughput and availability needs. Nothing here changes how detection works: it is probabilistic, and you remain responsible for validating redaction output against your own data.

The building blocks

Every architecture below places the same small set of components inside your network:

Philter is the redaction API. It receives text, applies your redaction policies , and returns redacted output. It is the only component callers talk to.
The detection model finds the sensitive information. Run PhEye as a shared model server when several applications need detection, or embed Phileas directly in one application when you want a single self-contained process. The model files are part of the deployment, so detection happens locally.
An internal load balancer fronts Philter (and PhEye, if shared) on a private address. It is never internet-facing.
A referential-integrity store (optional) holds the consistent-pseudonymization mappings so the same input value maps to the same replacement across a cluster. A Valkey-compatible cache fills this role.
Policy and image sources supply the redaction policies and container images. In a locked-down network these come from a private registry and private storage, not the public internet.

Network principles that apply everywhere

The cloud services differ, but the placement rules are the same across all three providers:

Put every component in private subnets. Philter, the model server, and the cache have no public IP addresses.
Expose Philter only through an internal load balancer. Callers inside the same network reach it directly; callers in other accounts or networks reach it over the provider’s private connectivity, not the public internet.
Keep egress closed by default. The workload subnets need no route to the internet. Pull images and read configuration over private endpoints so you can run with outbound access fully disabled.
Restrict traffic between tiers. Security groups or their equivalent allow only caller to load balancer, load balancer to Philter, Philter to the model server, and Philter to the cache.

AWS reference architecture

On AWS, the components sit in private subnets across at least two Availability Zones inside a single VPC. Callers reach Philter through an internal Application Load Balancer or Network Load Balancer; Philter calls PhEye over the same private network and, optionally, a Valkey-compatible ElastiCache for referential integrity.

Compute. Run Philter and PhEye as containers on ECS (Fargate or EC2) or EKS, or directly on EC2 instances. Spread tasks or instances across Availability Zones and place an Auto Scaling group or service behind the load balancer for each.

Access. Callers in the same VPC use the internal load balancer’s DNS name directly. To serve other accounts or VPCs, publish Philter as an AWS PrivateLink endpoint service or connect networks with Transit Gateway, so cross-account traffic stays on the AWS private network.

No egress. Give the workload subnets no internet gateway and no NAT gateway. Pull container images through interface VPC endpoints for the ECR API and Docker registry plus an S3 gateway endpoint for the image layers, and read policies from S3 over that same gateway endpoint or bake them into the image. Reach CloudWatch, KMS, and Secrets Manager through their own interface endpoints if you use them. With the detection models baked into the PhEye image, nothing in this path requires outbound internet access.

Referential integrity. When you need the same value to map to the same replacement across requests or instances, add an ElastiCache (Valkey or Redis OSS) cluster in the private subnets and point Philter at it.

Encryption and access control. Terminate TLS at the load balancer with a certificate from ACM, restrict each tier with security groups, and use IAM roles for the tasks or instances rather than long-lived credentials.

Azure reference architecture

On Azure, the same components run in private subnets of a single Virtual Network, spread across availability zones. Callers reach Philter through an internal load balancer or Application Gateway; Philter calls PhEye privately and, optionally, an Azure Cache for Redis for referential integrity.

Compute. Run Philter and PhEye as containers on AKS or Azure Container Apps, or on virtual machines. Spread the nodes or replicas across availability zones behind the internal load balancer.

Access. Callers in the same VNet use the internal load balancer’s address directly. To serve other networks or subscriptions, publish Philter behind an Azure Private Link Service and let consumers reach it through a Private Endpoint, or connect networks with VNet peering, keeping traffic on the Azure backbone.

No egress. Give the workload subnets no public IP and no outbound internet route; enforce default-deny egress with network security groups or route through Azure Firewall with the internet path closed. Pull images from Azure Container Registry over a Private Endpoint, read policies from Blob Storage over a Private Endpoint or bake them into the image, and reach Key Vault the same way. With the models baked into the PhEye image, nothing needs outbound internet access.

Referential integrity. Add an Azure Cache for Redis instance in the VNet and point Philter at it when you need consistent replacements across requests or instances.

Encryption and access control. Terminate TLS at the load balancer or Application Gateway, restrict each subnet with network security groups, and use managed identities rather than stored credentials.

GCP reference architecture

On Google Cloud, the components run in private subnets of a VPC within a region. Callers reach Philter through an internal load balancer; Philter calls PhEye privately and, optionally, a Memorystore instance for referential integrity.

Compute. Run Philter and PhEye on GKE, on Cloud Run with internal ingress, or on Compute Engine instances, placed in private subnets with no external IP addresses.

Access. Callers in the same VPC use the internal load balancer directly. To serve other VPCs or projects, publish Philter through Private Service Connect or share the network with a Shared VPC, so traffic stays on Google’s private network.

No egress. Leave the workload subnets without a Cloud NAT and without a default internet route, so outbound internet access is closed. Pull images from Artifact Registry and read policies from Cloud Storage over private paths, or bake the policies into the image. With the models inside the PhEye image, the deployment runs with no outbound internet access.

Referential integrity. Add a Memorystore (Redis or Valkey) instance in the VPC and point Philter at it for consistent replacements across a cluster.

Encryption and access control. Terminate TLS at the load balancer, restrict traffic with VPC firewall rules, and run the workloads as least-privilege service accounts.

No-egress and air-gapped variant

For environments that allow no outbound internet access at all, the same architecture runs with egress fully disabled. The key is to pre-stage everything inside the boundary so nothing has to be fetched at runtime.

No-egress variant: applications, Philter, PhEye, and an optional cache run inside a network boundary with no internet route. A private container registry holds the Philter and PhEye images with the models inside, and egress to the public internet is blocked. — The no-egress variant. Images and models are pre-staged in a private registry, and the boundary has no route to the public internet.

Pre-stage the images. Build the Philter and PhEye container images with the detection models inside them, and push them to a private registry that the workload can reach on the private network.
Close the egress path. Give the workload subnets no internet gateway or NAT (AWS), no outbound route or a default-deny firewall (Azure), and no Cloud NAT (GCP). Outbound traffic to the public internet is blocked.
Keep configuration in-boundary. Supply redaction policies from private storage or bake them into the image, so no configuration is fetched from outside.
No phone-home. Philter and PhEye need no license server, activation, or external telemetry, so they operate normally with outbound access disabled.
Update through a controlled path. Bring new images into the private registry through your own inbound staging process rather than from the running workload, so the runtime stays sealed.

Government-cloud variants

The architecture is identical in the US government clouds; what changes is the region, the service endpoints, and the accreditation boundary. Because Philter and PhEye run with no external dependencies, they fit the stricter egress and data-residency rules of these environments.

AWS GovCloud (US). Deploy into the us-gov-west-1 or us-gov-east-1 regions, which sit in a separate AWS partition with their own accounts and IAM. Use the FIPS 140-validated service endpoints. The building blocks used in the AWS architecture above (VPC, internal load balancer, PrivateLink, ECR, ElastiCache, and VPC endpoints) are all available, and the images and models stay inside the GovCloud partition.

Azure Government. Deploy into the Azure Government regions using their dedicated .us endpoints. AKS or Container Apps, internal load balancing, Private Endpoints, Azure Container Registry, and Azure Cache for Redis are available there, and the FedRAMP High and DoD Impact Level boundaries are the reason to use this cloud rather than commercial Azure.

In both, follow the same placement and no-egress practices as the commercial architectures above; the diagrams apply unchanged.

Frequently asked questions

Does Philter need internet access to run?

No. With the container images and detection models present inside your boundary, Philter and PhEye run with no outbound internet access. Image pulls and configuration can come from private registries and storage reached over private network paths, so the workload subnets need no internet gateway or NAT.

Where does the detection model run?

Inside your boundary. You either run PhEye as a model server in your own network or embed Phileas in your application. Either way there is no third-party PII API and no text sent to another provider.

Can I share one Philter deployment across multiple accounts or VPCs?

Yes. Front Philter with an internal load balancer and expose it to other accounts or networks over the cloud's private connectivity (AWS PrivateLink or Transit Gateway, Azure Private Link, GCP Private Service Connect) so traffic stays on the provider's private network rather than the public internet.

Do these architectures work in government clouds?

Yes. The same topology runs in AWS GovCloud and Azure Government; the government-cloud variant below covers the region, endpoint, and compliance-boundary differences. The components and data-flow are unchanged.