> ## Documentation Index > Fetch the complete documentation index at: https://docs.baseten.co/llms.txt > Use this file to discover all available pages before exploring further. # Concepts > Deployments, environments, resources, autoscaling, and CI/CD on Baseten. A [deployment](/deployment/deployments) is a version of your model running on Baseten with its own API endpoint. This page explains how deployments, environments, resources, autoscaling, and CI/CD fit together. To create, promote, scale, or deactivate a deployment, see [Manage deployments](/deployment/manage/overview). ## Deployments A deployment runs one version of your model on a selected instance type. Each `baseten model push` creates a deployment. Multiple deployments of the same model can run at once, allowing you to test a new version without changing production traffic. Deactivate a deployment to stop serving and billing, or delete it when you no longer need it. For rapid iteration, use `baseten model push --watch` to create a **development deployment**, a mutable instance that live-reloads as you edit your model code. You can promote a development deployment directly to an environment, which creates a published deployment. Baseten dashboard showing multiple model deployments ### Model lab deployments For deployment restrictions on models distributed by model labs, see [Customer availability and artifact access](/labs/platform#customer-availability-and-artifact-access). ## Environments [Environments](/deployment/environments) provide stable endpoints that persist as you release new deployments. A typical setup uses one environment for testing and another for production traffic. Each environment has its own endpoint, autoscaling settings, and metrics. Promoting a deployment moves the environment's traffic to that version without changing the URL called by your application. Deployment environments with development and production endpoints ## Resources Every deployment runs on an [instance type](/deployment/resources) that defines its GPU, CPU, and memory. Set the instance type in `config.yaml`, or change it for a published deployment in the Baseten dashboard. Select an instance based on the model's memory requirements, latency target, and expected traffic. Resource configuration showing GPU instance type selection ## Autoscaling [Autoscaling](/deployment/autoscaling/overview) adjusts the number of replicas as request load changes. Configure the minimum and maximum replicas, concurrency target, and scale-down delay. A deployment can scale to zero when idle, so a synchronous request can wait for a replica to start. See [Cold starts](/deployment/autoscaling/cold-starts) for ways to reduce startup time. Autoscaling configuration with replica count and concurrency settings For the mechanics of how the autoscaler tracks in-flight requests and adjusts replicas, see [How Baseten works](/concepts/howbasetenworks#autoscaling). For engine-specific autoscaling settings (BEI and Engine-Builder-LLM), see [Autoscaling engines](/engines/performance-concepts/autoscaling-engines). ## Request lifecycle Before your model code runs, each request passes through authentication, routing, and replica selection. See [Request lifecycle](/deployment/autoscaling/request-lifecycle) to understand queuing, load shedding, timeouts, and HTTP status codes. ## CI/CD Use the [Truss Push GitHub Action](/deployment/ci-cd) to deploy a model from a Git repository, validate it with a predict request, and optionally promote it to production. Configure the workflow to run for selected branches, pushes, or pull requests.