Managed MariaDB

Managed MariaDB is a MariaDB container that Temps runs on your own server: you create the service, link it to a project, and Temps injects DATABASE_URL, MYSQL_URL and MARIADB_URL into that project's environment. It speaks the MySQL wire protocol, so MySQL clients and ORMs connect unchanged. The default mariadb:lts image is backed up with mariadb-backup and archived binary logs, which gives you point-in-time recovery. There are no per-GB fees or connection caps.

Creating a MariaDB instance

Via Dashboard:

1. Navigate to Services → Create Service.
2. Select MariaDB.
3. Keep the default image, mariadb:lts, or enter another MariaDB image.
4. Pick a size profile. You choose it once: it is not editable after creation.
5. Click Create Service.

On creation Temps auto-assigns a host port starting from 3306, creates a Docker volume mounted at /var/lib/mysql, and generates the application and root passwords. The container is named mariadb-<service-name>, runs with the server timezone set to UTC, and has binary logging on from the first start so the service is ready for point-in-time recovery.

Manage from the CLI

The same services commands cover every managed database. If you use an AI coding agent, install the temps-cli skill and describe what you want; the agent runs these commands for you.

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

# Create the service. Set parameters with repeatable -s key=value flags
bunx @temps-sdk/cli services create -t mariadb -n my-db -y

# A larger profile and a one-minute binlog shipping interval
bunx @temps-sdk/cli services create -t mariadb -n my-db \
  -s size_profile=standard -s binlog_archive_interval=1m -y

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

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

# Link to a project so DATABASE_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 remove --id 10 -f             # removes container and data volume

To bring a MariaDB or MySQL-compatible container you already run under Temps management, see Import an existing container.

Connecting to MariaDB

A MariaDB service is one shared database server. When you link it, Temps creates a separate database for each project and environment inside that server, named {project_slug}_{environment_slug}, and injects these variables on the next deploy:

import mysql from 'mysql2/promise';

// DATABASE_URL is injected automatically when the service is linked
const pool = mysql.createPool(process.env.DATABASE_URL);

const [rows] = await pool.query('SELECT NOW() AS now');

import os
from sqlalchemy import create_engine, text

# Swap the scheme for the driver you installed (PyMySQL here)
url = os.environ["DATABASE_URL"].replace("mysql://", "mysql+pymysql://", 1)
engine = create_engine(url, pool_pre_ping=True)

with engine.connect() as conn:
    print(conn.execute(text("SELECT NOW()")).scalar())

Size profiles

The size profile sets both the container's resource limits and MariaDB's own tuning, so the buffer pool always fits inside the memory cap. Pick it when you create the service.

Every linked project shares that connection budget, so size your application pools against max_connections. You can still change the container's memory, swap and CPU caps afterwards from the service's Resources card, as for any managed service (see Resource limits); the MariaDB tuning that came with the profile stays as it was.

Backups & point-in-time recovery

Backups go to an S3-compatible bucket on a schedule you configure. See Backups for S3 sources, schedules and retention. For MariaDB, Temps picks the method from the tools in the image:

Point-in-time recovery has two halves:

1. A physical base backup. Each scheduled run uploads a mariadb-backup snapshot and records the binary-log position it was taken at.
2. Archived binary logs. Between backups, Temps ships closed binary-log segments to the same S3 location every binlog_archive_interval (5 minutes by default). A restore replays them on top of the base with mariadb-binlog.

Use InnoDB tables. MyISAM and Aria tables are not crash-safe and do not restore consistently to a point in time.

Restoring

MariaDB supports all three restore modes:

• In place overwrites the service's data with the backup.
• Into a new service leaves the original untouched and creates a second MariaDB service from the backup, which is the safe way to inspect old data or build a staging copy.
• Point in time restores a physical base backup and replays binary logs up to your target. The target is a UTC timestamp, or a binlog_file:position pair. Transaction-ID and named-restore-point targets are PostgreSQL only.

# Inspect what restore modes a service supports (in-place / new service / PITR)
bunx @temps-sdk/cli services restore-capabilities --id <id>

# List backups stored on an S3 source
bunx @temps-sdk/cli services list-backups --s3-source-id <id>

# Start a restore (optionally to a point in time, optionally into a new service)
bunx @temps-sdk/cli services restore --id <id> --backup-id <id> [--pitr <iso>] [--new-service auto]

A point-in-time restore from a mariadb-dump backup is rejected, because a logical dump has no binary-log position to replay from. Restore & Recovery covers the restore plan preview, recovery targets and restoring backups made by another Temps instance.

Changing the MariaDB version

docker_image is editable, so you move to another MariaDB release by changing the image on the service. The container runs with MARIADB_AUTO_UPGRADE=1, which makes MariaDB upgrade its system tables on the first start after an image change. Take a backup first. To rehearse on a copy, restore that backup into a new service and try the new image there before you touch the original.

The services upgrade command, and the guided major-version upgrade that PostgreSQL has, are not available for MariaDB.

Security

Database contents are not encrypted at the application layer. For encryption at rest, use encrypted volumes or LUKS on the host; Temps does not manage disk encryption.

Deleting the service

Pricing & ownership

Because the service runs on your own infrastructure, there are no per-GB charges, connection caps or metered bandwidth fees: the cost is the server it runs on. Your data never leaves that server, and 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 Redis, Managed MongoDB and Managed S3 (RustFS) — the other managed engines
• Backups and Restore & Recovery — schedules, S3 sources, restore modes and recovery targets
• Environment variables — how injected variables reach your app