# d1-manager: a web console and API for Cloudflare D1

> D1 Manager is a SvelteKit application that gives Cloudflare D1 a web interface and an HTTP API: browse tables, read schemas, run SQL, edit records and translate natural language into SQL with an AI model. You deploy your own fork to Cloudflare Pages, bind databases through DB_ environment variables, and put the whole thing behind Cloudflare Access.

**JacobLinCool/d1-manager** — D1 Manager is a web UI and API for Cloudflare D1, a serverless SQL database. It provides a web interface for managing databases, tables, and records, as well as an AI assistant to help you write query in natural language.

- Repository: https://github.com/JacobLinCool/d1-manager
- Website: https://d1-manager.pages.dev
- Stars: 651 · Forks: 342
- Language: Svelte
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/jacoblincool-d1-manager

## A console for a database that lives at the edge

D1 Manager is a web UI and API for Cloudflare D1, which the project description calls a serverless SQL database. The stated goal is to simplify database management so users can focus on their data.

The problem it addresses is specific. D1 is a database designed to be bound to a Cloudflare Worker or Pages project, not a server you sit in front of. There is no psql prompt on the edge. If you want to look at what your application has actually written, or fix a row by hand, or check a schema, the options are the Cloudflare dashboard, the wrangler command line, or building something like this yourself. D1 Manager is that something, packaged as an open source project.

The feature list is a checklist of a database console. Multiple D1 databases. List all tables in a database. Show table schema. Run SQL queries. Run Semantic Queries using an OpenAI API or a Cloudflare AI Worker. Edit table data through the user interface. I18n support for English, Chinese, Spanish and Japanese. And API support, with the details in the routes under src/routes/api.

The audience is developers on Cloudflare who want a browser-based view of their D1 data, and, thanks to the API routes, teams that want to script against the same operations. The primary language is Svelte, the licence is MIT, and the running instance linked from the README is hosted on Cloudflare Pages at d1-manager.pages.dev.

## Deployment is fork, configure, and put your own access policy in front

There is no package to install and no binary to run. The setup section describes a four-step procedure that ends with a deployment of your own fork.

Step one is to fork the repository. Step two is to set up a Cloudflare Pages project with the forked repo, and here the specifics matter. The framework preset is SveltKit, as the README writes it, the build command is npm run build, and the build output directory is .svelte-kit/cloudflare:

```bash
npm run build
.svelte-kit/cloudflare
```

Step three is to use Cloudflare Access to protect the site, and this step carries the most important warning in the whole README. The default access rules only restrict access to preview pages, so you must make sure to add other urls you want protected. In other words, deploying this without thinking about the Access policy publishes a database console, and the default configuration only closes off part of the surface.

Step four is to bind databases to DB_ environment variables, which is the subject of the next section.

For a team, this deployment model is the main decision. You are running someone else's code with direct bindings to your production databases, on a public URL, protected by a policy you have to write yourself. The MIT licence and the fact that it is a fork you control are what make that acceptable, and they are also what make it your problem when something goes wrong.

## DB_ prefixed bindings decide what the console can see

Databases reach the manager through environment variable bindings, and the naming convention is the whole interface.

You can bind multiple databases to the manager, and the example in the README shows the mapping. A binding named DB appears in the interface as default, and a binding named DB_test appears as test. The prefix is the marker that identifies a binding as a database, and the remainder is the label the user sees.

That is a small design decision with real consequences, because the label is what a person picks from a dropdown. If your production database is bound as DB_prod, the console will show a database called prod, and anyone who gets past the Access policy can query it. The prefix convention also means a binding named something else entirely will not be picked up, which is a useful safety property if you bind other resources to the same project.

There is one display option in the same family. SHOW_INTERNAL_TABLES shows internal tables in the UI, with the prefixes written as splite_* and d1_* in the README, so the internal tables of the database engine are hidden by default and visible on request. Note the spelling of that first prefix as the project writes it, since it does not match what you might expect from the engine's own naming.

The environment variable approach is the only configuration the README describes. There is no configuration file in the repository listing, so the settings live entirely in the Pages project settings.

## Semantic Query turns a sentence into SQL

The feature that distinguishes this console from a plain SQL editor is semantic query, a natural language front end to the database. The README shows a demo recording of it, and the screenshots include one for the semantic query screen.

There are two provider paths, and the choice is made with environment variables.

The OpenAI path uses three variables. OPENAI_API_KEY is the API key. OPENAI_API_URL may be used with Cloudflare AI Gateway to proxy requests to the OpenAI API, which is how you would route the traffic through your own gateway. OPENAI_MODEL selects the model, defaulting to gpt-4.1-mini.

The Cloudflare AI Worker path uses two. AI is a binding to a Cloudflare AI Worker, and CFAI_MODEL selects the model, defaulting to @cf/mistral/mistral-7b-instruct-v0.1.

The README also states plainly which model the screenshot uses, that Semantic Query uses OpenAI GPT-4.1 Mini to translate natural language queries into SQL.

Two observations for anyone deploying this. The second path keeps the model inside the Cloudflare ecosystem rather than sending questions to an external API, which is the answer to a data residency question. And either way, the model is being asked to write SQL against your real schema, so the prompt and the response both involve your table structure. That is a decision to make deliberately rather than by leaving the defaults in place.

## Table browsing, record editing and the API routes

The rest of the console is the part you would expect from a database admin tool, and the screenshots confirm the shape of it. There are screens for the tables list, running a query, browsing table data, and adding a record, and a separate screen for the semantic query.

Listing all tables in a database and showing a table schema are separate operations in the feature list, which suggests the schema view is not a footnote on the table list but its own view, since a generated schema is usually what you want to read before writing a query by hand.

Editing table data through the interface covers the case where a row needs to change and a deployment is not an option. Adding a record is shown in the screenshots, which means the interface can write, not just read, and that matters for the security discussion in the next section.

The API support is what turns the tool from a console into a platform component. The README points to the routes under src/routes/api for the details, and the top-level description says the API is for performing operations programmatically. The same operations that a person performs in the interface, listing tables, showing schemas, running queries and editing rows, are therefore reachable over HTTP, which is what you need if a script, a CI job or another service has to touch the database.

The one thing the README does not document is the authentication model for those API routes. The protection described is Cloudflare Access in front of the site, so the API inherits whatever that policy allows, and there is no separate token scheme described.

## A SvelteKit project with the usual guard rails wired up

The repository is a pnpm based SvelteKit project, and the scripts in package.json describe the whole workflow.

```bash
"dev": "vite dev",
"build": "vite build",
"test": "playwright test",
"test:unit": "vitest",
"check": "svelte-kit sync && svelte-check --tsconfig ./tsconfig.json",
"lint": "prettier --ignore-path .gitignore --check . && eslint .",
"upload": "pnpm build && wrangler pages deploy --project-name d1-manager .svelte-kit/cloudflare",
"tail": "wrangler pages deployment tail --project-name d1-manager"
```

That gives you two test tiers, Playwright for the end to end tests and Vitest for unit tests, with the Playwright config at playwright.config.ts and a tests/ directory. Type checking goes through svelte-check with the tsconfig.json, and linting runs Prettier and ESLint together, with eslint.config.js and .prettierrc.yml at the root.

Two tooling details are worth knowing. The prepare script runs husky, and there is a .husky/ directory, so commit hooks are installed on install. And the upload and tail scripts drive wrangler, which means the deploy path is the same command line tool Cloudflare provides rather than a custom deployment script.

Internationalisation is handled through a separate toolchain. The locales/ directory holds the translation files, project.inlang/ holds the inlang configuration, and the README links an Online Editor hosted by Fink inlang for contributors who want to add a language. The four languages named are English, Chinese, Spanish and Japanese.

The UI stack is SvelteKit with the Cloudflare adapter, Tailwind CSS, daisyUI for components, and Iconify for icons. Release notes are handled with changesets, with a .changeset/ directory and the changesets CLI in the dev dependencies.

## The security boundary is the part you own

Everything about this project is in the open, and the parts that matter for safety are the parts the README flags as your responsibility.

The first is access control. The console can read schemas, run arbitrary SQL and write records, and it is exposed to the network. The README's instruction to use Cloudflare Access to protect the site comes with the warning that the default access rules only restrict access to preview pages, so the default configuration is not sufficient and the other urls you want protected have to be added explicitly. Cloudflare Access is doing the authentication, and Access policies are what stand between a stranger and your production database.

The second is binding. A DB_ binding is a live handle to a database, and the manager will run whatever SQL the person or the API client sends. The binding names are visible in the interface, so a naming convention that puts production and test side by side as default and test is not a problem until it is.

The third is the AI path, discussed earlier, where a model is asked to translate natural language into SQL against your schema.

On the state of the project, the facts are modest. The package version in package.json is 0.0.0, which is a placeholder rather than a release number, and the repository has no GitHub releases, so the deployment is a fork of the main branch rather than a versioned artefact. The last push to the repository was on 2026-10-22, so the code moves quickly. The licence is MIT, which means you can read the source of the thing that has access to your data, and the practical advice for anyone deploying it is to read that source before pointing it at a database you care about.

## Conclusion

d1-manager suits developers who have a D1 database attached to a Cloudflare Pages project and want a readable console for it, including a semantic query path for people who would rather describe what they want than write SQL. It does not suit a team that wants a managed product, since there is no hosted service to sign up for and the deployment model is fork, configure and deploy yourself, and it does not suit anyone who will expose the instance without a proper access policy. Check three things before you deploy: that your Cloudflare Access rules actually cover the paths you care about, since the README warns the default rules only restrict preview pages, that your database binding variable names map to the names you want in the interface, and that you have decided which model provider handles semantic queries, since the OpenAI path sends your schema and question to a third-party API. The last push to the repository was on 2026-10-22 and there are no GitHub releases.

## FAQ

### How do I deploy d1-manager?

Fork the repository, create a Cloudflare Pages project with the SveltKit preset, set the build command to npm run build and the build output directory to .svelte-kit/cloudflare, protect it with Cloudflare Access, then bind databases to DB_ environment variables.

### How do I connect a Cloudflare D1 database to d1-manager?

Bind it to a DB_ prefixed environment variable. The README's example binds DB, which appears as default in the interface, and DB_test, which appears as test, so the binding name decides the label the user sees.

### What does Semantic Query need to work?

For the OpenAI path it needs OPENAI_API_KEY, optionally OPENAI_API_URL to proxy through Cloudflare AI Gateway, and OPENAI_MODEL which defaults to gpt-4.1-mini. For the Cloudflare AI Worker path it needs an AI binding and CFAI_MODEL, defaulting to @cf/mistral/mistral-7b-instruct-v0.1.

### Is d1-manager safe to expose on the internet?

The README instructs you to use Cloudflare Access to protect the site and warns that the default access rules only restrict access to preview pages, so you must add the other urls you want protected. The console can run SQL and write records, so the access policy is the security boundary.

### How do I run the tests for d1-manager?

The package scripts use Playwright for the end to end tests, with the command playwright test, and Vitest for unit tests. Type checking runs svelte-check against the tsconfig.json, and linting runs Prettier and ESLint.

## Sources

- [Issues](https://github.com/JacobLinCool/d1-manager/issues)
- [JacobLinCool/d1-manager on GitHub](https://github.com/JacobLinCool/d1-manager)
- [License: MIT](https://github.com/JacobLinCool/d1-manager/blob/main/LICENSE)
- [Project website](https://d1-manager.pages.dev)
- [README](https://github.com/JacobLinCool/d1-manager/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jacoblincool-d1-manager