Core concepts

Everything on Fortly hangs off one thing: the project. A project is an address, the code served there, a PostgreSQL database, stored files, environment values, domains and schedules, all owned together and deleted together. This page explains each part and how they relate, and links to the page that covers it in full.

How the parts fit

The console, the HTTP API at https://api.fortly.com and AI agents all act on these same objects. The console does everything through the same API you can call.

Projects

A project has two names:

• Its label is the name you chose, such as my-app. Labels are unique within your account.
• Its name is the label joined to your account name, such as my-app-ada. It is unique across Fortly, it is the first part of the project's address, and it is what every API route takes: /projects/my-app-ada/deploys.

The project's address is https://<name>.fortly.com. Your account name starts out as the letters and digits of your email address before the @, and you can change it under Settings; projects whose addresses follow it move with it. The API returns both names and the full url whenever it returns a project, so read them from there rather than building them yourself.

Deleting a project removes everything it holds: the database, files, releases, secrets, domains, and the stored copies of all of them. There is no undo. Only the account owner or an admin can delete a project; see Team and roles.

Releases

A release is what your project serves. You make one by uploading a gzipped tar (or a .zip, in the console) or by deploying a linked GitHub repository.

• A folder with an index.html and no package manifest is a static site. It goes live within the request.
• Source with a package.json is installed and built by Fortly first, and the build's output appears in the project's log as it runs. What the build produces decides how it is served: static output from storage, a server framework on Fortly's runtime. Builds lists what can be built.

A new release replaces the live one only once it is ready. If a build fails, the release that was already live keeps serving. Earlier releases stay in the project's history, and you can make one live again without rebuilding it. See Deploying, Builds and Releases and rollback.

The database

Every project has its own PostgreSQL database with its own credentials. Nothing is shared with other projects, and all of it can be exported.

There are several ways in, each for a different caller:

Schema changes go through /sql, which accepts create, alter and drop. Reads and writes go through the table routes, where values are always bound as parameters. See The database, the server API and the frontend API.

Files

Files you upload to a project are stored with it and served at /_files/… on the project's address. Fortly serves them itself, without starting your code, so an idle project still serves its images. An uploaded file is never served as HTML, whatever it claims to be. See Files.

Domains

Every project has its Fortly address. To serve it on your own domain as well, you add the domain and publish two DNS records: a TXT record that proves the domain is yours, and a CNAME that sends its traffic to the project. A domain serves nothing until ownership is proved. See Domains.

Secrets

Secrets are a project's environment values: API keys, connection strings, configuration. They are encrypted at rest, and the API lists their names and dates but never returns a value.

Each secret has a scope:

• runtime (the default) reaches your running code.
• build reaches the build only, for values a framework bakes into its output.
• both reaches both.

Your code reads its environment once, when it starts, so setting or removing a secret restarts the project. A few names, such as PORT and DATABASE_URL, are set by Fortly and cannot be replaced. See Environment and secrets.

Schedules

A schedule requests a path on your project on a timer, written as five cron fields in UTC. A run is an ordinary GET request to your project, so it wakes it, is logged, and is handled by your own code. A run that takes longer than 5 minutes is abandoned. See Schedules.

Idle projects and waking up

A project whose code runs as a server process is stopped after 15 minutes without a request, and the next request starts it again. Nothing has to be restored by hand, and the address never stops answering; the first request after an idle spell takes longer than the ones after it.

Static sites and files are served from storage, so they have nothing to stop.

Tokens and keys

Four kinds of credential exist, and each one is for a different holder. Use the narrowest one that does the job.

The publishable key is the only one that is safe to ship to a browser. Every table starts closed to it, and you open read, create, update and delete separately for each table. The rules are per table, not per row.

Accounts and teammates

Projects belong to an account. You can invite people to yours as an admin or a member, and they then see and work on your projects alongside their own. See Team and roles.