Skip to main content
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. 
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

1

Authentication

Verifies you are logged in to Specific Cloud. If not, your browser opens for login.
2

Local build testing

Runs your build commands locally to catch errors before deploying, giving fast feedback without waiting for a cloud build.
3

Upload

Your project code is uploaded to Specific Cloud.
4

Cloud builds

Your code is built in the cloud based on the build blocks in specific.hcl. Multiple builds run in parallel, and dependencies are cached for faster rebuilds.
5

Secrets and config

If any secrets or config values are missing for the target environment, you are prompted to enter them. You can enter values while builds are still running.
6

Resource provisioning

Databases, object storage, Redis, sync engines, and Temporal namespaces are provisioned as needed. Resources are created once and reused across deploys.
7

Service rollout

Services are rolled out with zero downtime: new instances must pass their health checks before receiving traffic. 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 are started before the rollout and completed after it succeeds.
8

Active

The deployment is live. Public URLs for your services are displayed in the terminal.
If any step fails, the deployment is aborted and the error is shown in the terminal. Fix the issue and run specific deploy again.

​
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.

​
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 are ephemeral environments created per pull request or with specific deploy --preview.

​
Managing production

Once deployed, the 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.