Temps vs RustRak : deux alternatives Rust à Sentry en 2026

Après avoir exploré les alternatives à Sentry dans mon précédent article sur Sentry, je voulais approfondir deux solutions qui ont retenu mon attention : Temps et RustRak.

Depuis quelque temps, j'ai adopté une règle simple : avant d'adopter un outil, je vérifie s'il existe une alternative en Rust. Le langage offre des performances remarquables, une consommation mémoire ridicule et une fiabilité que j'apprécie de plus en plus dans ma stack. Cet article est le premier d'une série où je compare les alternatives Rust aux outils établis.

Si tu cherches une alternative à Sentry écrite en Rust, deux noms reviennent en 2026 : Temps et RustRak. Les deux sont compatibles avec les SDK Sentry, légères, performantes, et parfaitement adaptées à l'auto-hébergement. Mais elles répondent à des besoins très différents.

Cet article les compare point par point pour t'aider à choisir selon ton projet.

Présentation des deux solutions

Temps

Temps est une plateforme PaaS complète écrite en Rust. Son objectif : remplacer plusieurs services SaaS (Vercel, Sentry, PostHog, FullStory) par une seule plateforme auto-hébergée. Il inclut :

• Déploiements git-push (comme Vercel)
• Error tracking compatible Sentry (drop-in DSN)
• Session replay
• Analytics
• Uptime monitoring
• SSL automatique

Avec ses 506 ⭐ sur GitHub, Temps est le projet le plus visible des deux. Il propose une version cloud à ~6$/mois et un auto-hébergement gratuit. Le binaire Rust est accompagné d'une stack TypeScript pour le frontend.

RustRak

RustRak est un serveur d'error tracking ultra-léger et spécialisé. Rien d'autre : pas de PaaS, pas d'analytics, pas de session replay. Juste de l'error tracking compatible Sentry, fait pour être performant et discret :

• ~50 Mo de mémoire en fonctionnement
• <50 ms de latence P99 à l'ingestion
• 10 000+ événements/seconde
• SQLite par défaut (zéro dépendance) ou PostgreSQL
• Binaire unique, pas de Redis nécessaire
• Licence GPL-3.0

Avec 61 ⭐ sur GitHub, RustRak est plus récent et plus confidentiel, mais techniquement impressionnant par sa légèreté.

Tableau comparatif

Quand choisir Temps ?

• Tu veux remplacer plusieurs outils à la fois : Sentry + Vercel + PostHog + FullStory. Temps est ta solution tout-en-un.

• Tu as besoin de déployer des apps Next.js avec git-push, SSL automatique et monitoring intégré.

• Tu veux du session replay sans payer FullStory ou LogRocket.

• Le modèle cloud managé à 6$/mois te convient pour ne pas gérer l'infrastructure toi-même.

• Tu développes des agents IA et veux le support du protocole MCP.

Quand choisir RustRak ?

• Tu veux juste de l'error tracking, rien d'autre. Pas de PaaS, pas d'analytics, pas de surcharge.

• Tu as besoin de performances extrêmes : latence <50ms, 10k+ events/s, 50 Mo de RAM.

• Tu veux du zéro dépendance : SQLite par défaut, pas de Redis, un binaire unique.

• Ton infrastructure est contrainte en ressources (Raspberry Pi, petit VPS, edge).

• La licence GPL-3.0 est compatible avec ton projet.

Et si tu veux les deux ?

Rien ne t'empêche d'utiliser Temps pour le hosting et le session replay, tout en gardant RustRak comme backend d'error tracking dédié pour les workloads critiques. Les deux étant compatibles Sentry, tu peux même basculer l'URL DSN d'un SDK entre les deux sans changer ton code.

Installation rapide

Temps (auto-hébergé)

# docker-compose.yml complet disponible sur temps.sh
# Stack : Rust + TypeScript + PostgreSQL + Redis
git clone https://github.com/gotempsh/temps
cd temps
docker compose up -d

L'interface d'administration est disponible sur le port configuré (par défaut 3000). La configuration du DSN Sentry se fait dans les paramètres du projet.

RustRak (SQLite, zéro dépendance)

version: "3"
services:
  server:
    image: rustrak/rustrak-server:latest
    ports:
      - "8080:8080"
    volumes:
      - rustrak_data:/data
    environment:
      - SESSION_SECRET_KEY=${SESSION_SECRET_KEY}
      - CREATE_SUPERUSER=${CREATE_SUPERUSER}
    restart: unless-stopped

  ui:
    image: rustrak/rustrak-ui:latest
    ports:
      - "3000:3000"
    environment:
      - RUSTRAK_API_URL=http://server:8080
    depends_on:
      - server
    restart: unless-stopped

volumes:
  rustrak_data:

SESSION_SECRET_KEY=$(openssl rand -hex 32)
CREATE_SUPERUSER=admin@example.com:changeme123
docker compose up -d

RustRak tourne avec deux conteneurs (server + UI) et SQLite en stockage local. Pas de PostgreSQL, pas de Redis. L'URL DSN Sentry à configurer dans ton app est : http://localhost:8080

Migration depuis Sentry

Les deux outils acceptent les SDK Sentry existants. La migration se résume à changer l'URL DSN :

// Avant (Sentry)
const Sentry = require("@sentry/node");
Sentry.init({ dsn: "https://key@o0.ingest.sentry.io/project" });

// Après (Temps ou RustRak)
Sentry.init({ dsn: "https://key@localhost:8080/project" });

Aucune modification de code supplémentaire. Les SDK Sentry continuent de fonctionner exactement comme avant — les erreurs partent simplement vers ton serveur auto-hébergé au lieu du cloud Sentry.

Verdict

Mon conseil : si tu veux juste te débarrasser de Sentry sans changer ta stack, RustRak est le choix le plus simple : 50 Mo, SQLite, zéro configuration, compatible DSN. Si tu veux en profiter pour consolider tout ton stack (hosting, analytics, monitoring), Temps est clairement plus ambitieux et peut remplacer 4 services à lui seul.

Les deux étant écrits en Rust et compatibles Sentry, tu peux aussi les essayer l'un après l'autre en changeant une URL DSN. Le meilleur des deux mondes ? Peut-être garder RustRak pour l'error tracking pur et Temps pour le reste.

Article rédigé par Aplix — développeur full-stack (Laravel, Vue.js, Nuxt). Tu peux me suivre sur blogs.aplix.nl pour plus de comparatifs et de retours d'expérience.