> ## Documentation Index > Fetch the complete documentation index at: https://docs.leapter.com/llms.txt > Use this file to discover all available pages before exploring further. # Runtime clusters, environments and releases > How a release gets from the Lab to a runtime cluster, what callers need to run it, and which role may do what. You build and test a project in the Lab. A runtime cluster is where a released version of that project runs for other systems: an order system, an AI agent or an n8n workflow calls one of its blueprints and gets the result back. This page explains the parts of a runtime cluster and how they relate. The steps are on the other pages of this guide. ```mermaid theme={null} flowchart LR Lab["Lab: project"] -- "Create release" --> Release["Release v1"] Release -- "Deploy" --> App subgraph Cluster["Runtime cluster"] subgraph Env["Environment"] App["Application"] end end Caller["Calling system"] -- "run address + evaluation key" --> App ``` ## Environments A runtime cluster holds one or more environments. An environment is a separate place to run releases, for example one for trying things out and one for production. Each environment has a name and a tier. The Admin UI shows both at the top of the **Status** page, for example `playground development`. Most things are set per environment: who may deploy, which keys exist, and which runs were recorded. A key or a right in one environment does nothing in another. ## Applications When you deploy a project to an environment, it becomes an application there. The application's name comes from the project's name, in lowercase with hyphens. In some environments, the cluster adds 6 characters of the project's ID, for example `pizza-pricing-calculator-180269`. The Lab tells you the name when you deploy: "This project is called pizza-pricing-calculator-180269 there." Each application has its own current release and its own history. Two projects in the same environment never change each other. In short: a release is what runs, and an application is the place in one environment where it runs. ## Releases and deploying A release is a version of a project that never changes once it is created. In the Lab, the **Deploy** dialog first creates the release, then deploys it. Deploying tells an environment which release to serve for an application. The cluster records every deploy and every roll back with a number, for example `deploy 11` on the **Status** page. A roll back serves the release before the current one again. A second roll back serves the newer release again. After a deploy or a roll back, the cluster needs a short time, usually one to three minutes, until every worker serves the new release. Only public blueprints of a release can be called. The **Deploy** dialog lists them under **Callable on the cluster**. On the cluster, a blueprint is called by its name in lowercase with underscores: the blueprint **Pizza Pricing** is `pizza_pricing`. ## Calling a release Every callable blueprint has a run address: ```text theme={null} https://cluster.example.com/runtime/api/v1///models//runs ``` The Admin UI shows the run address of each blueprint, the address for MCP clients, and the address of the OpenAPI document. [Call a release over REST](https://docs.leapter.com/rc/user-guide/call-rest.md), [Connect an MCP client](https://docs.leapter.com/rc/user-guide/connect-mcp.md) and [Call a release from n8n](https://docs.leapter.com/rc/user-guide/call-from-n8n.md) show how to use them. ## Evaluation keys A caller sends an evaluation key in the `X-API-Key` header of every call. A key belongs to one application in one environment, and to the system that calls with it, not to a person. So it keeps working when the person who created it leaves. Its first characters show the environment's tier: `lk_dev_` in a development environment. An application without a key is not served: nothing can call it. The **Status** page says "Not served yet: this application has no evaluation key in" and the environment's name until you [create a key](https://docs.leapter.com/rc/user-guide/evaluation-keys.md). When you revoke a key, calls with it are refused within about a minute. ## Runs and usage Every call is a run. The cluster records each run: when it started, how long it took, which release ran, the input and the output. Test runs in the Lab are not recorded here. In the Admin UI, [**Runs**](https://docs.leapter.com/rc/user-guide/runs-and-usage.md) lists the runs and **Usage** counts them. The input and output of a run are its payloads. They can be deleted on their own. The facts of the run stay: when it ran, how long it took, which release ran, its correlation ID and its status. So the cluster keeps a record that the run happened. ## Who may do what The cluster decides from grants what a person may do: deploy a release, create and revoke evaluation keys, or read runs and usage. On Leapter Cloud, your first deploy of a project to `playground` gives you the rights on that application there, so you need no one to give them to you. On a runtime cluster of your own workspace, the admin of the cluster gives you the rights you need. ## What to do next * [Deploy a release and call it](https://docs.leapter.com/rc/user-guide/deploy-and-call.md): try the whole way once. * [Create and revoke an evaluation key](https://docs.leapter.com/rc/user-guide/evaluation-keys.md): give a system access. * [Find a run and read usage](https://docs.leapter.com/rc/user-guide/runs-and-usage.md): see what your callers ran. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.