Inbound traffic
Inbound HTTP and WebSocket traffic reaches your app through floo’s edge:- The request hits your
*.on.getfloo.comhost or custom domain. - The floo gateway looks up the matching route.
- Edge policy and managed auth run before traffic reaches your container.
- The gateway proxies the request to the target app service.
*.run.app backend URLs. Treat floo hosts and custom domains as the public contract.
Use the route table when you need to inspect what the edge is serving:
Outbound egress
When your app calls a public HTTPS API, a Slack webhook, a payment provider, or an SMTP provider, the request leaves from the app’s Cloud Run runtime through Google Cloud’s standard internet egress path. Current contract:
If a third-party vendor requires source-IP allowlisting, email team@getfloo.com before designing around that requirement.
Private network deployments
Private network deployments are not generally available yet. The planned model is an outbound-only customer-side connector:- The floo control plane stays public.
- App traffic to private backends stays inside your network.
- The connector opens an outbound tunnel to floo, so you do not need to expose inbound ports.
- The floo gateway remains the auth, edge-policy, and audit boundary.
- Tailnet is one possible transport, not the product model itself.
Common patterns
Calling Slack, Stripe, GitHub, or other HTTPS APIs
Use the provider SDK or HTTPS API as usual. Store tokens withfloo env set and read them from environment variables in your app.