Production checklist

Every production Temps instance needs these six things wired up before it handles real traffic. Verify each item using the linked page; the checklist is ordered by the cost of getting it wrong.

Initial setup

• Setup wizard completed — confirm setup_complete is set in your instance. If the setup wizard was interrupted or skipped, some system defaults (admin account, domain configuration, TLS) may not be fully applied. You can verify by visiting the console root — an incomplete setup will redirect you back to the wizard.

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

• HTTPS configured per domain during setup — the setup wizard now lets you configure HTTPS for each domain at install time. If you skipped this step or added domains afterwards, you can configure TLS from the console. See Custom Domains & SSL.
• 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 by opening a fresh ACME order for each renewal cycle; verify port 80 remains open to the internet so HTTP-01 challenges succeed on every renewal attempt, not just the initial issuance.
• No "unclassifiable challenge" warnings in the dashboard — if the SSL status card shows an "unclassifiable challenge" warning, the ACME HTTP-01 challenge response could not be validated (usually because port 80 is firewalled, a CDN is stripping the .well-known/acme-challenge/ path, or DNS is not yet pointing to this server). Resolve the underlying routing issue and trigger a manual renewal from Project → Domains to clear the warning before going live.

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.
• TEMPS_DATABASE_URL set as an env var, not a CLI flag — passing --database-url exposes the database password in ps/pgrep output, visible to all users on the server. Use export TEMPS_DATABASE_URL=... in your systemd unit's EnvironmentFile instead. See Database Configuration.

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. The restore flow is bunx @temps-sdk/cli services restore (test it against a staging environment first); see Restore from a backup.

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