> ## Documentation Index
> Fetch the complete documentation index at: https://docs.specific.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Deployments

> From source code to a running production environment in one command.

`specific deploy` takes your project from local development to a fully running production environment: provisioning infrastructure, building your code, and rolling out services with a single command.

```bash theme={null}
specific deploy
```

## First deploy

The first `specific deploy` walks you through a short setup:

1. **Login** - your browser opens to authenticate with Specific Cloud. The session is saved for future deploys.
2. **Project selection** - choose an existing project or create a new one. The project is saved to `.specific/project.json` so subsequent deploys skip this step.
3. **Deploy** - your project is built, infrastructure is provisioned, and services go live.

After that, deploys are a single command with no prompts (unless new secrets or config values need to be set).

## The pipeline

<Steps>
  <Step title="Authentication">
    Verifies you are logged in to Specific Cloud. If not, your browser opens for login.
  </Step>

  <Step title="Local build testing">
    Runs your build commands locally to catch errors before deploying, giving fast feedback without waiting for a cloud build.
  </Step>

  <Step title="Upload">
    Your project code is uploaded to Specific Cloud.
  </Step>

  <Step title="Cloud builds">
    Your code is built in the cloud based on the [`build` blocks](/guides/builds) in `specific.hcl`. Multiple builds run in parallel, and dependencies are cached for faster rebuilds.
  </Step>

  <Step title="Secrets and config">
    If any [secrets or config values](/guides/secrets-and-config) are missing for the target environment, you are prompted to enter them. You can enter values while builds are still running.
  </Step>

  <Step title="Resource provisioning">
    Databases, object storage, Redis, sync engines, and Temporal namespaces are provisioned as needed. Resources are created once and reused across deploys.
  </Step>

  <Step title="Service rollout">
    Services are rolled out with zero downtime: new instances must pass their [health checks](/guides/services#health-checks) before receiving traffic. [Deploy hooks](/guides/services#deploy-hooks) run at this stage: `pre_deploy` before the service starts (a failed hook aborts the deployment), `post_deploy` after it's live. [Reshape migrations](/guides/reshape) are started before the rollout and completed after it succeeds.
  </Step>

  <Step title="Active">
    The deployment is live. Public URLs for your services are displayed in the terminal.
  </Step>
</Steps>

<Note>
  If any step fails, the deployment is aborted and the error is shown in the terminal. Fix the issue and run `specific deploy` again.
</Note>

## Public URLs

Services with `endpoint { public = true }` get a public HTTPS URL on a managed `*.spcf.app` domain, shown in the terminal when the deploy completes. TLS is handled automatically. Services without a public endpoint are only reachable internally by other services.

To serve a service from a domain you own, see [Custom domains](/guides/domains).

## Environments

A project can have multiple environments (for example, `production` and `staging`), each with its own resources, secrets, and config. Target one with `specific deploy --environment <name>`, and list them with `specific status`. [Preview environments](/guides/previews) are ephemeral environments created per pull request or with `specific deploy --preview`.

## Managing production

Once deployed, the [dashboard](/concepts/dashboard) is your window into the project: logs and metrics, deployment history, database management, secrets, scaling, custom domains, and more. To deploy automatically on every push, connect your GitHub repository in the dashboard's settings.