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.
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 the Forte 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:
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.
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.
Next Steps
- Deploy your first service with the step-by-step guide
- Learn about monitoring your services
- Understand how Projects organize your services