Skip to main content
Multi-service apps share a single hostname. floo routes requests to the right service based on path prefix.

​
Default path assignment

Service typePath prefix
web/
api/api/
other/<name>/
A full-stack app with a web and api service gets:
  • https://full-stack.on.getfloo.com/ → web
  • https://full-stack.on.getfloo.com/api/ → api
The web service is the catch-all — any path not matched by a more specific prefix falls through to it.

​
Why same origin matters

All services share one hostname, so cookies and session tokens set by the web service are visible to the api service without any cross-origin configuration. No CORS headers needed for same-origin requests. If you separate services onto different domains, you’ll need to configure CORS and handle cross-origin cookie restrictions.

​
Per-service debug hostnames

Each service also gets its own hostname for direct access: 
https://<app>-<service>.on.getfloo.com
Examples: 
https://full-stack-web.on.getfloo.com
https://full-stack-api.on.getfloo.com
These are useful for debugging a specific service or connecting external tools directly to one service.

​
Custom domains

Add a domain field to a service in floo.app.toml to bind a custom domain to that service: 
[services.api]
type = "api"
path = "./api"
port = 8000
ingress = "public"
domain = "api.example.com"
A custom domain overrides the default path-prefix routing for that service. Traffic to api.example.com goes directly to the api service, bypassing the shared hostname routing. See Custom Domains for DNS setup.

​
Local development

During floo dev, each service runs on its own localhost port. Discovery vars (API_URL, WEB_URL, etc.) are injected so services can find each other without hardcoding ports. See floo dev for the full local dev reference.