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

# How Specific works

> The mental model: one config file that runs your whole system, locally and in production.

Specific is infrastructure-as-code designed for coding agents. Your infrastructure is defined in a single `specific.hcl` file alongside your application code: how to build, run, and deploy the full system, in both development and production.

Specific is fully generic: it works with any programming language and framework, without SDKs. All connection details reach your code through environment variables.

## One file, every environment

A typical `specific.hcl`:

```hcl specific.hcl theme={null}
build "app" {
  base    = "node"
  command = "npm run build"
}

service "web" {
  build = build.app
  command = "npm start"

  endpoint {
    public = true
  }

  env = {
    PORT         = port
    DATABASE_URL = postgres.main.url
  }

  dev {
    command = "npm run dev"
  }

  pre_deploy {
    command = "npm run db:migrate"
  }
}

postgres "main" {}
```

The same file drives every environment your project runs in:

* **[`specific dev`](/concepts/local-development)** runs everything locally (Postgres, services, sync engines) with connection details injected automatically. No `.env` files.
* **[`specific deploy`](/concepts/deployments)** builds the code, provisions managed infrastructure, and rolls out services to Specific Cloud. A project can have multiple deployed environments (production, staging, [previews](/guides/previews)), all defined by the same file.

References like `postgres.main.url` resolve to the right value in each environment: a local database during development, a managed one per deployed environment.

## Building blocks

| Block                                             | What it defines                                                                                                                     |
| ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| [`build`](/guides/builds)                         | How to produce artifacts: managed base environments or custom Dockerfiles.                                                          |
| [`service`](/guides/services)                     | Long-running processes: web apps, APIs, workers.                                                                                    |
| [`cron`](/guides/crons)                           | Scheduled jobs with per-run logs and metrics.                                                                                       |
| [`postgres`](/guides/postgres)                    | Managed PostgreSQL databases, with optional [Reshape](/guides/reshape) zero-downtime migrations and [real-time sync](/guides/sync). |
| [`storage`](/guides/storage)                      | S3-compatible object storage.                                                                                                       |
| [`redis`](/guides/redis)                          | Redis-compatible caches (Valkey).                                                                                                   |
| [`temporal`](/guides/temporal)                    | Managed Temporal workflow engines for durable workflows.                                                                            |
| [`secret` / `config`](/guides/secrets-and-config) | Parameterized sensitive and environment-specific values.                                                                            |
| `volume`                                          | [Persistent directories](/guides/volumes) inside services.                                                                          |
| `environment`                                     | Per-environment [config overrides](/guides/secrets-and-config#environment-overrides).                                               |

## The workflow

Whether you're a human or a coding agent, working with Specific follows the same loop:

1. Create or edit `specific.hcl`.
2. Run `specific check` to validate the configuration - always, after every change.
3. Run `specific dev` to run the system locally, and `specific exec <service> -- <command>` for one-off commands like migrations and seeding.
4. Run `specific deploy` to ship it.

After deploying, manage the project from the [dashboard](https://dashboard.specific.dev): logs and metrics, scaling, database browsing, secrets, and custom domains.

## Designed for coding agents

Your coding agent writes and maintains `specific.hcl`: you describe what you want to build, and the agent defines the infrastructure alongside the code. The CLI ships its own LLM-optimized documentation (`specific docs`), and `specific init` wires it into your agent's context. See [Coding agents](/coding-agents).