TempsTemps
On this page
  1. Creating a MongoDB Instance
  2. Manage from the CLI
  3. Connecting to MongoDB
  4. Common Use Cases
  5. Backups & Durability
  6. Monitoring
  7. Resource Limits
  8. Security
  9. Deleting the Service
  10. Pricing & Ownership

Managed MongoDB

A managed MongoDB instance — a NoSQL document database for flexible, schema-less data. MongoDB is one of the managed database services Temps runs as a container on your own infrastructure.

Provision and manage MongoDB three ways: the dashboard, the @temps-sdk/cli command-line tool (Manage from the CLI), or the REST API. If you use an AI coding agent (Claude Code, Cursor, Windsurf), install the temps-cli skill and just describe what you want.

Creating a MongoDB Instance

Create a MongoDB instance

  1. 1

    Navigate to Services, then click Create Service.

  2. 2

    Select MongoDB as the service type.

  3. 3

    Choose the image: MongoDB 8 (Managed + WAL-G) for the recommended default with S3 snapshot backups, or a Custom image (e.g. mongo:7.0) which supports local dumps only.

  4. 4

    Optionally enable replica set mode to unlock transactions and change streams (this choice is permanent and cannot be changed after creation).

  5. 5

    Click Create Service. Temps auto-assigns a host port from 27017, creates a Docker volume at /data/db, and generates a root user with an auto-generated password.

    Checkpoint: Open the Services list and confirm the new my-mongo service appears and its status reaches running.

Via Dashboard:

  1. Navigate to Services → Create Service.
  2. Select MongoDB.
  3. Choose the image:
    • MongoDB 8 (Managed + WAL-G) — the recommended default (gotempsh/mongodb-walg:8.0). This image archives mongodump snapshots to S3.
    • Custom image — bring your own (e.g. mongo:7.0). Custom images support local dumps only.
  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.

Replica set mode runs a single-node replica set (which unlocks transactions and change streams). Temps auto-generates the authentication keyfile when you enable it. This choice is made at creation and cannot be changed afterward. Standalone mode is the default.

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.

Create

# 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

Inspect, link & manage

# 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 --project-id 5
bunx @temps-sdk/cli services env --id 10 --project-id 5     # see injected vars
bunx @temps-sdk/cli services unlink --id 10 --project-id 5

# 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             # destroys data

Connecting to MongoDB

Node.js with the MongoDB driver

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 });

Python with pymongo

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})

Connection string format: mongodb://<user>:<password>@<host>:27017/<database> (with ?replicaSet=<name> appended when replica-set mode is enabled).

Connections happen over the Temps internal network using the container name as the host — the port is not exposed to the public internet.

Linking to Projects

Link MongoDB to a project

  1. 1

    Open the project you want to connect MongoDB to.

  2. 2

    Link the MongoDB service to the project so its connection variables are injected at deploy time.

  3. 3

    Redeploy the project so MONGODB_URL, MONGODB_HOST, MONGODB_PORT, MONGODB_DATABASE, MONGODB_USERNAME, and MONGODB_PASSWORD are available to the app.

    Checkpoint: Check the project environment variables and confirm MONGODB_URL is present and points at the linked service.

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

VariableDescription
MONGODB_URLFull connection string
MONGODB_HOSTContainer hostname
MONGODB_PORTPort (27017)
MONGODB_DATABASEDatabase name
MONGODB_USERNAMEUsername
MONGODB_PASSWORDPassword

Common Use Cases

  • Name
    Flexible Documents
    Description

    Store records whose shape varies between entries without migrations:

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

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

  • Name
    Aggregation Pipelines
    Description

    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

Restore MongoDB from a backup

  1. 1

    Confirm the service supports restore and find the backup to restore from (list the backups stored on the S3 source).

  2. 2

    Start the restore from the latest snapshot for the service. Restore overwrites the existing data in place.

    Checkpoint: Watch the restore run until its status shows completed before sending traffic back to the database.

The managed gotempsh/mongodb-walg image archives mongodump snapshots to your configured S3 destination on a schedule you set; each backup schedule has its own retention window (in days). Custom images fall back to local dumps only. Unlike PostgreSQL, MongoDB restore is snapshot-based (latest) — there is no point-in-time recovery.

Restores are driven from the CLI:

Restore via the Temps 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

For higher availability, enable replica set mode at creation so the instance runs as a replica set rather than a single standalone node.

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

Edit resource limits

  1. 1

    Open Services and select the MongoDB service.

  2. 2

    On the Resources card, click Edit limits.

  3. 3

    Toggle Memory on and set the hard cap in MiB (e.g. 512); leave it off to run unconstrained.

  4. 4

    Optionally set Swap as extra swap above the memory cap in MiB (e.g. 256 lets the container use 512 MiB RAM plus 256 MiB swap).

  5. 5

    Toggle CPU on and set the cap in cores (e.g. 1); leave it off for unlimited CPU.

  6. 6

    Save. Temps persists the caps to the encrypted config and live-applies them via Docker's update API with no restart needed.

    Checkpoint: On the Resources card confirm the applied limits match what you set, and watch that memory usage stays under the cap so the OOM killer does not terminate the container.

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

FieldMeaningEmpty / off
MemoryHard memory cap, in MiBUnlimited
SwapExtra swap above the memory cap, in MiBNo extra swap
CPUCPU cap, in coresUnlimited

The Swap input means swap in addition to the memory limit — Memory = 512 and Swap = 256 lets the container use 512 MiB of RAM plus 256 MiB of swap. Internally Temps submits memory + swap to Docker. When a memory cap is set and the working set exceeds it, the kernel OOM killer terminates the container — that kill never reaches the app's own logs, so the oom_killed flag on the runtime endpoint is often the only signal.

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

Rotate credentials

  1. 1

    Open Services and select the MongoDB service.

  2. 2

    Click Rotate Credentials.

  3. 3

    Confirm the rotation. Temps regenerates the password and updates linked projects automatically so you never have to choose or copy a password.

    Checkpoint: Redeploy or restart the linked apps and confirm they reconnect using the rotated MONGODB_PASSWORD injected by Temps.

  • Name
    Network Isolation
    Description
    • Reachable only from containers on the same Temps internal network — the port is never exposed to the public internet
    • Apps connect using the container name as the host, over private networking
    • Credentials are auto-generated at creation; you never have to choose a password
  • Name
    Credential Handling
    Description
    • Temps injects credentials as environment variables when the service is linked — never hard-code them
    • Credentials are stored encrypted at rest (see Encryption below)
    • Rotate them from Services → select service → Rotate Credentials; linked projects update automatically

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

Delete the MongoDB service

  1. 1

    Download a backup: open Services, select the service, go to Backups, and download the latest.

  2. 2

    Unlink all projects so no running app still holds a reference to the credentials.

  3. 3

    Delete the service from its settings page and confirm. This permanently destroys all data and backups.

    Checkpoint: Reload the Services list and confirm the service no longer appears.

Deleting the service permanently destroys all data and backups associated with it. This cannot be undone.

  1. Download a backup — Services → select the service → Backups → download the latest.
  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:

TierAllocation
Small1 GB RAM, 10 GB storage
Medium2 GB RAM, 50 GB storage
Large4 GB+ RAM, 200 GB+ storage

MongoDB is built in — Vercel and Netlify are external-only, while Railway includes it. Your data never leaves your server; Temps (the company) has no access to it. See Data Ownership & Privacy for the full policy, including GDPR.

Was this page helpful?