Encryption
Security and privacy are core design objectives at Neural Inverse. The Neural Inverse Team runs Neural Inverse in production on Neural Inverse Cloud which is ISO27001, SOC2 Type 2, HIPAA, and GDPR compliant (Neural Inverse Cloud security page, Form to request reports).
This guide covers the different encryption methods and considerations. It is assumed that you are familiar with the architecture of Neural Inverse.
Encryption in transit (HTTPS)
For encryption in transit, HTTPS is strongly recommended. Neural Inverse itself does not handle HTTPS directly. Instead, HTTPS is typically managed at the infrastructure level. There are two main approaches to handle HTTPS for Neural Inverse:
- Load Balancer Termination: In this approach, HTTPS is terminated at the load balancer level. The load balancer handles the SSL/TLS certificates and encryption, then forwards the decrypted traffic to the Neural Inverse container over HTTP. This is a common and straightforward method, especially in cloud environments.
- Pros: Simplifies certificate management as it is usually a fully managed service (e.g. AWS ALB), offloads encryption overhead from application servers.
- Cons: Traffic between load balancer and Neural Inverse container is unencrypted (though typically within a secure network).
- Service Mesh Sidecar: This method involves using a service mesh like Istio or Linkerd. A sidecar proxy is deployed alongside each Neural Inverse container, handling all network traffic including HTTPS.
- Pros: Provides end-to-end encryption (mutual TLS), offers advanced traffic management and observability.
- Cons: Adds complexity to the deployment, requires understanding of service mesh concepts.
Once HTTPS is enabled, you can configure add LANGFUSE_CSP_ENFORCE_HTTPS=true to ensure browser only allow HTTPS connections when using Neural Inverse.
Encryption at rest (database)
All Neural Inverse data is stored in your Postgres database, Clickhouse, Redis, or S3/Blob Store. Database-level encryption is recommended for a secure production deployment and available across cloud providers.
On Neural Inverse Cloud, we use AES-256 across all databases.
See ClickHouse encryption documentation for details on how to enable encryption at rest for ClickHouse. For Postgres, Redis, and S3/Blob Storage, we recommend to use managed services by your cloud provider, which typically offer built-in encryption at rest. For self-managed, containerized deployments, refer to the documentation of the respective database system.
Additional application-level encryption
In addition to in-transit and at-rest encryption, sensitive data is also encrypted or hashed at the application level.
| Data | Encryption |
|---|---|
| API keys | Hashed using SALT |
| Neural Inverse Console JWTs | Encrypted via NEXTAUTH_SECRET |
| LLM API credentials stored in Neural Inverse | Encrypted using ENCRYPTION_KEY |
| Integration credentials (e.g. PostHog) | Encrypted using ENCRYPTION_KEY |
