TempsTemps
On this page
  1. Transport Security
  2. Access Control
  3. Bot Protection
  4. Application Security
  5. Best Practices
  6. Compliance
  7. Reporting Security Issues

Security Overview

Temps is self-hosted, which means every layer of security runs on your own infrastructure. This page covers the protections Temps applies automatically — from TLS certificates and security headers to IP access control and bot protection — and what you need to configure.

Transport Security

For authentication (login methods, password reset, MFA), role-based access control, data encryption, and audit logging, see the dedicated pages in this section.

Automatic SSL/TLS

Temps issues and renews Let's Encrypt certificates automatically for every custom domain — no certificate management required. Modern TLS versions (1.2 and 1.3) are supported. Every response includes a Strict-Transport-Security header with includeSubDomains to enforce HTTPS across all subdomains. You can attach unlimited custom domains per project. Point your domain to your Temps server and SSL is configured automatically.

Cluster mutual TLS (multi-node)

In a multi-node cluster, the control plane and worker agents can authenticate each other with mutual TLS in addition to bearer tokens. When enabled (multi_node.require_mtls), the control plane runs a per-cluster CA — its private key encrypted at rest and never leaving the control plane — and signs a per-node certificate for each worker. Each node generates its own key pair locally (the private key is never transmitted), and joins can pin the CA fingerprint with --ca-fingerprint to defeat a man-in-the-middle. It is off by default and rolls out observe-then-enforce. See Multi-node → Mutual TLS.

Access Control

Control Plane Admin Surface

The Temps control plane can split its HTTP surface across two listeners so admin/management routes bind to a private interface while public ingest endpoints stay reachable. See the Admin Listener guide for configuration, deployment recipes (SSH tunnel, Tailscale, reverse proxy), and the route classification.

Worker-Node Enrollment

Worker nodes join a multi-node cluster with single-use enrollment tokens: short-lived (1 h default, 24 h max), optionally bound to a specific node name, and stored only as a SHA-256 hash (the plaintext is shown once at mint time). Expired, revoked, or exhausted tokens are rejected outright with no fallback to the legacy shared token, and the registration endpoint is rate-limited per-IP. See Multi-node → Securing node enrollment.

IP Access Control

  1. 1

    Go to your project

  2. 2

    Open Settings → Security

  3. 3

    Add entries to the Allow List or Block List

  4. 4

    Click Save — no restart required, changes propagate to the edge within ~30 seconds

An allow list restricts your application to specific IP addresses or CIDR ranges — useful for internal tools and admin surfaces where only known IPs should connect. A block list drops traffic from known bad IPs or ranges, letting you respond quickly to targeted attacks. No restart is required; changes propagate to the edge within about 30 seconds. Configure them per project in Settings → Security.

OIDC SSO Security

The OIDC SSO login flow generates a server-side state token, a nonce, and a PKCE code challenge before redirecting to the identity provider, and validates all three when the IdP calls back (temps-auth/src/oidc_service.rs:539-556,678-701). The redirect_uri is pinned to the console's own callback route and validated before the authorize URL is built (oidc_service.rs:976-987). Requests to the IdP's issuer are blocked from resolving to private, link-local, or CGNAT IP ranges — re-checked at connect time to close off DNS-rebinding — so issuer discovery can't be abused to reach internal services or cloud metadata endpoints (oidc_service.rs:1018-1213, BlocklistResolver at :92-113). Callback failures return a short opaque error code to the browser instead of the IdP's raw error text, so failure detail never leaks into the URL bar, browser history, or Referer header (oidc_handler.rs:150-256). The per-provider trust_idp_email flag defaults to false; enabling it bypasses the email_verified verification gate but not the underlying record, and every bypass is logged (oidc_service.rs::resolve_user, migration m20260526_000002_add_trust_idp_email_to_oidc_providers).

Bot Protection

CAPTCHA Challenge

  1. 1

    Go to your project

  2. 2

    Open Settings → Security

  3. 3

    Toggle CAPTCHA Challenge on

  4. 4

    Click Save

Protect your applications from automated traffic:

  • Automatic Detection — Triggers on suspicious traffic patterns
  • Manual Trigger — Enable per project or domain at any time
  • Session-Based — Users solve the challenge once per session, not per request

When it triggers:

  • High request rate from a single IP
  • Suspicious traffic patterns detected by the proxy
  • Manual configuration for public-facing registration or contact forms
  • Repeated failed login attempts

Application Security

Temps automatically adds the following protections to every deployed application:

Security Headers

HeaderValuePurpose
Content-Security-PolicyconfigurableRestrict allowed content sources
X-Frame-OptionsDENYPrevent clickjacking
Strict-Transport-Securitymax-age=…; includeSubDomainsEnforce HTTPS
Referrer-PolicyconfigurableControl referrer information sent to other sites

Automatic Protections

  • Input Validation — All inputs validated at the API layer
  • SQL Injection Prevention — Parameterized queries throughout
  • XSS Protection — Output encoding on all rendered content
  • OIDC Login CSRF Protection — The OIDC login flow uses a state parameter to protect against CSRF

Best Practices

For Your Account

  • Enable Two-Factor Authentication (TOTP) on your account
  • Use magic links or SSO instead of passwords where possible
  • Review and revoke unused API keys regularly
  • Monitor the Audit Log for unexpected activity

For Your Applications

  • Use IP Allow Lists for internal tools and admin surfaces
  • Enable CAPTCHA for public-facing apps that are under bot pressure
  • Store sensitive values as secrets (encrypted env vars), not plain environment variables
  • Keep Temps updated — security patches ship in every release

For Your Infrastructure

  • Bind the admin listener to a private interface or VPN (see Admin Listener)
  • Use strong database passwords and restrict database network access
  • Back up your data regularly (see Backups)

Compliance

Data Privacy

Because Temps is self-hosted, you control all data:

  • Data stays on your own infrastructure — nothing is sent to third-party servers by default
  • Export your data at any time via API or database access
  • Delete data at any time; Temps does not retain copies

GDPR & Privacy

  • Data Minimization — Temps collects only what is necessary to operate the platform
  • User Consent — Integrate your own consent management; Temps does not impose one
  • Right to Access & Deletion — All user data is accessible and deletable via the API
  • Data Portability — Export data in standard formats (JSON, CSV)

Reporting Security Issues

If you discover a security vulnerability in Temps, please report it privately:

  • Do not post publicly until a fix is available
  • Email [email protected] with a description of the issue
  • Allow reasonable time for a fix before any public disclosure

We follow responsible disclosure principles and aim to respond within 48 hours.

Was this page helpful?