# Key ideas The words the console and these guides use, in plain language. Each entry links to the guide that goes deeper. ## Your app ### App An app is one website, API or service you run on Nimbus Land, built from one repository or folder. Its name gives it its address, `https://.nimbusapps.ca`, and app names are unique across Nimbus Land. Each app has its own pages in the console, such as **Overview**, **Resources**, **Deployments** and **Monitoring**. See [Apps](apps.md). ### Environment Every app has a production environment: the one at its main address. You can add others to try changes before they reach production: a preview for each pull request, or one you create yourself, such as `staging`, from the **Environments** card on the **Deployments** tab. Each environment runs your code with its own secrets and its own empty copy of any managed database, so nothing it does touches production's data. See [Secret environment variables](secret-env-vars.md#staging-and-preview-environments). ### Deploy plan Before anything builds, Nimbus Land reads your code and tells you what will run and whether the deploy will work. The plan gives one verdict: **Ready**, **Check this** (notes that never block) or **Blocked** (a certain failure, refused before anything is created). The deploy wizard, `nimbus detect` and `nimbus deploy` all use it. See [The deploy plan](apps.md#the-deploy-plan). ### Build A build turns your source code into something ready to run: Nimbus Land installs your dependencies, compiles what needs compiling and packages the result. A build starts each time you deploy, whether from the console, with `nimbus deploy` or by pushing to GitHub. Its output, the build log, is on the build's page in the console, or run `nimbus logs --build`. See [How your stack is chosen](apps.md#how-your-stack-is-chosen). ### Release A release is one version of your app going live: a build together with the app's settings at that moment. Each deploy creates a release, and so does a change that restarts the app, such as saving a secret. The **Deployments** tab lists releases and builds newest first. To go back, choose **Deploy** on the **Overview** and pick an earlier version: it goes live again from its existing build, without rebuilding. ## Running it ### Instance An instance is one running copy of your app. Web traffic is shared between instances, so more instances can handle more visitors. Set how many run, and the **Instance size** of each, on the **Resources** tab: **Web App**, then **Edit**. The **Monitoring** tab lists each one under **Instances**. ### Release command A release command runs before each new release goes live, inside your built app with the same settings. Database migrations belong here, such as `php artisan migrate --force` or `python manage.py migrate`. The deploy wizard suggests one for common frameworks, and you can change it later on the **Deployments** tab, in the **On every deploy** row. If it fails, the release fails and the console shows its exit code. See [Release command](apps.md#release-command). ### Background worker A background worker runs alongside your web app without serving web pages: a queue worker or a scheduler, for example. It runs from the same build, with the same environment variables. Add one with **Add worker** in **Background workers** on the **Resources** tab, giving it a **Name**, a **Start command** and a number of **Instances**. See [Commands, workers and one-off runs](apps.md#commands-workers-and-one-off-runs). ### One-off command A one-off command runs once against your deployed app and then ends, for a migration, a data fix or a console session. Use `nimbus run -- `, or **Run a command** on the **Monitoring** tab. It runs inside your built app with the app's environment variables, and it doesn't count as an instance. ## What it uses ### Environment variable Environment variables hold settings your app reads when it runs, such as `API_URL` or `STRIPE_KEY`. Set them on the **Resources** tab under **Environment Variables**, or with `nimbus env set`. A plain variable's value stays visible, and plain variables also reach the build. A secret variable is write-only: your app reads it like any other, but nobody can read it back, and it never reaches a build unless the deploy passes it. Use secrets for passwords, tokens and API keys. See [Secret environment variables](secret-env-vars.md) and [Environment variables](apps.md#environment-variables). ### Dependency A dependency is something your app relies on: a managed database, a bucket, a volume, AI access or another of your apps. They're listed on the **Resources** tab, where **Add dependency** adds one. Adding a dependency gives your app its connection details as environment variables, such as `DATABASE_URL`, and Nimbus Land keeps those values current. See [App dependencies](dependencies.md). ### Volume A volume is disk storage that keeps its files across restarts and deploys. Anything else your app writes to its own disk is lost when a new release starts. Add one with **Add dependency → Volume** on the **Resources** tab, mounted at a folder such as `/data`. Volumes are mounted in production only. See [Volumes](volumes.md).