Configuration

Look up an environment variable or a graft.config.ts export here. Graft reads .env from the current folder or any folder above it.

Required: none

A static project needs no environment at all. graft init scaffolds the static index, graft compile writes .graft/index.db, and your app reads it embedded. Everything below is for a capability you opt into.

Postgres

Required once graft.config.ts sets export const index = "postgres", which is what operational data, typed functions, and copy-on-write branches need.

Identity and policy

Serve

Studio

graft serve --studio reads these. Set GRAFT_GITHUB_REPO to make saves land on GitHub instead of the content directory. See Host Studio for your team for the full setup.

Assets (S3-compatible)

Neon branching

graft.config.ts exports

The config is TypeScript you own, loaded at runtime. Only collections is required.

content

Choose where your content is the real thing, the version everything else is built from.

• "git" keeps it in the MDX files under contentDir. Studio saves files on your computer, or commits through GitHub when hosted. graft compile builds the index from the files.
• "database" keeps it in Postgres. Studio and agents save drafts there, and publishing puts a change on the live site straight away, with no rebuild. graft compile builds the index from what is published, not from the files. A hosted Studio needs no GitHub setup at all.

export const content = { source: "database" };

The database source needs the Postgres engine, so it can't be combined with index = "static". To move an existing project, set the export and run graft content import, which loads your files into the database. It brings in documents that have nothing published yet, and never overwrites one that does, so running it again is safe. Deleting a file does not delete its document: delete it in Studio instead. Content in the database covers pulling, pushing and keeping a copy in git.

export const content = {
  source: "git",
  review: { collections: ["legal"], overLines: 100 },
};

In a database-sourced project these refuse with CONTENT_SOURCE_MISMATCH, because they work on files: reverting to a commit in Studio, graft merge, and content migrations.

mdxTrust

"restricted" refuses {…} expressions, import, export and spread attributes in authored bodies. graft compile checks every document and reports all offenders at once, so the refusal happens at build time rather than per-request.

Set "full" only when every author of the repository has commit access. Rendering evaluates MDX as JavaScript on the server, so on a Studio hosted for writers, "can author a page" would otherwise mean "can execute code on the render host".

export const mdxTrust = "full";

MdxBody has its own trust prop with the same default, and the two have to agree: set mdxTrust here and pass trust="full" at the render site. Compile says so in the error when it refuses a document.

Operator vs runtime

Keep two URLs in production:

• Operator. Compiles, migrates, merges, and approves from CI or your machine.
• Runtime. Serves the deployment on DATABASE_URL after graft harden.

On Vercel embedded deploys, run compile in the build step with the operator URL, then serve the app with the runtime URL. See Deploy.