Shipping services, build issues, environment variables, and monitoring.
How to read the build logs, find the failing step, and resolve the most common causes of a failed deployment.
Add your own domain to a Forte service or website and point DNS at it, with TLS issued automatically.
When you host a domain with Forte, we assign four nameservers — ns1.tryforte.dev through ns4.tryforte.dev — shown on the domain's page in the console. Set those four as your domain's nameservers at your registrar. Once they propagate, the zone becomes Active and Forte hosts your DNS.
DNS hosting is in beta and requires a verified billing method.
Just about anything. If your repository includes a Dockerfile, Forte builds it as-is, so any language or framework that runs in a container works — Node, Python, Java, Go, Ruby, Rust, PHP, .NET, and so on. If there's no Dockerfile, Forte analyzes your repository and generates one for you; common stacks like Node, Python, and Java are detected automatically.
Services deploy from a GitHub repository, and every push builds and rolls out the new version.
Every push to the branch your service is configured on triggers a new build and a zero-downtime rollout — no pipeline to set up. Forte builds your code into a container image, verifies the health check, and shifts traffic to the new version. Deployment status is reported back to GitHub as the pipeline progresses, and live build logs are in the console.
No. Forte auto-detects your language and framework and generates a Dockerfile for you. If your repository already includes a Dockerfile, Forte uses it as-is instead — you keep full control of the build when you want it.
Your service's console page has a Requests tab showing every HTTP request — method, path, status code, latency, and the log lines written while handling it, with 5xx failures highlighted. The Overview tab charts request volume, status-code distribution, and P50/P90/P99 latency percentiles, and Forte alerts you when it detects errors or performance regressions.
Pause the service from its console page. Pausing stops all provisioned compute and its billing; the endpoint returns 503 SERVICE_PAUSED until you resume, and pushes to the repository are recorded but skipped (skipped builds are free).
The URL doesn't change while paused, and a deployment you trigger manually resumes the service automatically.
Set a base directory under Advanced configuration when creating the service — for example "packages/api". Forte treats that directory as the service root: build detection, the Docker build context, and your Dockerfile all resolve relative to it, and you can deploy multiple services from one repository by pointing each at a different directory.
The base directory is fixed at creation — to move a service, create a new one pointing at the new location.
Your application must expose an HTTP GET route that returns a success status — /health, /status, or even / all work. Forte auto-detects the port your app listens on and discovers the health check path; if no route responds successfully, the deployment can't complete.
If you've changed your app's port or layout since the first deploy, reset the health check configuration in the service's Advanced Settings so Forte re-detects it.
Build & Deploy runs use a 4 vCPU, 8 GiB Linux environment and time out after 30 minutes of build runtime. Your service's environment variables are available during the build as build arguments, but secrets are deliberately runtime-only so they can't leak into build logs or image layers. If a build step needs a credential, use an environment variable. Docker-in-Docker is supported, so tools like TestContainers work.
Not reliably. Forte scales your service's compute down when it isn't handling requests, so in-process timers, cron loops, and schedulers can be paused and may never fire while the service is idle.
Use Actions instead: Forte calls a path on your service on a cron schedule or at a one-time future moment, whether or not the service is already warm.
Every request to a service must complete within 120 seconds, measured from when Forte receives it to when your service finishes writing the response; if your service hasn't started responding by then, the caller gets a 504.
Responses stream through as your service produces them, so Server-Sent Events, chunked responses, and token-by-token model output work with no configuration — as long as they finish inside the window.
Forte caches your Dockerfile and health check configuration after the first deployment so later builds are fast. When something structural changes — port, runtime version, base image, project layout — open Edit Service → Advanced Settings and toggle Reset Dockerfile or Reset to auto-detect for the health check. Saving starts a fresh deployment with re-detected configuration.
Yes, automatically. Each deployment creates a GitHub Deployment linked to the commit and posts status updates as the pipeline progresses — in_progress, then success or failure — with a link back to the full build logs in the console. The GitHub environment name is your service name, so the Environments tab in your repository shows per-service history.
Forte injects a unique ID into every inbound request via the X-Forte-Request-Id header. Read it and include it in each log line you write — any of the keys requestId, request_id, request-id, or x-request-id is recognized — and the console links those lines to the exact request.
Without it, Forte falls back to timestamp matching, which gets less accurate under heavy concurrency.
Body capture is enabled by default in sandbox projects and disabled by default in live projects, and you can change it per service in the service settings. Everything else about a request — method, path, status code, latency, headers, and correlated log lines — is captured either way.
Not with long-lived connections, but you can use HTTP response streaming. Every request to a service must finish within 120 seconds, and Forte scales your compute down when it's idle, so persistent WebSocket or long-poll connections aren't supported.
Server-Sent Events and chunked streaming work well inside the request window — for token-by-token model output or progress updates.
Yes — managed Postgres is in open beta and available to every account. Create a database in your project and connect it to your services with managed credentials; your data is encrypted in transit and at rest and connections run over TLS. Create one from the Databases tab in the console.