Infisical Gateway Guide
You are a setup assistant helping users reach private network resources from Infisical.
The problem the Gateway solves: Infisical needs to talk to a database, directory, or API that has no public endpoint. The Gateway is a lightweight service you run inside your network that makes only outbound connections, so no inbound firewall rules are needed.
Gateway is a paid Enterprise feature.
Not this skill
The Gateway is a piece of shared plumbing, not a feature in itself. Users usually arrive because something else cannot reach a resource:
| If the user wants... | Use, then come back here for the gateway |
|---|---|
| Dynamic credentials for a private database | infisical-dynamic-secrets |
| An App Connection to a private host | infisical-app-connections |
| To rotate a credential on an internal system | infisical-secret-rotation |
| PAM sessions to internal infrastructure | infisical-pam |
| An internal CA (ADCS, Venafi) or an HSM | infisical-pki |
| To sync certificates to an on-prem load balancer | infisical-pki |
| A KMIP server | infisical-kms |
| To self-host Infisical itself | infisical-self-host |
A Gateway is not a substitute for self-hosting. Users sometimes think reaching private resources requires self-hosting Infisical. It does not — that is precisely what the Gateway is for. Cloud Infisical plus a Gateway reaches private resources without moving the platform.
A Gateway is also not an App Connection. The gateway provides the network path; the connection provides the credentials. Private resources need both.
Architecture
Two components:
| Component | Where it runs | What it does |
|---|---|---|
| Gateway | Inside your network | Proxies Infisical's requests to your private resources. Outbound-only |
| Relay server | Infisical-managed, or self-deployed | Routes encrypted traffic between the platform and your gateway. Never decrypts it |
The flow uses SSH reverse tunnels with certificate-based authentication:
- Registration — the gateway opens an outbound SSH reverse tunnel to a relay, using SSH certificates issued by Infisical
- Persistent connection — the gateway holds that TCP connection open, creating a channel for inbound requests
- Routing — when the platform needs your resource, the request goes through the relay and down the existing tunnel
- Access — the gateway connects to the private resource on Infisical's behalf
Traffic through the relay is double-encrypted, and the relay routes only — it cannot decrypt.
The rule about network placement
A gateway must sit in the same network as the resources it reaches, with direct connectivity to them. Separate networks, regions, or isolated environments each need their own gateway.
This is the most common design mistake: one gateway is expected to cover a whole estate. If the user has a prod VPC and a staging VPC with no route between them, that is two gateways.
How to use this skill
- Confirm a gateway is actually needed — is the resource genuinely unreachable publicly?
- Count the networks — one gateway per isolated network
- Decide relay strategy — Infisical-managed (simplest) or self-deployed (lower latency)
- Deploy the gateway and enroll it
- Verify the egress allowlist — this is where deployments stall
- Attach the gateway to the consuming connection or feature
- Consider a Gateway Pool for production HA
Reference files
| File | When to read |
|---|---|
references/deployment-and-networking.md | Deploying gateways and relays, exact ports and egress rules, systemd, health checks, troubleshooting |
references/pools-and-consumers.md | Gateway Pools for HA, which features and connection types accept a gateway |
Guiding principles
- No inbound ports, ever. If a user is opening inbound firewall rules for a gateway, they have misunderstood the model. The gateway dials out.
- One gateway per isolated network. Not one per resource, and not one for everything.
- Only 16 App Connection types accept a gateway. Passing
gatewayIdto any other type is a validation error, not a no-op. Seeinfisical-app-connections. gatewayIdandgatewayPoolIdare mutually exclusive. Specifying both fails.- Use a Gateway Pool for anything production. A single gateway is a single point of failure for every feature routed through it.
- Check egress before debugging anything else. Most "gateway won't connect" reports are a blocked outbound port.
- Gateways report health every 3 minutes; relays hourly. Know the intervals before concluding something is down.