Services
When you deploy code to Forte, it becomes a Service. A Service is a containerized application that Forte hosts, scales, and monitors for you. Services scale up and down automatically based on demand.
How Services Work
To call a service, you send an HTTP request to its Forte endpoint. The request passes through the Forte API gateway, which authenticates the user (typically in under 5 milliseconds) and routes it to your Service within a private network. This gateway is also what gives Services their per-request authentication enforcement and observability (request logs and metrics) — Websites, including server-rendered (SSR) sites, are served directly and do not pass through it.
Service Endpoint
Every service deployed on Forte is assigned a unique HTTPS endpoint on the tryforte.dev domain. This is your service's invocation URL — the address your frontend, mobile app, or any client uses to send requests to your backend.
This endpoint is permanent. It is generated when the service is created and will never change for the lifetime of the service, even across redeployments. It is safe to copy directly into your application configuration as your backend URL.
Custom domain support is coming soon. In the meantime, the generated tryforte.dev endpoint is stable and production-ready.
Built-in Tools
Forte provides tools that make hosting and maintaining your services easy:
- Seamless request debugging: Forte captures logs from your services for every request, and provides fast failed request tracing to help you find issues quickly.
- Intelligent build system: Forte automatically detects your code's language and framework, and builds it for you — no Dockerfile or build script needed. If your repository already has a Dockerfile, Forte will use it as-is.
- Integrated monitoring: Forte provides a dashboard to view your performance metrics from your services, and sends you alerts when we detect errors or performance regressions.
Service Token
Every service deployed on Forte automatically receives three environment variables at runtime:
| Variable | Description |
|---|---|
FORTE_PROJECT_ID | The ID of the project this service belongs to |
FORTE_SERVICE_ID | The ID of this service |
FORTE_API_TOKEN | A Bearer token scoped to this service's project |
Your service can use FORTE_API_TOKEN to call Forte's server-side API — for example, to manage users, read project data, or interact with other resources within the same project. Include it as a Bearer token in your requests:
Server-side (API key):
curl -H "Authorization: Bearer $FORTE_API_TOKEN" \
https://api.tryforte.dev/api/v1/projects/$FORTE_PROJECT_ID/usersIf you use the Forte runtime SDKs for TypeScript, Java, or Python, credentials are loaded automatically from these environment variables — no manual configuration needed.
The service token can only access resources within its own project. It cannot access other projects or perform account-level operations.
FORTE_API_TOKEN is a server-side secret. Never expose it to a browser or commit it to your repository. To let your signed-in users call Forte directly from your frontend, use Forte's client-side API (forte.users.*) instead — it uses the user's session cookie, not the project API key.
The FORTE_ prefix is reserved — you cannot create custom environment variables that start with FORTE_ or AWS_.
Authentication Path Exclusions
By default, every request to your service is authenticated — Forte verifies the user's identity before forwarding the request to your application. If you have routes that need to be publicly accessible (health checks, webhooks, public APIs), you can configure authentication path exclusions to bypass user authentication for specific paths.
Pattern Syntax
Path exclusions use Ant-style patterns, supporting three wildcards:
| Token | Meaning | Example |
|---|---|---|
? | Matches exactly one character | /api/v?/status matches /api/v1/status |
* | Matches zero or more characters within a single path segment | /api/*/health matches /api/orders/health |
** | Matches zero or more path segments | /api/public/** matches /api/public/foo/bar/baz |
Common Examples
| Pattern | Matches | Does Not Match |
|---|---|---|
/health | /health | /health/deep |
/api/public/** | /api/public, /api/public/users, /api/public/a/b/c | /api/private |
/webhooks/*/callback | /webhooks/stripe/callback | /webhooks/stripe/callback/retry |
/**/*.css | /styles/main.css, /assets/fonts/icon.css | /styles/main.js |
Testing Your Patterns
When editing a service in the Console, you can use the built-in path tester to verify your patterns before saving. Enter a request path and click Test to see whether it would be excluded from authentication and which pattern matched.
Excluding paths from authentication means those requests will not be associated with a user identity. This limits Forte's ability to provide per-user observability, rate limiting, and abuse protection on those routes. We recommend keeping exclusions to a minimum and only using them for genuinely public endpoints.
CORS Preflight
Browser CORS preflight requests (OPTIONS) are automatically forwarded to your service without Forte authentication. This lets your service own its CORS policy — set the Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers response headers from your code, and Forte will return them to the browser unchanged.
This applies only to OPTIONS. Every other method — including HEAD — is still authenticated like a normal request. (Browsers send credentials on HEAD the same way they do on GET, so treating HEAD as auth-exempt would let unauthenticated callers probe response headers on protected paths.)
You do not need to add OPTIONS paths to your authentication path exclusions — preflight is exempt platform-wide.
Next Steps
- Deploy your first service with the step-by-step guide
- Learn about monitoring your services
- Understand how Projects organize your services