Temps

Production Checklist

Things to verify before treating a Temps instance as production. Each item links to the page where the setup is documented.

Backups

  • S3 storage connected — Backups require an S3-compatible bucket (Cloudflare R2, MinIO, or AWS S3). See Set Up Backups & Monitoring.
  • Backup schedule configured — At minimum, a daily full backup. See recommended schedules.
  • Test restore verified — Run a restore against a staging environment before you need it in an emergency.
  • Backup destination is off-server — Backups stored on the same server are lost if the server is lost. Use a provider in a different region.

Monitoring & Alerting

  • Uptime monitor created for each critical project. See Create an uptime monitor.
  • Notification channel configured (email, Slack, or webhook) so alerts reach someone. See Set up a notification channel.
  • Error tracking DSN set in each project's environment variables. See Error Tracking.
  • Resource metrics reviewed — Check CPU and memory baselines under [Project → Metrics] so you know what "normal" looks like before something breaks.

SSL & Domains

  • Custom domain added and TLS provisioned for each public-facing project. See Custom Domains & SSL.
  • Certificate auto-renewal confirmed — Temps renews via Let's Encrypt automatically; verify port 80 remains open to the internet so HTTP-01 challenges succeed.

Security

  • SSH key-only access on the server — disable password SSH auth (PasswordAuthentication no in /etc/ssh/sshd_config).
  • Firewall reviewed — Only ports 22, 80, and 443 should be open to the internet. See Networking.
  • Admin account uses a strong password or SSO — See Teams & Collaboration.
  • Secrets in environment variables, not source code — See Environment Variables.

Logs

Temps writes to stdout/stderr, captured by systemd. By default, journald applies its own retention policy (usually capped at 10% of disk space or 4 GB, whichever is smaller). For production you may want explicit control:

# Check current journal disk usage
journalctl --disk-usage

# Limit journal size in /etc/systemd/journald.conf
# SystemMaxUse=1G
# MaxRetentionSec=30day
sudo systemctl restart systemd-journald

Application-level logs (container stdout) are streamed via Project → Logs and retained according to your log retention setting in Settings → General.

Upgrades

  • Upgrade process understood before you need it under pressure. See Upgrade Temps.
  • Backup taken immediately before any upgrade — the upgrade guide covers this, but it bears repeating.
  • Systemd service confirmed to restart on failure — The installer sets Restart=always. Verify with systemctl cat temps | grep Restart.

Database

  • TEMPS_DB_MAX_CONNECTIONS tuned for your server size — on servers with 2 GB RAM, reduce this to 20–30. See Environment Variables.
  • Database on a dedicated server or managed service if running 10+ apps — the database competing with container workloads for RAM is the most common production bottleneck. See Resources.

Recovery

  • You can SSH into the server without the Temps dashboard — if the control plane is down, you need another way in.
  • You know how to restart the service — sudo systemctl restart temps.
  • You have the backup restore command bookmarked — a production incident is the wrong time to find the docs.

For multi-server setups, see Multi-Node for control-plane recovery procedures.

Was this page helpful?