Gateway nodes are Garage cluster members that serve S3 API and website endpoints without storing data locally. They provide an optimized access layer for your Garage cluster.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/deuxfleurs-org/garage/llms.txt
Use this file to discover all available pages before exploring further.
What is a Gateway Node?
A gateway node participates in the Garage cluster as a full member but is configured to store zero data blocks. It handles S3 API requests and serves static websites while forwarding storage operations to data nodes.Benefits of Gateway Nodes
Reduced Network Latency
Gateway nodes eliminate 1-2 network round trips:- Without gateway: Client → Reverse Proxy → Random Node → Storage Node(s)
- With gateway: Client → Gateway Node → Storage Node(s)
Simplified Server Management
Benefits include:- No reverse proxy updates needed - Gateway nodes track cluster membership automatically
- Consistent endpoints - Always connect to
http://localhost:3900 - Automatic failover - Gateway nodes handle node availability internally
Enhanced Security
Gateway nodes improve security posture:- No TLS certificate management - Use Garage’s encrypted RPC protocol
- Local-only access - S3 API available only on localhost
- Encrypted cluster communication - All inter-node traffic uses Secret Handshake protocol
Setting Up a Gateway Node
Prerequisites
- Running Garage cluster with at least one data node
- Garage binary installed on the gateway machine
- Network connectivity to cluster RPC ports
Configuration
Gateway nodes use the same configuration file format as regular nodes. The key difference is in the layout assignment, not the configuration. Example garage.toml:Bind S3 API and web endpoints to
127.0.0.1 (localhost) on gateway nodes to restrict access to local applications only.Assigning Gateway Role
The critical step is assigning the node with the--gateway flag:
--gateway: Marks the node as a gateway (no data storage)--tag gw1: Assigns a human-readable tag for identification-z dc1: Assigns the node to a zone (for topology awareness)<node_id>: The node’s unique identifier (fromgarage node id)
Verifying Gateway Operation
Check that the gateway node is operational:Troubleshooting
Gateway Not Working After Addition
If a newly added gateway seems non-functional, perform a full table resync:Connection Refused Errors
Verify the gateway can reach storage nodes:- RPC ports (3901) are not firewalled
rpc_secretmatches across all nodesrpc_public_addris correctly configured on storage nodes
Performance Issues
If gateway performance is poor:-
Check network latency to storage nodes:
-
Monitor gateway resource usage:
-
Review Prometheus metrics at
http://localhost:3903/metrics
Deployment Patterns
Co-located Gateway
Run a gateway node on each application server:- Minimal latency
- No network bandwidth between app and gateway
- Simple security model
Dedicated Gateway Cluster
Deploy multiple gateway nodes behind a load balancer:- Scalable gateway capacity
- High availability
- Separation of concerns
Multi-Site with Local Gateways
Gateway nodes in each datacenter:- Reduced cross-datacenter traffic
- Better data locality
- Geographic redundancy
Best Practices
- Use descriptive tags - Name gateways by location or purpose (e.g.,
gw-web-dc1) - Assign zones appropriately - Place gateways in zones they primarily serve
- Monitor gateway health - Track metrics for request latency and error rates
- Don’t overload gateways - Scale gateway count with request volume
- Secure localhost bindings - Use firewall rules if needed to prevent local access
Gateway Limitations
- Gateway nodes count toward cluster membership but not storage capacity
- Gateway nodes still maintain metadata databases (buckets, keys, indices)
- Gateway nodes cannot serve requests if all storage nodes in a quorum are unavailable