# Core concepts > Learn what a project, a release, the database, files, domains, secrets, schedules and each kind of credential are, and how they fit together. Source: https://docs.fortly.com/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 | Part | What it is | Belongs to | |---|---|---| | [Project](#projects) | The unit you create, deploy to and delete | Your account | | [Release](#releases) | One upload or repository commit, built if needed and served | A project | | [Database](#the-database) | A PostgreSQL database of the project's own | A project | | [Files](#files) | Uploaded files, served at `/_files/…` | A project | | [Domains](#domains) | Your own hostnames pointed at the project | A project | | [Secrets](#secrets) | Encrypted environment values | A project | | [Schedules](#schedules) | Requests to a path on the project, on a cron timer | A project | | [Credentials](#tokens-and-keys) | API tokens, the project token, the publishable key, agent grants | Your account or a project | 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://.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](https://docs.fortly.com/account/team). ## 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](https://docs.fortly.com/deploy/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](https://docs.fortly.com/deploy), [Builds](https://docs.fortly.com/deploy/builds) and [Releases and rollback](https://docs.fortly.com/deploy/releases). ## 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: | Caller | How it reaches the database | Authenticates with | |---|---|---| | You, in the console | The project's **Data** tab | Your sign-in | | Scripts and CI | `https://api.fortly.com/projects/{name}/tables/…` and `/sql` | An API token | | Your server code | The server API, from inside the running project | The project token | | Browsers | `/_data/…` on the project's own address | The publishable key | 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](https://docs.fortly.com/data), the [server API](https://docs.fortly.com/data/server-api) and the [frontend API](https://docs.fortly.com/data/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](https://docs.fortly.com/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](https://docs.fortly.com/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](https://docs.fortly.com/deploy/environment). ## 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](https://docs.fortly.com/deploy/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. | Credential | Looks like | Can do | Belongs in | |---|---|---|---| | [API token](https://docs.fortly.com/account/tokens) | `fly_…` | Anything your account can do, on every project you can reach | Scripts, CI, your own machine | | Project token | Given to your code as `FORTLY_TOKEN` | Anything to that one project's data, through the server API | Your project's server code | | [Publishable key](https://docs.fortly.com/data/frontend-api) | `cvp_…` | Only what that project's per-table rules allow | Browser code, mobile apps | | [Agent grant](https://docs.fortly.com/agents/mcp) | Issued when an MCP client signs in | Only the tools and projects you approved | An AI agent | 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](https://docs.fortly.com/account/team). - [Quickstart](https://docs.fortly.com/quickstart): Create a project and deploy a first page in a few minutes. - [Limits](https://docs.fortly.com/account/limits): Upload sizes, file counts, timeouts and other hard numbers.