Managed MongoDB

Managed MongoDB is a MongoDB container that Temps runs on your own server: you create the service, link it to a project, and Temps injects MONGODB_URL and the other connection variables into that project's environment. Scheduled backups upload mongodump archives to your S3 bucket, and you can restore in place or into a new service. There are no per-GB fees or connection caps.

Creating a MongoDB instance

Via Dashboard:

1. Navigate to Services → Create Service.

2. Select MongoDB.

3. Choose the image:

   • MongoDB 8 (Managed) — the recommended default (gotempsh/mongodb-walg:8.0).
   • Custom image — bring your own (e.g. mongo:7.0).

   Backups work the same for both: a one-shot mongodump sidecar archives the database and uploads it to S3.

4. Optionally enable replica set mode (see below).

5. Click Create Service.

On creation Temps auto-assigns a host port starting from 27017, creates a dedicated Docker volume at /data/db, and generates a root user with an auto-generated password.

Manage from the CLI

Provision and manage MongoDB two ways — hand it to a coding agent, or run the @temps-sdk/cli commands yourself.

Drive it through an AI agent

Most clients never type these commands by hand. A coding agent — Claude Code, Codex, or Opencode — runs the @temps-sdk/cli calls (shown below) against the Temps API for you. Install the CLI skill once so the agent knows every command and flag:

npx skills add gotempsh/temps --skill temps-cli

Then describe the goal in plain language — "create a MongoDB service and link it to my project" — and the agent issues the commands — or call the skill directly by typing /temps-cli. New to AI agents? See how to call a skill for the step-by-step. Browse every skill on the AI Skills page.

The underlying commands

Whether the agent runs them or you do, these are the @temps-sdk/cli calls. The same services create -t <type> flow covers every managed database — see Managed PostgreSQL for the fully worked, parameter-by-parameter example.

# Log in once (stores credentials in ~/.temps)
bunx @temps-sdk/cli login

# Create the service. Set parameters with repeatable -s key=value flags;
# if a required one is missing the CLI fails fast and names it, so you
# can add it and re-run.
bunx @temps-sdk/cli services create -t mongodb -n my-mongo -y

# List services and grab the numeric ID
bunx @temps-sdk/cli services list

# Full details, including the connection string
bunx @temps-sdk/cli services show --id 10

# Link to a project so MONGODB_URL (and friends) are injected on deploy
bunx @temps-sdk/cli services link --id 10 -p my-app
bunx @temps-sdk/cli services env --id 10 -p my-app     # see injected vars
bunx @temps-sdk/cli services unlink --id 10 -p my-app

# Lifecycle
bunx @temps-sdk/cli services stop --id 10
bunx @temps-sdk/cli services start --id 10
bunx @temps-sdk/cli services upgrade --id 10 -v mongo:7.0
bunx @temps-sdk/cli services remove --id 10 -f             # removes container and data volume

Connecting to MongoDB

import { MongoClient } from 'mongodb';

// MONGODB_URL is injected automatically when the service is linked
const client = new MongoClient(process.env.MONGODB_URL);
await client.connect();

const db = client.db(process.env.MONGODB_DATABASE);
const user = await db.collection('users').findOne({ id: userId });

import os
from pymongo import MongoClient

client = MongoClient(os.environ['MONGODB_URL'])
db = client[os.environ['MONGODB_DATABASE']]

user = db['users'].find_one({'id': user_id})

Linking to Projects

When you link a MongoDB service to a project, Temps injects these variables into the environment:

Common use cases

Flexible documents

Store records whose shape varies between entries without migrations:

await db.collection('events').insertOne({
  type: 'signup',
  payload: { plan: 'pro', referrer: 'docs' },
  at: new Date(),
});

Content & catalogs

Model nested, hierarchical data — product catalogs, CMS content — as a single document instead of joining across tables.

Aggregation pipelines

Compute analytics in the database with the aggregation framework:

const topPlans = await db.collection('events').aggregate([
  { $match: { type: 'signup' } },
  { $group: { _id: '$payload.plan', count: { $sum: 1 } } },
  { $sort: { count: -1 } },
]).toArray();

Backups & durability

On the backup schedule you set, Temps runs a one-shot mongodump --archive --gzip sidecar against the service and uploads the archive to your S3 source. This works the same for the managed image and custom images; each schedule has its own retention window (in days). Restore in place or into a new service from any archive. Unlike PostgreSQL, MongoDB has no point-in-time recovery, so writes after the last backup are lost. See Restore & Recovery for the restore API.

Restores are driven from the CLI:

# What restore modes does the service support?
bunx @temps-sdk/cli services restore-capabilities --id 10
# List backups stored on an S3 source
bunx @temps-sdk/cli services list-backups --s3-source-id 3
# Restore in place from a specific backup
bunx @temps-sdk/cli services restore --id 10 --backup-id 42 -y

Replica set mode does not change backups or availability: it is a single node. Temps' high-availability clusters are PostgreSQL-only (Postgres high availability).

Monitoring

View live metrics and health in the dashboard's Services section — CPU & memory usage, connection count, disk usage, and uptime. Service-level monitoring is not yet exposed through the CLI.

Resource limits

You can cap how much memory, swap, and CPU the service's container is allowed to use, and inspect what it's actually consuming. A service with no limits set runs unconstrained (the default). The same controls apply to every managed service type — PostgreSQL (standalone and cluster), MongoDB, Redis, RustFS, and S3.

The service detail page shows a Resources card that polls runtime status every 30 seconds and live usage every 5 seconds, plus an Edit limits dialog.

Editing limits

Open Services → select the service → Resources card → Edit limits. The dialog has independent Memory and CPU toggles:

Endpoints

All served under the /api prefix:

GET   /api/external-services/{id}/runtime
GET   /api/external-services/{id}/stats
PATCH /api/external-services/{id}/resources

• GET …/runtime (ExternalServicesRead) — a per-container docker inspect snapshot: status, restart_count (a steady climb signals a crash loop), oom_killed, last exit_code, image, and the limits actually applied (so you can detect drift between configured and live caps).
• GET …/stats (ExternalServicesRead) — a one-shot CPU/memory usage sample per container, cheap enough to poll every 5–10s. memory_percent is measured against the memory limit when one is set, or against host RAM otherwise.
• PATCH …/resources (ExternalServicesWrite) — persists the caps to the service's encrypted config and live-applies them via Docker's update API (no restart needed). A request where every field is null removes all limits.

Security

Encryption

Credentials (passwords, access keys) are encrypted with AES-256-GCM before being written to the Temps database. The key lives at ~/.temps/encryption_key — protect this file and back it up separately from the database.

Database contents are not encrypted at the application layer by default. For encryption at rest, enable it at the infrastructure level — encrypted volumes or LUKS on bare metal; Temps does not manage disk encryption. In transit, traffic stays on the internal Docker network and is never exposed to the public internet.

Deleting the service

1. Take a fresh backup — Services → select the service → Trigger backup, and wait for it to finish. The backup file stays in your S3 bucket after the service is deleted; open the backup to copy its S3 path.
2. Unlink all projects so no running app still holds a reference to the credentials.
3. Delete the service from its settings page and confirm.

Pricing & ownership

Because the service runs on your own infrastructure, there are no per-GB storage charges, connection caps, or metered bandwidth fees. A recommended starting allocation:

MongoDB is built in. For comparison (checked October 2026): Vercel and Netlify have no built-in MongoDB, so you connect an external provider; Railway offers a MongoDB template that it runs as an unmanaged service. Your data never leaves your server; Temps (the company) has no access to it. See Data Ownership & Privacy for the full policy, including GDPR.

Related

• Set Up Managed Services — every service type, import and per-project isolation
• Managed PostgreSQL, Managed MariaDB, Managed Redis and Managed S3 (RustFS) — the other managed engines
• Backups and Restore & Recovery — schedules, S3 sources and restore modes