Driftfile
A Driftfile is the single source of truth for a Drift project. It declares the Atomic functions, Backbone data, and Canvas sites your app needs, plus the resource limits it runs within. You run drift project deploy from the project root, and the platform reads the Driftfile, provisions everything, and wires it together.
The file
The file is named Driftfile: capital D, no extension, just like a Makefile or Dockerfile. It lives at the project root, next to your atomic/, backbone/, and canvas/ folders. The format inside is YAML. The CLI looks for ./Driftfile where you run the deploy. There is no second config file and no lockfile; multiple environments live in this one file under environments:, not a forest of per-environment variants.
-
my-project/the project root
-
atomic/your functions
- submit.go
- validator.go
-
backbone/seeds and schemas
- permit-types.jsonlupserted by
_id
- permit-types.jsonlupserted by
-
canvas/your sites
- public/mounted at /
- reviewer/mounted at /reviewer
- Driftfilethe manifest, at the root
-
atomic/your functions
The shape of the file
- AnatomyEvery top-level key, the name rules, short forms.
- A worked exampleOne app with every section written out.
Section by section
- AtomicFunction limits, schedules, alerts and egress.
- BackboneCollections, databases, buckets, queues, secrets.
- CanvasStatic sites, and the route each mounts on.
- DomainsCustom hostnames the slice answers on.
- EnvironmentsOne project, several slices, one file.
- Deploying and validatingLint it, hook a build onto it, read its errors.
The smallest Driftfile
Every limit has a default, so the minimum that deploys something is a name and a site:
name: hello
canvas: ./canvasdrift file new writes a starter one for you, with the knobs a first deploy needs filled in and a comment on each explaining what omission means.