# Prisma Editor: a visual editor for the Prisma schema

> Prisma Editor is a Next.js application for visualising and editing a Prisma schema, pairing a Monaco based text editor with a diagram view of the data model. The interesting structural decision is that the core logic was extracted into two published npm packages, so the schema to DMMF conversion can be used on its own, and the project carries a community label rather than being a Prisma product.

**mohammed-bahumaish/prisma-editor** — Prisma Editor - A powerful tool to visualize and edit Prisma Schema.

- Repository: https://github.com/mohammed-bahumaish/prisma-editor
- Website: https://prisma-editor.bahumaish.com
- Stars: 1,033 · Forks: 84
- Language: TypeScript
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/mohammed-bahumaish-prisma-editor

## A schema file with a picture next to it

Prisma Editor is described as a powerful tool designed to visualize and edit Prisma Schema with ease, and the hosted instance is at prisma-editor.bahumaish.com.

The problem it addresses is narrow and real. A Prisma schema is a text file that describes a data model, and the text form is precise but not legible at a glance. A diagram is legible at a glance and imprecise. The editor's premise is that you should be able to see both, and that moving between them should not be a manual export and import.

The stack follows from that premise. The schema text is edited in Monaco, through @monaco-editor/react,. The diagram side is built on the DMMF, the Prisma data model format, and the data model is read through @prisma/client, @prisma/engine-core and @prisma/internals, the last of which is Prisma's own internals package rather than a third party one.

The rest of the dependency list is the usual Next.js application stack. The Radix UI primitive packages supply the interface pieces, with accessible-icon, accordion, alert-dialog, aspect-ratio, avatar, checkbox, collapsible, context-menu, dialog, dropdown-menu, hover-card, label, menubar, navigation-menu, popover, progress, radio-group, scroll-area, select, separator, slider, slot, switch and tabs, plus @headlessui/react and @hookform/resolvers. Tailwind handles the styling, with a tailwind.config.cjs in the repository.

The topics list the databases the tool is aimed at, PostgreSQL, MySQL, MongoDB and CockroachDB, alongside prisma, prisma-schema, schema and erdiagram, and the primary language is TypeScript with the application in an app/ directory and the supporting code in src/.

## The two npm packages that hold the real logic

The updates section of the README records a refactoring that matters more than it might look. The project has been simplified by extracting core functionality into npm packages, and the two of them are named with their purpose.

@mohammed-bahumaish/prisma-dmmf-extended provides bidirectional conversion between the Prisma schema and the DMMF. @mohammed-bahumaish/prisma-dmmf-modifier provides a way to programmatically modify Prisma's DMMF.

So the diagram and the text are two views of the same object, and the conversion between them is a published library rather than a private function inside the app. That is a meaningful change for anyone who wants the same behaviour in their own tooling, because you can now depend on the conversion without depending on the editor, and the modifier package lets you change a data model programmatically rather than by text manipulation.

It also changes what the repository is. The application is one consumer of two libraries, and the libraries are the part that has to be correct. The package version of the web app is 0.1.0 and it is marked private, so the app is not published to npm, while the two DMMF packages are, with the editor depending on them at versions 1.0.1 and 1.0.0.

One line in the README is worth repeating, because it sets the boundaries of what support means here: this is a community project, not associated with Prisma.

## The scripts that move the schema into the database

The package manifest is small in the ways that matter, and the scripts describe the whole workflow of the application.

```text
"build": "next build",
"dev": "next dev",
"db:generate": "prisma generate",
"lint": "next lint",
"start": "next start",
"db:deploy": "npx prisma migrate deploy",
"db:push": "npx prisma db push"
```

The two database scripts are the interesting ones. db:push runs prisma db push, which applies the schema directly to the database without creating a migration, and db:deploy runs prisma migrate deploy, which applies the migration history. Both are in the manifest because an editor that edits schemas is an editor that will need to apply those schemas, and a developer iterating on a data model wants the direct path while a deployment wants the migration path.

The engines field requires node 24.x, which is a high floor and worth noting before you clone the repository. The application is a Next.js app, so next dev runs the development server, next build produces the production build and next start serves it.

The repository also carries a prisma/ directory, which is where the schema and the migrations live, and a .env.example with the environment variables the application expects.

The configuration is the interesting part, because it shows that this is a hosted application with accounts rather than a local viewer.

```text
DATABASE_URL=""
NEXTAUTH_SECRET=""
NEXTAUTH_URL="http://localhost:3000"
OPEN_AI_API_KEY=""
GITHUB_CLIENT_ID=""
GITHUB_CLIENT_SECRET=""
```

There is a database connection, a NextAuth secret and URL, an OpenAI API key and GitHub OAuth credentials, and the presence of @next-auth/prisma-adapter in the dependencies confirms the accounts are stored in the same database as everything else. A schema editor that persists what you draw, and that you can log into, is a different thing from a local file viewer, and the environment file is where that difference shows up.

## The compose file behind the hosted instance

The docker-compose.yml in the repository is the deployment of the author's own instance, and it is a good illustration of what running this thing involves.

The front of it is Traefik, image traefik:v2.10, publishing ports 80 and 443, with the Docker provider enabled and exposedbydefault set to false, so only the services that opt in get published. The web entrypoint redirects to the secure one at the scheme level, and certificates come from a Let's Encrypt resolver using the HTTP challenge, with the ACME storage file on a mounted volume and the Docker socket mounted read only so Traefik can discover containers.

The application service is named nextjs, built from the repository's own Dockerfile, and the build arguments are the environment variables the app needs.

```yaml
    nextjs:
      image: prisma-editor:latest
      build:
        context: .
        dockerfile: Dockerfile
        args:
          DATABASE_URL: postgresql://postgres:${POSTGRES_PASSWORD}@db:5432/postgres
          NEXTAUTH_URL: ${NEXTAUTH_URL}
          GITHUB_CLIENT_ID: ${GITHUB_CLIENT_ID}
          GITHUB_CLIENT_SECRET: ${GITHUB_CLIENT_SECRET}
          NEXTAUTH_SECRET: ${NEXTAUTH_SECRET}
          OPEN_AI_API_KEY: ${OPEN_AI_API_KEY}
```

The database URL points at a db service on the compose network, so the compose file describes a small stack: a proxy, the application and a Postgres instance, on an app-network. There is a second service, portfolio, with the same Traefik labelling pattern and a host rule, which shows the pattern being reused for the author's other site.

The Dockerfile itself is a careful multi stage build. It starts from node:20, installs dependencies with npm ci in a deps stage, copies the source in a builder stage, sets the six configuration values as build arguments and environment variables, disables Next.js telemetry, runs npx prisma generate explicitly after copying the files so that prisma can find the schema, and runs npm run build. The runner stage creates a non root user and group, copies public, the.next directory, the standalone output and the static assets, and sets NODE_ENV to production. The comments about output file tracing explain that the standalone output is copied so the image can be smaller than a full install.

## The Node version mismatch between the manifest and the image

There is one inconsistency in the repository that anyone setting this up should notice, and it is the kind of detail that turns into a confusing failure rather than a clean one.

The package manifest declares the engines field as node 24.x. The Dockerfile starts from node:20.

So the container image runs Node 20 while the package says the project requires Node 24. The build inside the image therefore runs on Node 20, and if any dependency or the Next.js build genuinely needs the newer runtime, the image build is where you will find out, not on your own machine where the engines field is respected.

The image is otherwise careful, and it is worth reading the two things it does that many Dockerfiles skip. It runs npx prisma generate explicitly after copying the whole project, with a comment explaining that the copy has to happen first so that prisma can find the schema, which is the classic failure when the schema is not in the build context. And it creates a system user and group with fixed ids, 1001 for both, and chowns the .next directory to them before copying the application files, so the running process is not root.

The trailing detail in the builder stage is the telemetry switch. The comment says Next.js collects completely anonymous telemetry data about general usage and that the environment variable NEXT_TELEMETRY_DISABLED 1 is set in both the builder and the runner stage, so a self hosted deployment does not report usage to a service the operator did not ask to report to.

## Where Prisma Editor is the wrong tool

The limits are mostly about what it does not change about the way you work with Prisma.

The first is that it is an editor for the schema, not for the migrations. The schema describes what the data model should be, and applying it to a real database is a separate concern that the Prisma CLI handles with migrations and with db push. An editor that draws a nicer diagram does not remove the need to decide how a schema change reaches production, and the presence of both db:push and db:deploy in the manifest is a reminder that those are two different paths with different consequences.

The second is that this is a hosted web application with accounts, not a local file view. The NextAuth secret, the GitHub OAuth credentials, the database URL and the OpenAI key are all part of running it, which means running your own instance is an operational commitment that a text editor in your IDE is not. For a schema that lives in a private repository, a hosted instance that you paste a schema into is a different proposition from editing schema.prisma on your own disk.

The third is the community status. The README says plainly that this is a community project and not associated with Prisma, so the schema format support, the Prisma internals usage and the DMMF packages all track whatever the maintainer has built against, and the dependency list shows a Prisma client at 5.21 with internals at 5.2, so a project on a much newer Prisma would be testing compatibility rather than assuming it.

The fourth is that the core logic is in packages you have to evaluate separately. The two DMMF packages are published under the maintainer's own scope rather than a Prisma scope, they are at version 1.0.x, and if you adopt the packages you are adopting them, not the editor.

And the fifth is the plainest one. If you are comfortable with the schema syntax and you edit it rarely, a text editor plus prisma generate is enough, and the editor is a second place where your schema can drift out of sync with the file that actually drives your migrations.

## Conclusion

Adopt Prisma Editor if you design Prisma schemas visually, if you want the schema and the diagram to stay in sync while you edit, and if you are willing to host it yourself for anything sensitive. Do not adopt it for a team that is happy with the schema file and the Prisma CLI, since the editor adds a service to maintain, and do not treat it as a Prisma product, because the README says it is a community project and not associated with Prisma. Verify first that the Node version in your environment matches the engines field of 24.x rather than the node 20 image the Dockerfile uses, that the DMMF packages you depend on are the ones the editor was built against, and that the authentication and storage configuration in .env.example is what you want before you expose it.

## FAQ

### What is Prisma Editor and who makes it?

It is a tool to visualise and edit Prisma Schema, built with Next.js and TypeScript, with a Monaco based text editor and a diagram of the data model. The README states that it is a community project and not associated with Prisma, and the hosted instance is at prisma-editor.bahumaish.com.

### Which npm packages hold the Prisma Editor core logic?

Two, published under the maintainer's own scope: @mohammed-bahumaish/prisma-dmmf-extended for bidirectional conversion between the Prisma schema and the DMMF, and @mohammed-bahumaish/prisma-dmmf-modifier for programmatically modifying Prisma's DMMF.

### How do I apply schema changes with Prisma Editor?

The package manifest provides two scripts, db:push which runs npx prisma db push and db:deploy which runs npx prisma migrate deploy, alongside db:generate which runs prisma generate. The web application also uses NextAuth with the Prisma adapter, so it stores accounts in the configured database.

### What Node version does Prisma Editor need?

The package manifest sets the engines field to node 24.x, while the Dockerfile in the repository is based on node:20. The image therefore builds and runs the application on Node 20 even though the manifest declares 24.x.

## Sources

- [Issues](https://github.com/mohammed-bahumaish/prisma-editor/issues)
- [License: MIT](https://github.com/mohammed-bahumaish/prisma-editor/blob/main/LICENSE)
- [mohammed-bahumaish/prisma-editor on GitHub](https://github.com/mohammed-bahumaish/prisma-editor)
- [Project website](https://prisma-editor.bahumaish.com)
- [README](https://github.com/mohammed-bahumaish/prisma-editor/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/mohammed-bahumaish-prisma-editor