One repo.Every app, one project.

One project. Every app in the repo.

A monorepo can hold a website, an API, workers and shared packages. On Fortly, the repository becomes one project: one PostgreSQL database, one set of users, one storage space and one team. Each app you choose to deploy becomes a service of that project, with its own address, releases and variables.

The first app you choose is the project's application, at the project's address. Each other becomes a service at <service>--<project>.fortly.com. Deploying one never replaces another's live release, and a service reaches the database only when an owner or admin turns that on.

Choose the folders to deploy.

After you pick a repository, Fortly reads it at your branch and lists the folders that look like applications, with their framework. A filter finds any folder by name. Every folder you choose is checked before anything is created, so a folder that cannot be built is reported rather than half deployed.

Shared packages stay with every app.

The app's folder and the install folder can differ. A web app in apps/web installs from the repository root, links packages/shared and follows the root lockfile. Fortly builds each service from its own folder with the whole workspace beside it, so those relationships hold.

With deploy on every push turned on, one GitHub webhook serves the repository. A push rebuilds every service that follows that branch, each from its own folder, at the exact commit that was pushed. A redelivered push is deployed once.

Keep private authority on the server.

Services of one project share its database, users and storage, but not their variables: each receives only its own. A service other than the application reaches PostgreSQL only when an owner or admin grants it, so a frontend service never holds the database credential by accident.

A frontend may receive the API's public HTTPS address. It must not receive the account token, an owner database password or a private S3 key. Build-time public values can be compiled into browser files, even if their input field was masked. Keep private server values in runtime configuration and use Data API roles, verified app-user identity and row policies for browser access that needs them.

Each service has its own release history. Reverting the frontend does not revert the API, change a table back, or restore stored objects. Plan schema changes so the previous published app can still handle the data it encounters. Release rollback and database recovery are distinct operations.

Verify the selected app before calling it done.

1. Confirm the expected source, branch and commit in the release details.
2. Read the build output for the app and dependency install you intended.
3. Wait for publication, then open an application route and refresh a direct nested URL.
4. Exercise a real data request using the caller's actual permissions.
5. Check runtime logs if the build succeeds but requests fail.

An accepted build is still work in progress. A failed attempt does not replace an earlier live release; on a first deployment, there is no previous release to serve. Read the first meaningful error and change the relevant source, configuration or permission before retrying. The failure-stage guide helps identify that next action.