Multi-Tenant mTLS Proxy
Open-source proxy that issues signed certificates and dynamic routes per tenant, built to simplify App Builder integrations when clients need stable outbound identity.
Go mTLS TLS Reverse proxy Open source
Overview
An open-source, multi-tenant mTLS proxy that lets users onboard an application, receive signed certificates automatically, and configure dynamic routes to downstream services. Born from a recurring problem at work: Adobe Commerce clients on App Builder often need IP allowlists, but serverless runtimes do not offer a fixed egress IP to share.
The problem
- App Builder (serverless) has no stable outbound IP list for clients to allowlist
- Common guidance: “run your own mTLS proxy” (correct, but heavy for many clients)
- Many teams lack appetite or skills to stand up, harden, and maintain a proxy long term
- You wanted something repeatable you could point implementations at
What it does
Outline: align with README / actual behavior.
- Tenant onboarding: what a tenant is, what gets created on signup
- Automatic certificate issuance: CA model, rotation, storage
- Dynamic routing: how routes map incoming requests to downstream services
- mTLS termination / origination: where TLS ends and starts in the path
- Operational boundaries: what admins configure vs what tenants configure
Architecture
Outline:
- Control plane vs data plane (if separated)
- Certificate authority / signing flow
- Route table storage and reload behavior
- How multiple tenants are isolated (certs, routes, namespaces)
- Deployment target you have in mind (VM, k8s, single binary, etc.)
Tech stack
| Area | Choice | Notes |
|---|---|---|
| Language | Go | TODO: why Go for networking/crypto |
| Protocol | mTLS | TODO: client cert expectations |
| Distribution | Open source | GitHub: multi-mtls-proxy |
Work context (without oversharing)
- How this maps to App Builder → client allowlist conversations
- What “good enough” looks like for a client who is not infra-heavy
- What you are not trying to solve (scope boundaries)
Challenges and decisions
- Certificate lifecycle and revocation
- Tenant isolation guarantees
- Safe defaults for clients who do not live in TLS daily
- Why multi-tenant in one deployment vs per-client proxy
Status
Not live yet. Development and hardening in progress. Goal is to run it internally and start using it for real client onboarding flows.
What’s next
- Production deployment plan
- Documentation for “client onboarding in 30 minutes” style guide
- Hardening checklist (authz, audit logs, rate limits)
- First real tenant / dogfood story
Links
- GitHub: multi-mtls-proxy
- TODO: Live demo / docs site when available
