Nautilus par Verne Software
Nautilus est un produit unique pour les tâches de backend dont la plupart des applications ont besoin et que peu d'équipes ont envie de construire : la connexion et la gestion des utilisateurs, la livraison de webhooks, les tâches planifiées, et la connexion de vos utilisateurs par Telegram. Vous les obtenez depuis un seul hôte d'API (https://api.vernesoft.com), un seul tableau de bord, un seul compte et une seule offre, et vous les appelez depuis votre propre serveur avec les SDK officiels ou en HTTP simple.
Ce que vous pouvez en faire
| Tâche | Ce que cela couvre | Pour commencer |
|---|---|---|
| Connexion et utilisateurs | Inscription et connexion de vos utilisateurs finaux, connexion sociale, double authentification, sessions et gestion des utilisateurs. | Connexion et utilisateurs |
| Livraison de webhooks | Envoi d'événements de votre application vers les endpoints de vos clients, avec nouvelles tentatives, signatures et journal de livraison. | Livraison de webhooks |
| Tâches cron | Appels HTTP récurrents ou ponctuels, à l'horaire que vous fixez, avec nouvelles tentatives et historique d'exécution. | Tâches cron |
| Connexion Telegram | Connexion sans mot de passe pour vos utilisateurs finaux, par l'intermédiaire d'un bot Telegram qui vous appartient. | Connexion Telegram |
Chaque tâche est servie par sa propre API, et l'API garde son nom : l'API Gate (/v1/gate/*) pour la connexion et les utilisateurs, l'API Relay (/v1/relay/*) pour les webhooks, l'API Clockwork (/v1/clockwork/*) pour les tâches cron, et l'API Passepartout (/v1/passepartout/*) pour la connexion Telegram. Ces noms et ces chemins sont le contrat sur lequel votre code est écrit ; ils apparaissent donc dans les pages de référence, même si les sections portent le nom de la tâche. Une clé d'API commence par vrn_, suivi de caractères aléatoires, et porte un ensemble de scopes, un par API (gate, relay, clockwork, passepartout), que vous cochez à sa création ; voir Clés d'API.
Comment cette documentation est organisée
La barre latérale suit l'ordre dans lequel la plupart des équipes adoptent le produit :
- Présentation du produit – cette page, l'installation des SDK et un seul tableau de tous les endpoints.
- Connexion et utilisateurs – les utilisateurs, les flux de connexion, la connexion sociale, la double authentification, les sessions, les métadonnées, les webhooks des événements d'identité et la suppression automatique des comptes inactifs.
- Livraison de webhooks – la publication d'événements et leur livraison.
- Tâches cron – les tâches récurrentes et différées, et leur historique d'exécution.
- Connexion Telegram – la connexion sans mot de passe par Telegram.
- Clés d'API et offres – le fonctionnement des clés d'API, ce que comprend chaque offre, et ce que reçoit votre code quand une limite est atteinte.
Chaque section de tâche a une introduction et une référence d'API avec les endpoints, les paramètres et les schémas de réponse, des exemples curl et, quand c'est utile, un usage des SDK.
Principes d'ingénierie
Chez Verne Software, nous traitons Nautilus comme un Umbrella SaaS : un plan de contrôle unique qui orchestre plusieurs plans de données spécialisés.
Nous appliquons une séparation stricte des responsabilités :
- Dumb Pipes, Smart Endpoints – le réseau reste simple ; l'intelligence se trouve dans des services bien définis.
- Control Plane vs Data Plane – le provisionnement, la gestion des identités et des accès, et la facturation sont isolés du traitement des requêtes sur le chemin critique.
- Documentation as a First-Class Surface – chaque primitive exposée par Nautilus a un contrat versionné et testable, sur lequel vous pouvez vous appuyer en confiance.
Côté infrastructure :
- Passerelle edge – 100 % du trafic public de l'API entre par notre passerelle en Rust (Actix + Dragonfly). Elle authentifie les clés d'API et applique les limites de débit et les limites d'offre à l'edge.
- Isolation multi-tenant – chaque requête d'API est rattachée à son tenant à l'edge, et le cœur limite ses requêtes à ce tenant.
- Cœur découplé – la Core Platform joue le rôle de « cerveau » : elle gère le provisionnement, les identités, les limites d'offre et la facturation au nombre d'utilisateurs actifs par mois, et garde les opérations lourdes hors du chemin de l'edge.
Sur quoi repose chaque API
Chaque API tourne sur son propre plan de données, sans exposition directe à l'internet public :
- Connexion et utilisateurs (API Gate) – gestion des identités et flux d'authentification, avec Ory Kratos. Adaptée aux tenants SaaS B2B et aux consoles d'exploitation.
- Livraison de webhooks (API Relay) – construite sur Svix et sur des files PostgreSQL dédiées, pour une livraison d'événements durable, avec nouvelles tentatives et observabilité.
- Tâches cron (API Clockwork) – un planificateur Rust développé en interne pour les tâches différées et récurrentes, avec une logique de nouvelles tentatives et un historique d'exécution.
- Connexion Telegram (API Passepartout) – permet à vos utilisateurs finaux de se connecter avec Telegram : connexion sans mot de passe, identités propres à chaque tenant dans Ory Kratos, et jetons de bot chiffrés par tenant.
Infrastructure et exploitation
Nous traitons l'infrastructure comme du code et nous visons la fiabilité et la prévisibilité :
- Hébergement et réseau – Nautilus tourne sur des environnements VPS hautes performances (stockage NVMe, vCores évolutifs). Traefik sert de reverse proxy edge, pour le routage automatique des sous-domaines et la gestion des certificats Let’s Encrypt.
- Pipeline CI/CD – GitHub Actions construit les binaires Rust et les front-ends Vue dans des images Docker compactes (Alpine/Distroless). Les déploiements exécutent
docker compose pull && docker compose up -d, ce qui redémarre les services dont l'image a changé.
Du point de vue d'un développeur, cela signifie :
- la même configuration de conteneurs en développement local et en production,
- un comportement de déploiement prévisible,
- et des modes de défaillance documentés, que vous pouvez anticiper.