> ## Documentation Index > Fetch the complete documentation index at: https://docs.vizra.ai/llms.txt > Use this file to discover all available pages before exploring further. # Connect a Project > Create a project, mint a key, add two lines to .env — and your next run appears. A **project** groups the eval suites of one codebase. An **API key** belongs to exactly one project, and runs reported with it are filed there. ## 1. Create the project From the sidebar's `+`, or **Projects → New project**. Name it after the application, not the agent — one Laravel app with six agents is one project. ## 2. Create a key New projects show their connection steps immediately, including a key created for you: A new project's connect panel: composer require, the two env lines, and the run command The full key is shown **once**, when it is created. Only a sha256 hash is stored, so we genuinely cannot show it to you again — not "won't". If you lose it, create another. ## 3. Add it to your environment ```bash .env theme={null} VIZRA_CLOUD_KEY=vz_your_key_here ``` That is the whole configuration on the hosted service. `VIZRA_CLOUD_ENDPOINT` defaults to `https://vizra.ai/api/v1/runs` and only needs setting if you are pointing at a self-hosted instance. ## 4. Run your evals ```bash Terminal theme={null} ./vendor/bin/pest --evals # or php artisan evals:run ``` The run finishes, reports, and appears in the project. Nothing else changes — the same run is still recorded locally, and the gate still decides pass or fail exactly as before. See [what gets reported](/cloud/reporting). ## Managing keys The API keys tab, showing masked keys with their project, last use, expiry and rotate/revoke actions Each key shows its project, when it was created, whether it has **ever been used**, and its expiry. "Never used" is usually the answer to "why aren't my runs showing up". ### Expiry Choose **Never**, **30 days**, **90 days** or **a year** when creating a key. An expired key stops being accepted at ingest; runs still record locally. ### Rotate, don't revoke **Rotate** creates a replacement and keeps the old key working for **7 days**, so you can deploy the new one everywhere before the old one stops. Rotation never *extends* an expiry that was already sooner than the grace period. **Revoke** stops the key immediately. Worth knowing what that looks like from the other side: a rejected upload never fails a build, so anything still using the key goes quiet rather than erroring — you notice by the missing runs, not by a red pipeline. Give CI its own key, named for the pipeline. When you rotate it you know exactly what has to be redeployed, and revoking it doesn't stop anyone's laptop reporting.