drift slice

Create, resize and operate the slice itself: the environment your project lives in.

What a slice is doing right now

The runtime admits work against a per-function memory pool, learns each pool's booking from the peak memory of every invocation it reaps, and stops an invocation that overruns rather than letting it take the slice down with it. drift slice info is the read on all of that:

$ drift slice info
my-slice

  compute        340MB of 512MB held (66%)
  in flight      2 invocation(s)
  warm workers   3 parked

  pools
    post:webhook                 12MB of 32MB held (37%)
    get:report                   190MB of 256MB held (74%)

A limit reported as unbounded means no ceiling could be read, not a generous one. Read this when something is slow; drift file benchmark answers the other question, what a function has actually cost and what it should book.

Changing a slice's shape

drift slice create and drift slice resize own a slice's shape, and they are the only things that write one. Every resource, every limit and the price of the lot are chosen there. A Driftfile declares what runs on a slice; it does not say what the slice is.

The default path for either is a form that recomputes the total as you type. It is a tree you move around in: arrows move, space folds a section, and typing edits the row you are on directly, a function's row is its route, so you highlight it and start spelling. ^D removes an item, Esc discards a half-typed one. Everything is collapsed to begin with, so the parts you never open stay at the platform's own defaults. The price comes from the server on every edit; the CLI ships no rates of its own, so the figure above Apply is the figure you are charged.

For a resize, that gives one path for a change in any direction, up or down:

drift slice resize            # the active slice
drift slice resize my-slice   # or a named one

drift slice shrink still works and resizes the active slice. It says once that it is deprecated: a reduction is chosen and confirmed where the shape lives, so there is no longer a destructive spelling of resize for it to be.

A resize is refused twice on purpose, and each refusal is answered on the form itself rather than by starting again. Booking memory per function for the first time reprices the whole slice, so it is refused until you agree to the new figure: the button changes to say what it now costs, and pressing it again is the agreement. A change that takes something away is refused until you confirm it, after the form has listed what would go.

Resizing without a terminal

The form needs a TTY, which used to mean no script, CI job or SDK consumer could resize a slice at all. --dump and --config answer the platform's same two questions from flags instead of from the form:

drift slice resize my-slice --dump > shape.json     # what it is now
$EDITOR shape.json                                  # what it should be
drift slice resize my-slice --config shape.json \
    --acknowledge-monthly-cents 1200                # yes, at that price

--dump writes the slice's current shape as JSON to stdout; edit it and feed it back with --config. A resize that changes what the slice costs is refused until --acknowledge-monthly-cents sends back the new figure in cents; one that takes something away is refused until --confirm <slice-name> names the slice. Each refusal states the figure or lists what would be lost, the same information the form's own row shows, so a second attempt can answer it exactly. drift slice create has no such flag pair: a slice that does not exist yet has nothing to dump, and --free is its own no-form path for creating one.

Linking

Let the active slice call another slice you own, without the call leaving Drift (e.g. an app calling your own observability slice). From code, reach the linked slice with drift.Slice("<name>").

Site gate

Guard the slice's Canvas site with HTTP Basic auth: anyone without the credential gets a 401 and never reaches the site. This gates the site itself, not the API; drift atomic auth guards a function separately.

set replaces the whole credential set rather than adding to it, so naming one user leaves exactly that user able to get in, which is what makes removing someone a single predictable command. Passwords are read from the terminal, or from stdin in order with --password-stdin (one line per --user); there is no --password flag, since the credential would land in ps output and shell history. disable asks for confirmation, being the one direction that exposes something.

Snapshots

Portable backups of a whole slice: source code, data, secrets, and sites. Your source comes back as you wrote it, with every Drift-generated wrapper stripped out; the only Drift files in the archive are two manifests that sit beside the tree rather than inside it.

Encryption, and your own passphrase

Snapshots are stored encrypted. Each archive gets a key of its own, and that key is held wrapped by the platform, so the object store holds ciphertext and a restore can run without you present. The file you download is a plain .tar.gz, and it holds this slice's secrets in cleartext. The CLI writes it 0600 and says so every time.

--passphrase changes who can open the archive. Drift prompts for one, derives the archive's key from it, and uses that instead of the platform's key. Downloading or restoring that snapshot asks for the same passphrase.

--passphrase-stdin reads the passphrase from stdin instead of prompting, on create, download and restore, for scripts. There is deliberately no flag that takes the passphrase as a value: it would land in ps and in your shell history, and unlike a password this one can never be reset.

What the passphrase protects is the archive at rest, in the object store and on whatever holds a copy of it. Drift builds the archive from your slice, so the contents pass through the platform when you create one and again when you open one. Encrypting in the CLI instead would change that, at the cost of an archive an older CLI could not read.

Custom domains

Point your own hostname at a slice; Drift verifies ownership and issues the TLS certificate. See Getting started for the full flow.

--wildcard is routing only. Every subdomain reaches the slice, and each one gets its own certificate issued on demand, and there is no wildcard certificate. Telling alice.example.com from bob.example.com is your app's job; the platform hands both to the same slice.

Hostnames can also be declared in the Driftfile under domains:, which the deploy reconciles.