Services

A project is one set of resources: its database, auth and storage. A service is something in the project you deploy on its own. Every project starts with one service, its application, served at the project's address. Add more when a codebase has several deployable parts. A monorepo with a website in apps/web and an API in apps/api is one project with two services.

Each service has its own:

Address: <service>--<project>.fortly.com, for example api--ormi-ada.fortly.com.
Releases: deploying one service never replaces another's live release.
Source: a repository folder or an uploaded archive, and its own build.
Variables: only the values set on that service. Service variables are not shared with the project or with other services.

All of a project's services use the same database, users and storage.

The Overview groups PostgreSQL, the Data API and storage into the Fortly foundation. Its connector lines show the application's and services' shared project resources. Individual access follows the configured credentials and grants; direct database access remains off for a new service until an owner or admin enables it.

Workspace members may deploy to projects they have access to. Deployment artifacts and resource accounting stay under the project's owning account, including when a teammate initiates a deployment. Service identity and parent ownership are checked before publication.

Add a service

Open the overview

On your project's Overview, select Add a service. When the project already has services, the Add service card is next to them.

Name it

The name is how the service appears in the console. Its address comes from the name and does not change when you rename it.

Choose where its code comes from

GitHub folder. Choose a repository and branch. Fortly reads the repository and suggests the folders that look like applications, or you can browse to any folder. Selecting one shows how it will be built: framework, package manager, and the workspace root dependencies are installed from. Leave Deploy on every push on to deploy the service whenever that branch changes.
Upload. Drop a .zip or .tar.gz of the whole codebase and choose the service's folder. The whole archive is sent, so a workspace that installs from its root still works.
Empty. Create the service now and deploy it later from its page.

Create and deploy

The service is created only at this step, with its first release. Leaving the setup before this step creates nothing.

Deploy on push

When a service's source has Deploy on every push on, Fortly installs one GitHub webhook for the repository, shared by every service in the project that uses that repository. A push to a branch deploys every service that follows that branch. Each service is built from its own folder at the exact commit that was pushed. A service following another branch is not touched.

Installing a webhook requires admin access to the repository. Without it, the service's Source says that pushes don't deploy yet. Select Deploy latest to deploy by hand, or have a repository admin save the source.

GitHub can deliver the same push more than once. Each delivery is deployed only once.

Each service's page

Select View build or Deployments on an Overview service card, or open the project's Deployments page and choose the service in Deployments for. The main application is the default selection. Switching targets clears the previously selected release, so another service's build cannot remain on screen under the new name.

Service links use /p/{project}/deployments?service={service_id}. Existing /p/{project}/services/{service_id} links continue to work and include the same target selector.

Deployments: the selected release's progress and live build output, its saved source, Deploy latest, Change folder, Upload, and release history. Select View build on a release to inspect it. Load older releases reads the next history page. Build output refreshes while a release is building; a historical release stays selected as new attempts arrive.
Variables: values only this service receives, at runtime, during its build, or both. Running code sees a change on its next request; a build value applies from the next build.
Settings: rename it, give it the database, or delete it.

Each application and service address has a Copy control. On the Overview, the application's address sits below its name; a service's address is on its own card. The three-dot menu beside a service opens its deployments, variables, settings and deletion confirmation. A building service is marked Building even before its first successful release.

Once the selected release is live, Open app appears beside its completion message and opens that target's address. Pending, failed and superseded releases do not present themselves as a live application.

The database

A new service doesn't receive the project's PostgreSQL credentials. Turn on Give this service the project's PostgreSQL in its Settings when it needs to query the database directly. Workspace owners and admins can change this setting. A service that only calls your application's API doesn't need it.

The project's application always has database access.

Delete a service

Workspace owners and admins can delete a service. Deleting it immediately stops its address from answering. Its stored releases, variables and saved source are removed. The project's application, its database and its other services are not affected.

Open the service card's three-dot menu and select Delete service, or use Settings → Delete service. Type the displayed service name in the confirmation dialog. Cancel leaves it untouched. If the service changed after you opened the dialog, reload it and confirm the current name before retrying; the previous revision cannot silently delete changed settings. Workspace members who cannot delete services do not see the deletion action, and the API checks the current role again when the request arrives.

The project's application can't be deleted on its own; delete the project instead. Its Overview menu labels that action Delete project and uses the separate project confirmation, including the database and file removal warning.

What stays with the project

Custom domains and schedules currently belong to the project's main application. A service is reached at its own -- address.

Runtime logs and metrics

Open Metrics or Logs from a service's navigation or three-dot menu. Monitoring for in Observability also selects any application address, including the main application. All application addresses shows the existing project aggregate; the same request is not charged again for its service-level measurement.

Each address has its own request/error/latency/CPU measurements, route statistics and resumable runtime log stream. Metrics begin when service monitoring is deployed; old aggregate history remains under the project view. Per-service runtime output is recent bounded output, separate from a release's build output. The release selector opens that target's build panel.

The API checks current project access and service ownership before returning history, charts or a stream. Long-lived service streams recheck token validity, membership and service existence every ten seconds. Deleting a service removes its live runtime-log scope. Newly captured scoped log copies use the same secret-redaction path as the project aggregate.

Restore a retained release

Select the application or service in Deployments, find a previous release in Recent releases, and choose Roll back from its actions. Review the target service and confirm. The retained artifact is verified again before its traffic changes. A missing or corrupted artifact is refused, leaving the current release selected; sibling services keep serving their own releases.

Rollback restores code without rebuilding or running migrations again. Database schema and rows, stored files and current environment values are unchanged. An active build can still publish afterward. Use the database restore workflow separately when data recovery is required.

Deployment progress comes from the server: build, artifact validation, database migrations and publication. The panel retains the failed step even when the builder is unavailable. Build output has its own reconnect state; a finished compiler log does not mean the release is published. Older releases without a progress record explicitly show that migration history was not recorded.