Skip to main content
floo puts your app behind the floo gateway for inbound traffic. Your app’s outbound traffic uses Cloud Run’s normal internet egress today.

​
Inbound traffic

Inbound HTTP and WebSocket traffic reaches your app through floo’s edge:
  1. The request hits your *.on.getfloo.com host or custom domain.
  2. The floo gateway looks up the matching route.
  3. Edge policy and managed auth run before traffic reaches your container.
  4. The gateway proxies the request to the target app service.
Do not expose or depend on raw *.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: 
floo edge routes list --app my-app --env prod
floo edge routes list --app my-app --env prod --json

​
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:
QuestionAnswer
Can my app call public HTTPS APIs?Yes. Use the normal SDK or HTTP client for that service.
Does floo provide a stable outbound source IP?Not today. Do not ask a vendor to allowlist a fixed floo egress IP.
Is outbound port 25 available for SMTP?No. Use an authenticated SMTP provider on 587 or 465, or use the provider’s HTTPS API.
Does floo attach my app to my private VPC or tailnet?Not today. Private networking is a planned enterprise connector model.
Do managed services need public egress?No. floo injects managed service credentials. Use the provided env vars and SDKs.
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.
The first supported target will be an enterprise deployment where the customer owns the private network and runs the connector near the private service. floo will publish the connector lifecycle, routing model, auth model, and failure behavior before enabling the feature for production workloads.

​
Common patterns

​
Calling Slack, Stripe, GitHub, or other HTTPS APIs

Use the provider SDK or HTTPS API as usual. Store tokens with floo env set and read them from environment variables in your app. 
floo env set SLACK_WEBHOOK_URL --app my-app
git push origin main

​
Sending email

Use an email provider’s HTTPS API when possible. If you use SMTP, use authenticated submission on port 587 or 465. Port 25 is not the right path for app mail.

​
Vendor asks for an allowlisted source IP

floo does not provide a stable app egress IP today. Prefer API-token auth, OAuth, mutual TLS, or vendor-side domain verification where the vendor supports it. If source-IP allowlisting is mandatory, contact floo before committing to that integration.