baseclfdocs

Guide · 10 minutes

Go from an empty Cloudflare account to your first protected query.

One command provisions a database, a bucket, and a Worker into your own account, then waits until the address answers. The commands on this page are the shipped ones, not placeholders.

Two one-time things first

Sign in with npx baseclf login (the credential stays on your machine; BaseCLF has no OAuth app of its own), and switch on R2 in the Cloudflare dashboard. R2 is off on a new account, and provisioning stops at that step until it is enabled.

1. Create a deployment

Terminal
npx baseclf login
npx create-baseclf

It asks two questions, each with a default: a project name, which names the database, bucket, and Worker on your account, and your frontend origin, without which a browser on another origin cannot call the API. The signing secret is generated, never asked for.

2. Expose a table

A fresh deployment exposes nothing. A table without a policy document is a table nobody can reach, so there is no state where you forgot to turn security on. Save this as posts.json:

posts.json · Policy document
{
  "table": "posts",
  "enabled": true,
  "policies": [
    {
      "name": "read_published",
      "for": "select",
      "to": ["anon"],
      "using": { "status": { "_eq": "published" } },
      "columns": ["id", "title", "body", "status", "author_id", "created_at"]
    }
  ]
}

This grants one thing to one role: a caller who is not signed in may read published rows. Drafts are never granted, which is different from being excluded by a rule.

3. Apply and verify

Terminal
npx baseclf policy apply posts.json --project your-project

curl https://your-project.your-subdomain.workers.dev/rest/v1/posts

HTTP/2 200
[{ "id": "p_1", "title": "Published by u_1", "status": "published" }]

Two of the four seeded rows come back with no filter in the URL: the drafts are outside what this caller was granted. A policy change lands within about thirty seconds, so a request sent the instant apply returns can still see the previous answer.

Direct database access, meaning wrangler d1 execute or the D1 console, bypasses the policy engine by design. Application traffic belongs on the API. Admin tokens belong in local tooling, never in a browser bundle.