Introduction

If you want Kubernetes to provide a JavaScript file containing MongoDB commands, the normal pattern is to store the file contents in a ConfigMap and mount that ConfigMap into a pod. The ConfigMap does not execute the script by itself; it only makes the file available to a container that runs mongosh or another MongoDB shell command.

Start With the JavaScript File

Suppose you have an initialization script named init.js.

1const appDb = db.getSiblingDB("appdb");
2
3appDb.createCollection("users");
4appDb.users.insertOne({
5  username: "admin",
6  role: "administrator"
7});

This is ordinary text, which makes it a good fit for ConfigMap data.

Create the ConfigMap From the File

The simplest command is:

kubectl create configmap mongo-init-script --from-file=init.js

That stores the file content under the key init.js.

If you prefer a declarative manifest:

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: mongo-init-script
5data:
6  init.js: |
7    const appDb = db.getSiblingDB("appdb");
8    appDb.createCollection("users");

Both approaches produce the same basic result: a ConfigMap containing the JavaScript source.

Mount the ConfigMap Into a Container

The script becomes useful only after it is mounted into a pod.

1apiVersion: batch/v1
2kind: Job
3metadata:
4  name: run-mongo-init
5spec:
6  template:
7    spec:
8      restartPolicy: Never
9      containers:
10        - name: mongo-shell
11          image: mongo:7
12          command:
13            - mongosh
14            - mongodb://mongo-service:27017/appdb
15            - /scripts/init.js
16          volumeMounts:
17            - name: mongo-script
18              mountPath: /scripts
19      volumes:
20        - name: mongo-script
21          configMap:
22            name: mongo-init-script

Now the file appears at /scripts/init.js and the container explicitly runs it with mongosh.

ConfigMap vs "Reference"

The title says "references the JS file," but in Kubernetes terms the ConfigMap does not store a pointer to some external file on disk. It stores the file content as ConfigMap data, then mounts that content into the container filesystem.

So the usual real workflow is:

1. create the file
2. put its contents into a ConfigMap
3. mount the ConfigMap
4. run the script from the mounted path

Keep Secrets Separate

Initialization scripts often need database credentials, but ConfigMaps are not for secrets. If authentication values are required, put them in a Kubernetes Secret and pass them to the pod via environment variables or mounted secret files.

That keeps the script and the sensitive values separated properly.

Jobs and Init Containers Are Common Execution Points

In practice, teams usually run MongoDB setup scripts in one of two places: a dedicated Job that can be rerun intentionally, or an init-style startup hook supported by a container image. The right choice depends on whether the script is a one-time database bootstrap step or part of each environment's startup flow.

That distinction matters operationally, because rerunnable jobs are often safer for troubleshooting than hiding all initialization logic inside an image startup path.

Common Pitfalls

The biggest pitfall is assuming the ConfigMap executes the JavaScript. It does not. A pod command or image entrypoint has to run the script explicitly.

Another common mistake is creating the ConfigMap correctly but forgetting to mount it into the container. If the file is never mounted, the container cannot execute it.

Developers also sometimes put passwords directly into the ConfigMap because the file is convenient. That is poor security practice; use Secrets for sensitive data.

Summary

• Put the MongoDB JavaScript file contents into a ConfigMap.
• Mount the ConfigMap into a pod so the file appears in the container filesystem.
• Run the mounted file with mongosh or another MongoDB shell command.
• A ConfigMap stores file content; it does not execute scripts automatically.
• Keep credentials in Secrets, not in the ConfigMap itself.