DEV Community: Friedrich WT

How to Set Up Prisma and MongoDB with Docker Compose for Development

Friedrich WT — Mon, 13 Apr 2026 15:52:02 +0000

Note: If you are here because you have this issue currently and you just want to copy and paste the code, click to jump directly there.

About two years ago, I wanted to use Prisma in a project but with MongoDB as database. Don’t ask me why, it was one of my first projects and from the fresh tutorial I just watched, the guy used MongoDB, then it was my choice without really understanding why. And in my case, I had a well structured schema for the database, so a relational database like PostgreSQL would have been a better choice. Also, my TypeScript orm of choice is now Drizzle, still I want to share about what was done.

The problem I had was to connect Prisma and MongoDB running in a docker container (local database). Even now, the recommended way according to Prisma docs to do it is to use MongoDB Atlas. This is because the MongoDB Prisma connector requires a replica set deployment for its transactions, and MongoDB Atlas provides such an environment out of the box. But what if you want everything locally (for development or testing for example), or if you want to be able to replicate that infrastructure without any external provider? This is exactly what we are going to do, using Docker Compose. We will use a Next.js application, but any other web framework would be fine.

Let’s start by defining what a replica set is. It appears more in Kubernetes jargon, but basically a replica set is a group of instances (database in our case) that maintain the same dataset. We replicate our data across multiple nodes to guarantee their availability. Instead of having one single database instance we will have for example three of them and if one goes down, the others will still work. In the case of MongoDB, the three base nodes are:

the primary: all writes to the database happen here
one or many secondary(ies): they replicate the data of the primary node and in case the primary node goes down, a secondary node will be elected to become the new primary node, and the system can still work as expected
the arbiter that will be an mediator when a secondary node is chosen as primary. It doesn’t provide data redundancy

A quick excalidraw draft of our replica set:

This is a very simplified description of how the MongoDB replica set works and if you want more details about MongoDB replication system, you can check their docs.

OK, now that we have an overview of the system that is required by Prisma to handle those transactions, it is time to write some code. Let’s start by creating a new Next.js application:

npx create-next-app@latest prisma-mongodb --yes

Then cd in:

cd prisma-mongodb

And start the development server:

npm run dev

I have setup a basic Nextjs to illustrate all this. This is just some markup and it doesn’t really matter.

You can find the exact state of the repo here : Initial setup

Next step is to install Prisma itself. Currently, the version 7 doesn’t support MongoDB. We need to use the version 6.19 which is the latest version with proper support for MongoDB.

We first install it as a dev dependency with the command:

npm install -D prisma@6.19

After, we also install the Prisma client (for database querying) and dotenv (to load the environment variables from a .env file)

Configure Nextjs for ESM compatibility. Make sure the following options are present in your tsconfig.json:

{
  "compilerOptions": {
    "module": "ESNext",
    "moduleResolution": "bundler",
    "strict": true,
    "esModuleInterop": true,
  }
}

And enable ESM in the package.json:

"type": module

We will now proceed to the initialization of Prisma ORM with:

npx prisma && npx prisma init --datasource-provider mongodb --output ../generated/prisma

Those commands will allow us to generate a prisma folder with a schema.prisma file to configure the database connection and a prisma.config.ts (configuration file).

Now comes the fun part: craft the DATABASE_URL. Currently with the commands we just ran, Prisma provides us a .env file with a dummy value for this environment variable.

DATABASE_URL="mongodb+srv://root:randompassword@cluster0.ab1cd.mongodb.net/mydb?retryWrites=true&w=majority"

It is composed of some key elements:

Protocol (Here mongodb+srv)
Base URL (root:randompassword@cluster0.ab1cd.mongodb.net) formed of the username of the database and its password then the host (which can also be something like localhost:27017)
The database (mydb)
Additional parameters (retryWrites=true&w=majority)

We are going to create our own replica set with Docker Compose and update the DATABASE_URL accordingly. Let’s start by creating a compose.yaml file (or docker-compose.yml):

Compose code

# compose.yaml or docker-compose.yml

services:
  mongodb-primary:
    image: bitnami/mongodb@${MONGODB_DIGEST}
    container_name: mongodb-primary
    env_file:
      - .env
      - db/.env.mongo.primary
    ports:
      - 127.0.0.1:27017:27017
    volumes:
      - demo-prisma-db:/bitnami
    networks:
      - app-network

  mongodb-secondary:
    image: bitnami/mongodb@${MONGODB_DIGEST}
    container_name: mongodb-secondary
    depends_on:
      - mongodb-primary
    env_file:
      - .env
      - db/.env.mongo.secondary
    ports:
      - 127.0.0.1:27018:27017
    networks:
      - app-network

  mongodb-arbiter:
    image: bitnami/mongodb@${MONGODB_DIGEST}
    container_name: mongodb-arbiter
    depends_on:
      - mongodb-primary
    env_file:
      - .env
      - db/.env.mongo.arbiter
    ports:
      - 127.0.0.1:27019:27017
    networks:
      - app-network

volumes:
  demo-prisma-db:
    driver: local

networks:
  app-network:
    driver: bridge

And the proper .env files:

The root .env:

MONGODB_DIGEST=sha256:4ff25cfca3d44751416fffcde9fc3847dcf49ace2998f244a3bf319d9e216125 # I pinned the version of the image to a specific one
MONGODB_REPLICA_SET_NAME=rs0 # The name of the replica set
MONGODB_REPLICA_SET_KEY=replicasetkey123 # The replica set key, required for all our nodes. The current value is just an example

A db folder at the root of the repository, with three .env files, each for one of the nodes:

.env.mongo.primary:

 MONGODB_REPLICA_SET_MODE=primary # The replication mode   (the type of node)
 MONGODB_ADVERTISED_HOSTNAME=mongodb-primary # It will  make the primary node configured with a hostname instead of an ip address. The other nodes will refer to him as  "mongodb-primary"
 MONGODB_ROOT_PASSWORD=password # The root password of the database, the current value is just an example

.env.mongo.secondary:

MONGODB_REPLICA_SET_MODE=secondary # The replication mode (the type of node)
MONGODB_INITIAL_PRIMARY_HOST=mongodb-primary # The hostname of our primary node
MONGODB_ADVERTISED_HOSTNAME=mongodb-secondary # The hostname of the secondary node
MONGODB_INITIAL_PRIMARY_ROOT_PASSWORD=password # The root password of the database

.env.mongo.arbiter:

 MONGODB_REPLICA_SET_MODE=arbiter # The replication mode (the type of node)
 MONGODB_INITIAL_PRIMARY_HOST=mongodb-primary # The hostname of our primary node
 MONGODB_ADVERTISED_HOSTNAME=mongodb-arbiter # The hostname of the arbiter node
 MONGODB_INITIAL_PRIMARY_ROOT_PASSWORD=password # The root password of the database

Now we should be able to start the replica set with:

docker compose up -d

Let’s check that it has properly started. For the primary node:

exec in it:

  docker exec -it mongo-primary bash

enter in mongosh with the proper authentication credentials:

   > mongosh -u root -p password 
   # The root user is the default user of the db and can be  changed by setting `MONGODB_ROOT_USER`
   # The password is the one we defined with  `MONGODB_ROOT_PASSWORD`

check:

  > db.isMaster().ismaster

It should output true.

For the secondary or arbitrary nodes we can repeat the same steps (exec and enter in mongosh) then check the content of our replica set:

rs.status().members

And see an output like:

[
  {
    _id: 0,
    name: 'mongodb-primary:27017',
    health: 1,
    state: 1,
    stateStr: 'PRIMARY',
      ...
  },
  {
    _id: 1,
    name: 'mongodb-secondary:27017',
    health: 1,
    state: 2,
    stateStr: 'SECONDARY',
      ...
  },
  {
    _id: 2,
    name: 'mongodb-arbiter:27017',
    health: 1,
    state: 7,
    stateStr: 'ARBITER',
    ...
  }
]

Finally we can set our DATABASE_URL in the root .env file:

DATABASE_URL=mongodb://root:password@localhost:27017/db-dev?replicaSet=rs0&authSource=admin

We use localhost:27017 for the host because we exposed the container of the primary node on our machine on 127.0.0.1:27017.

To test that everything works, let’s add some dummy models to our schema.prisma:

generator client {
  provider = "prisma-client"
  output   = "../generated/prisma"
}

datasource db {
  provider = "mongodb"
  url      = env("DATABASE_URL")
}

model User {
  id        String   @id @default(auto()) @map("_id") @db.ObjectId
  email     String   @unique
  posts     Post[]
  createdAt DateTime @default(now()) @db.Timestamp()
  updatedAt DateTime @default(now()) @updatedAt @db.Timestamp()
}

model Post {
  id        String   @id @default(auto()) @map("_id") @db.ObjectId
  title     String
  slug      String
  content   String
  published Boolean  @default(false)
  authorId  String   @db.ObjectId
  createdAt DateTime @default(now()) @db.Timestamp()
  updatedAt DateTime @default(now()) @updatedAt @db.Timestamp()

  author User @relation(fields: [authorId], references: [id])
}

After that we can sync the schema with:

npx prisma db push

which will generate the Prisma client and create the collections in MongoDB (we don’t use migrate because it doesn’t support migrations like relational databases). And to have a visual of all those changes, we can run the Prisma studio:

npx prisma studio

And open localhost:5555 where our two collections should display, even if they are currently empty.

Let’s instantiate the Prisma Client we will use in the application. I created a prisma.ts file in the lib folder of the app:

// lib/prisma.ts
import { PrismaClient } from "../../generated/prisma/client";

const globalForPrisma = global as unknown as { prisma: PrismaClient };

export const prisma = globalForPrisma.prisma || new PrismaClient();

if (process.env.NODE_ENV !== "production") globalForPrisma.prisma = prisma;

We make sure to create one single instance of the Prisma Client by using a global variable. And a seed script to put some dummy data in the database:

// lib/seed.ts
import { prisma } from "./prisma";

async function main() {
  // Create a new user with some posts
  await prisma.user.create({
    data: {
      email: "alice@test.test",

      posts: {
        createMany: {
          data: [
            {
              title: "First Post",
              slug: "first-post",
              content: "This is my first post!",
              published: true,
            },
            {
              title: "His mother had always taught him",
              slug: "his-mother-had-always-taught-him",
              content:
                "His mother had always taught him not to ever think of himself as better than others. He'd tried to live by this motto. He never looked down on those who were less fortunate or who had less money than him. But the stupidity of the group of people he was talking to made him change his mind.",
            },
            {
              title: "He was an expert but not in a discipline",
              slug: "he-was-an-expert-but-not-in-a-discipline",
              content:
                "He was an expert but not in a discipline that anyone could fully appreciate. He knew how to hold the cone just right so that the soft server ice-cream fell into it at the precise angle to form a perfect cone each and every time. It had taken years to perfect and he could now do it without even putting any thought behind it.",
              published: true,
            },
            {
              title: "Dave watched as the forest burned up on the hill",
              slug: "dave-watched-as-the-forest-burned-up-on-the-hill",
              content:
                "Dave watched as the forest burned up on the hill, only a few miles from her house. The car had been hastily packed and Marta was inside trying to round up the last of the pets. Dave went through his mental list of the most important papers and documents that they couldn't leave behind. He scolded himself for not having prepared these better in advance and hoped that he had remembered everything that was needed. He continued to wait for Marta to appear with the pets, but she still was nowhere to be seen.",
            },
          ],
        },
      },
    },
    include: {
      posts: true,
    },
  });
}

main()
  .then(async () => {
    await prisma.$disconnect();
  })
  .catch(async (e) => {
    console.error(e);
    await prisma.$disconnect();
    process.exit(1);
  });

Attach the seed script to the config in the prisma.config.ts (install tsx as a dev dependency)

import "dotenv/config";
import { defineConfig, env } from "prisma/config";

export default defineConfig({
  schema: "prisma/schema.prisma",
  migrations: {
    path: "prisma/migrations",
    seed: "tsx src/lib/seed.ts",
  },
  engine: "classic",
  datasource: {
    url: env("DATABASE_URL"),
  },
});

Then, run it with:

npx prisma db seed

And we should now seed those entries in the database through the Prisma Studio.

Let’s fetch that data in our application to properly display it:

Each post can be viewed individually:

And we can also create a new posts:

Which will appear

That’s it. We were able to create our replica set locally using Docker Compose, and connect to it in our application with Prisma. This setup is ideal for development and testing or when you don’t want to use MongoDB Atlas. Thanks you for reading and happy coding !

Introducing MoonCode: an application that monitors you coding activity, powered by a VS Code extension with offline support

Friedrich WT — Tue, 17 Mar 2026 16:48:28 +0000

During the last months, I have being building an application called MoonCode to track my coding time, languages and projects I was working on. And let me visualize all that on a modern looking dashboard. In this article, I want to write about it, the features it currently has, how it works, why I built it and what I learned along the way.

Presentation

MoonCode is a platform tracking and giving you a summary of your coding activity: coding time, languages, files, all in one single place. To use it, you just need to install the VS Code extension, login, then everything is handled for you. Currently the project only supports VS Code as code editor.

Website link: mooncode.cc

MoonCode’s Features

summary of your coding time, languages and projects per day, week, month, year, or any custom period
support for most programming languages and files extensions. The extension automatically detects the language you are using
the dashboard to visualize your data is local. It comes out of the box when you install the VS Code extension
real-time sync dashboard (every minute). The stats always stay fresh and up to date with the data collected by the extension
the extension works offline and synchronize to the API once you’re back online. So no data loss if you lose your internet connexion
it also keeps your stats up to date automatically

Some screenshots of the dashboard and the extension:

Link on the VS Code marketplace if you want to try it: MoonCode VS Code extension. And the GitHub repository: MoonCode.

Architecture

The main parts of MoonCode are:

a VS Code extension that collect all the relevant metrics (files data and programming languages)
an API that manages all requests, built using NestJS. This choice was made because of the modular architecture of the framework
a Vite+React Router dashboard that comes with the extension and allow you to visualize all the data in a user-friendly way
a PostgreSQL database: a battle tested and robust option for an SQL database, used to store all the data needed: user and analytics data in one single place
a Turborepo monorepo to keep all the parts and shared packages in a single, unified TypeScript codebase
trpc between the API, the dashboard and the VS Code extension to allow end-to-end type-safety within the monorepo
a website, built using NextJS. It is not really a core part, but more like the landing page of the project

So, in on excalidraw diagram it looks like this:

Why I wanted to build it

Why building a productivity coding time tracker when there are already plenty of them out there? Especially when there is already WakaTime doing the same thing, is more established, battle-tested and very feature-rich?

I found the free-tier of Wakatime a little bit limiting (as a cheap developer 😏). Don’t get me wrong, it is an awesome project and product and my goal is not to discredit it. I just decided to build my own, that does exactly what I need and give me full control over the data. About the data control, more on that later.

This project didn’t have to be feature complete, it didn’t have to be the perfect app, it just needed to solve that specific issue I had: track and monitor my coding statistics on any period I want.

And honestly this seemed as a very exciting side-project to work on. Because not only I would build something that could solve a problem I had, but it was very exciting to me personally. I already knew to build frontend web apps, but didn’t know enough about backend but the most interesting part was definitely the extension. How would it work and its life-cycle in general. I decided to focus only on VS Code for the moment because it is the code editor I use on the day to day.

What I learned/lessons

While building MoonCode I learned quite a few things about how VS Code extensions work, backend and APIs in general and Nest.js in particular. I also taught me some tips and tricks about TypeScript monorepos. I will try to be short here because some of the points deserve their own detailed blog post.

VS Code extensions: they were intimidating for me at the beginning, especially because not too much is said about them. We usually build frontend apps and backend systems, not vscode plugins. But the extensions are just Node.js applications with an entrypoint that is the extension.js (built from extension.ts) file, and it can be changed anyways. They have a package.json like any other Node.js app. The main difference with the other apps, is that you can use the VS Code API to create and execute VS Code commands, show notifications, subscribe to events happening in the code editor,… Two approaches are mostly used to build VS Code extensions: Functional Programming (FP) and Oriented Object Programming (OOP) approaches. I chose the FP approach since it is the one I was the most comfortable with.
Nest.js: before building MoonCode, I didn’t do a lot of backend, I had mostly worked with Next.js and even though it offers some backend functionalities, it is not a full fleshed backend framework. In my case the API I will build would be consumed by the extension itself, the dashboard and maybe other applications/packages later. So a separate backend was necessary. As I said earlier, I chose Nest.js for it scalability and opinionated nature (in fact, I wanted to try something new that was stricter, stable and battle-tested so I could really learn the backend side of applications). And I can say without any doubt that it is an, awesome framework, everything is organised in modules and properly separated. Even though Nest.js uses Oriented Object Programming, I didn’t need to be a master at it to be productive. The mental model was a little bit odd at the beginning but I started to click as I was using it.
TypeScript monorepos and trpc: Turborepo is a simple yet very powerful tool to manage TypeScript monorepos, but it took me a very long time (many weeks/months) to really take advantages of its features: the cli, the cache,… I also used trpc to make everything typesafe from the backend to the frontend apps. It is so beautiful how the typesafety flows like water in the different applications. But it was very tricky to setup. I messed a lot with tsconfigs across the monorepo to get what I wanted. Some apps used ES Modules, others like Nest were still on CommonJS… It was a real chaos to make everybody share a typesafe contract, but it ended up being wired properly. What I also really like about monorepos is the ability to share common code/utility functions between all the apps in packages.
Docker in monorepos: this one is also tricky but I can just have one single docker compose file with all my apps. Each of them has its own dockerfile. Or (this one is my favorite approach) deploy each app individually using its Dockerfile.

Building MoonCode was a real journey, I learned a lot. Some days it got very tricky due to the nature of what I was building (a VS Code extension was something new, but working with time in programming is, well, very tricky). But one thing I would 100% avoid if I had to start again is over-engineering. I wasted so many hours, days and even weeks trying to perfect the folder structure of the apps, get the ESLint rules right, …. It was useful in some cases like the VS Code extension and otherwise I would have ended with a real mess. But some days I felt like it was more like an excuse to not continue building, a fake productivity.

I still fall in that trap and I’m learning to detect when I start over-engineering and stop it if so. I have shipped the extension way earlier but I spent a lot of time fixing small issues, not getting anything really serious done for a long time. This is something I needed to hammer down in my head: avoid over-engineering at all costs. Perfection is the enemy, it kills momentum. Ship something that works. It doesn’t mean produce bad quality code, but just get it done. And move on with your day.

About the data ownership, one of initial goals of this project was to make it in a way to allow the user(s) to self-host the API and the database. This can be accomplished with Docker for sure. And since the dashboard is bundled with the VS Code extension, it doesn’t have to be self-hosted. The pain point I hit was to wire the VS Code extension and the API, so the user could update the API URL in the VS Code extension to their self-hosted version. I might find a good solution and ship it soon.

So, yes, that’s it. Thanks you if you made if so far in the article and happy coding !