drift Docs
Start
What is Drift?
The tour, if you are new here.
Use cases
Whether Drift does your thing.
Getting started
Nothing to deployed, in one command.
Architecture
How a slice is put together.
What it costs
The free grant, four unit prices, two rules.
Build
Canvas
Static sites, same origin as your API.
Tools
Operate
Auth
Route gates, API keys and your account.
Security
Boundaries, sandboxing and hardening.
Troubleshooting
Error codes
What went wrong, and what to do about it.
Legal
Acceptable use
What a slice may not be used for.
Data processing
The DPA, and every sub-processor.

Deploying and validating

The loop around a Driftfile: check it offline, fold your build into the deploy, then apply it and read whatever it says back.

Working on a Driftfile

drift file answers questions about a manifest without touching the network. It's the fast loop: fix, lint, repeat, and only then deploy.

Command What it answers
drift file lintIs this file valid? Validates exactly as a deploy would, and exits non-zero, so it can gate CI.
drift file explain --env stagingWhat does staging resolve to once the overlay and the inherited defaults are applied?
drift file fmt --writeCanonical key order and indentation. Comments and short forms survive.
drift file newA starter Driftfile in this directory.

explain prints names of secrets, never values, because some are resolved $ENVREFs by that point, and a command whose job is to print the resolved shape must not put a live credential on a terminal or into a CI log. It prints no price either: a Driftfile doesn't set a slice's shape, so there's nothing here to cost. That lives on the form drift slice resize draws.

Hooks: pre/post-deploy commands

Fold the build-and-verify ceremony into the deploy so it stays one command. Commands run locally, in order, through the shell from the project root, with the deploy environment exported; a non-zero exit aborts.

Driftfile
hooks:
    pre_deploy:                       # before anything ships, typically a build
      - npm --prefix web run build
    post_deploy:                      # after the slice is live, typically a smoke test
      - ./scripts/smoke.sh

Hooks are lifecycle commands, not a pipeline engine: no test stages, matrices, parallelism, or remote execution. A failed post_deploy leaves the slice live but exits non-zero so you and CI see it.

Deploy & validation

The CLI validates the whole Driftfile before any network call. Malformed values, missing seed files, malformed JSONL, and unset secret references are reported together, so you fix everything in one pass. On a valid file, drift file apply checks that the slice already holds what it names: its functions, its NoSQL collections, blob buckets and SQL databases, and the secrets its functions declare. A bare function rename is repaired for you: an idle slot the slice sold you gets renamed to match, at no change in price. Anything else missing is refused with the exact names and a pointer to drift slice resize, where they're added. Only then does it deploy.

Applying a file never prices anything. A Driftfile doesn't declare a slice's shape, so there's no shape here to quote a cost against, and no monthly figure to confirm before it ships.

drift file apply --plan, or the dedicated drift file simulate, print the same thing without shipping anything: the functions, sites, collections, buckets, databases, queues and domains the file declares, and any of those the slice doesn't yet have. Nothing is applied and no hooks run.

Reading an error

Errors are keyed by location within the document, not by line number. The file is converted to JSON before validation, which is the honest conversion but discards the YAML source positions, so what you get is a path:

at '/environments/staging': additional properties 'name' not allowed
at '/backbone/nosql/1': missing property 'size'

Read /backbone/nosql/1 as “the second entry of nosql”. Seed files are the one exception and do carry a file and line, because a JSONL seed is validated line by line: nosql "permit-types" seed: ./backbone/permit-types.jsonl:4: missing _id.

The platform owns the format, so validation needs a copy of it.

The CLI fetches the schema on first contact and caches it at ~/.drift/driftfile.schema.json. On a machine that has never run an online command there is nothing to validate against, and the CLI says so rather than passing a file it hasn't checked. Run drift account login or drift slice list once. It also means a field the platform adds is accepted as soon as the cached schema refreshes, with no CLI release.

Deploys do not change a slice's shape at all.

drift file apply fills the slots you bought; it neither creates a slice, grows one nor shrinks one, and it refuses against a slice that does not exist. Every change of shape, growing or shrinking, goes through drift slice resize instead, which opens the terminal form on what the slice currently is, so the new price is shown before it is agreed to.

Ready to ship one?

The Getting Started guide walks a Driftfile from zero to a live app, and the CLI reference covers every deploy command.