Managed S3 / RustFS

S3-compatible object storage for files, backups, and assets, backed by RustFS. Object storage is one of the managed services Temps runs as a container on your own infrastructure.

Creating S3 Storage

Via Dashboard:

1. Navigate to Services → Create Service.
2. Select S3 / RustFS.
3. Choose the storage engine:
   • RustFS — the Rust-native default (rustfs/rustfs:1.0.0-alpha.98).
   • MinIO — kept for legacy services (minio/minio:RELEASE.2025-09-07T16-13-09Z). Deprecated — use RustFS for anything new.
   • Custom image — bring your own.
4. Click Create Service.

On creation Temps auto-assigns an API port starting from 9000 (and a console port from 9001 for RustFS), sets the region to us-east-1, and generates an access key (AKIA…) and secret key.

Manage from the CLI

Provision and manage object storage 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 an S3 bucket 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 service — 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 s3 -n my-storage -y

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

# Full details, including endpoint and access keys
bunx @temps-sdk/cli services show --id 10

# Link to a project so S3_ENDPOINT / S3_ACCESS_KEY (and friends) are injected
bunx @temps-sdk/cli services link --id 10 --project my-app
bunx @temps-sdk/cli services env --id 10 --project my-app     # see injected vars
bunx @temps-sdk/cli services unlink --id 10 --project 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 rustfs/rustfs:1.0.0-alpha.98
bunx @temps-sdk/cli services remove --id 10 -f             # destroys data

Connecting to S3

When linked to a project, Temps injects S3_ENDPOINT, S3_HOST, S3_PORT, S3_ACCESS_KEY, S3_SECRET_KEY, S3_REGION, and S3_BUCKET, along with AWS-style aliases (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION, AWS_ENDPOINT_URL) so standard AWS SDKs work unchanged:

import { S3Client, PutObjectCommand, GetObjectCommand } from '@aws-sdk/client-s3';

const s3 = new S3Client({
  endpoint: process.env.S3_ENDPOINT,
  region: process.env.S3_REGION,
  forcePathStyle: true,
  credentials: {
    accessKeyId: process.env.S3_ACCESS_KEY,
    secretAccessKey: process.env.S3_SECRET_KEY,
  },
});

await s3.send(new PutObjectCommand({
  Bucket: process.env.S3_BUCKET,
  Key: 'uploads/image.jpg',
  Body: fileBuffer,
  ContentType: 'image/jpeg',
}));

import os
import boto3

# boto3 reads AWS_* automatically, or pass them explicitly:
s3 = boto3.client(
    's3',
    endpoint_url=os.environ['S3_ENDPOINT'],
    aws_access_key_id=os.environ['S3_ACCESS_KEY'],
    aws_secret_access_key=os.environ['S3_SECRET_KEY'],
)

s3.upload_file('local-file.jpg', os.environ['S3_BUCKET'], 'uploads/image.jpg')

Pre-Signed URLs

Generate pre-signed URLs for temporary access without exposing credentials:

import { getSignedUrl } from '@aws-sdk/s3-request-presigner';

const command = new GetObjectCommand({
  Bucket: process.env.S3_BUCKET,
  Key: 'uploads/private-document.pdf',
});

// URL expires in 1 hour
const url = await getSignedUrl(s3, command, { expiresIn: 3600 });

Durability

Objects are stored on the underlying server disk via a dedicated Docker volume. For disaster recovery, replicate buckets to a separate off-server S3-compatible destination using rclone or a replication rule — data on a single disk is not protected against hardware failure.

Monitoring

View live metrics and health in the dashboard's Services section — CPU & memory usage, 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 (access keys, secret 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.

Stored objects 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. 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, request fees, or metered bandwidth costs. A recommended starting allocation:

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