Websites

Forte hosts websites — front-end applications deployed from a GitHub repository, built automatically, and served over HTTPS on a global content delivery network. Use websites for marketing pages, dashboards, single-page apps, documentation sites, and any other static or server-rendered front-end.

Websites are frontend only. Whenever you need user-authentication enforcement, the server-side Forte API (forte.projects.*, which requires FORTE_API_TOKEN), or request observability, pair your website with a Service and call it from the browser — see Authentication & Request Handling below.

How Websites Work

When you create a website, Forte connects to your GitHub repository, builds it for you, and serves the output globally over a CDN. Each git push to the configured branch triggers a new build and deployment automatically.

Website URL

Every website is assigned a unique HTTPS URL on the sites.tryforte.dev domain:

javascript

https://{websiteId}.sites.tryforte.dev

This URL is permanent — it is generated when the website is created and will never change for the lifetime of the website, even across redeployments. It is safe to copy directly into DNS records, marketing materials, or any place that expects a stable URL.

Custom domains

Custom domain support is coming soon. In the meantime, the generated sites.tryforte.dev URL is stable and production-ready.

Build Configuration

Forte automatically detects how to build most popular frameworks (Next.js, Vite, Astro, Create React App, Vue, Angular, plain HTML, and more). When auto-detection isn't enough, you can override:

Setting	Description
Build command	The command Forte runs to build your website (e.g., `npm run build`)
Output directory	The folder where built files land (e.g., `dist`, `out`, `build`)
Install command	The command to install dependencies (e.g., `npm install`)
Package manager	One of `npm`, `yarn`, `pnpm`, or `bun`
Node.js version	The major version of Node.js used to build (e.g., `18`, `20`)
Subdirectory	The path within your repository to build from — used for monorepos

If your repository changes — say, you add a new framework or move where package.json lives — you can reset the auto-detected configuration on the website's edit page so Forte detects fresh on the next build.

Build Triggers

Choose how new deployments are triggered:

On every push to branch — Every commit to the configured branch redeploys automatically. Best for staging and continuous-deployment workflows.
On GitHub release published — Only redeploys when a new GitHub release is published. Best for production websites that should only roll forward on tagged releases.

You can also manually deploy any commit at any time from the website's deployment page.

Environment Variables and Secrets

Set environment variables and secrets on your website:

Environment variables are injected into the build environment and accessible via standard mechanisms (process.env.NAME in Node.js, etc.). They're visible in the console and in build logs. Use them for non-sensitive build-time configuration like feature flags and public API URLs.
Secrets are encrypted at rest, never displayed in the console once saved, and not injected into the build environment. This prevents them from leaking into build logs or the published static bundle. Because websites are served as static assets from a CDN with no Forte-managed server runtime, secrets stored on a website are effectively unused today; treat the field as forward-compatible storage. For any value your build needs to read, use an environment variable.

The FORTE_ and AWS_ prefixes are reserved — you cannot create custom environment variables that start with either. A handful of additional names are also reserved for the automatic identifiers described below.

Automatic identifiers

Forte injects the website's project ID and website ID into every build and (for server-rendered sites) into the runtime as well. Each identifier is exposed under every common framework prefix so it reaches both your server code and your client bundle without extra configuration:

Identifier	Canonical	Next.js	Vite	CRA	Angular	SvelteKit	Nuxt
Project ID	`FORTE_PROJECT_ID`	`NEXT_PUBLIC_FORTE_PROJECT_ID`	`VITE_FORTE_PROJECT_ID`	`REACT_APP_FORTE_PROJECT_ID`	`NG_APP_FORTE_PROJECT_ID`	`PUBLIC_FORTE_PROJECT_ID`	`NUXT_PUBLIC_FORTE_PROJECT_ID`
Website ID	`FORTE_WEB_APP_ID`	`NEXT_PUBLIC_FORTE_WEB_APP_ID`	`VITE_FORTE_WEB_APP_ID`	`REACT_APP_FORTE_WEB_APP_ID`	`NG_APP_FORTE_WEB_APP_ID`	`PUBLIC_FORTE_WEB_APP_ID`	`NUXT_PUBLIC_FORTE_WEB_APP_ID`

All of these names are reserved — attempting to set one of them as a custom env var or secret is rejected with a validation error so the platform value is always the one your code reads.

No API token in the bundle

FORTE_API_TOKEN is not injected into websites. A website ships code to every visitor's browser, and a token reachable from client code would be a public secret — every visitor could act as the project owner. If your server-rendered site needs to call the Forte API with project-level privileges, store the token as a Secret on the website and read it only from server-side code paths. See API Surfaces for the full credential-safety model.

Authentication & Request Handling

Websites are public — every visitor can access them. Website requests are served directly from the CDN and do not pass through the Forte gateway. This is true for both static and server-rendered (SSR) websites: your SSR server code runs, but Forte does not sit in front of it.

Websites bypass the Forte gateway

The request-time features that Services get do not apply to websites — static or SSR:

No user-authentication enforcement. Forte does not authenticate requests to a website or inject the X-Forte-User-Id header. Auth path exclusions and end-user session enforcement are Service features — an SSR website must implement and enforce its own auth.
No per-request observability. The request logs, metrics, and latency percentiles described in Monitoring are captured for Services only. Forte does not log or meter individual requests to a website.
forte proxy and local auth testing are Service features.

If your front-end needs authenticated, observable request handling, deploy that logic as a Service. A Service receives the X-Forte-User-Id header and Forte session context automatically on every authenticated request, and each request is logged and metered. Your website can call that Service from the browser.

Quotas

Each project supports up to 10 websites for free. Beyond that, billing must be enabled on the project.

Next Steps

Deploy your first website with the step-by-step guide
Learn about Services for back-end APIs and authenticated routes
Set up a monorepo to deploy a website and a service from the same repository