Auto-hébergement

Globatics, c’est une application Node.js et une base PostgreSQL. Sans URL de base de données, il fait tourner un PostgreSQL embarqué (PGlite) dans un dossier local : il n’y a rien d’autre à installer. Ni file d’attente, ni cache. Un petit serveur virtuel suffit pour commencer, et il fonctionne aussi sur Vercel avec Supabase.

Prérequis#

• Node.js 22.13 ou plus récent, 24 LTS recommandé.
• PostgreSQL 17 (n’importe quel hébergeur, Supabase compris) renseigné dans DATABASE_URL, ou un disque persistant pour la base embarquée.
• De la place pour les données. À titre indicatif, 90 jours d’historique à environ 4 000 sessions par jour (356 000 sessions et 1,1 million d’événements) occupent environ 800 Mo.
• HTTPS en frontal pour la production (n’importe quel reverse proxy, ou une plateforme qui gère le TLS).

Lancer avec Node.js#

# dans votre copie du dépôt Globatics
npm ci
NEXT_PUBLIC_APP_URL=https://analytics.example.com npm run build

DATABASE_URL=postgres://user:password@host:5432/postgres \
NEXT_PUBLIC_APP_URL=https://analytics.example.com \
npm start            # écoute sur le port 3000 (PORT=8080 pour le changer)

Au premier démarrage, la base de données est créée et migrée. Ouvrez le serveur dans un navigateur, créez votre compte et ajoutez votre premier site. Lancez-le sous un gestionnaire de processus (systemd, pm2…) pour qu’il redémarre avec la machine.

Lancer avec Docker#

Le dépôt fournit un Dockerfile de production (multi-étapes, Node.js 24) : il construit le script de suivi et l’application, puis lance next start avec un utilisateur sans privilèges, migre la base au démarrage, et un contrôle de santé appelle /api/health. Avec DATABASE_URL, vous pouvez lancer autant de conteneurs que vous le souhaitez. Sans elle, la base embarquée réside dans le volume /app/data : lancez un seul conteneur par volume.

docker build -t globatics --build-arg NEXT_PUBLIC_APP_URL=https://analytics.example.com .

docker run -d --name globatics --init --restart unless-stopped \
  -p 3000:3000 \
  -e DATABASE_URL=postgres://user:password@host:5432/postgres \
  -e GLOBATICS_TRUST_PROXY=1 \
  globatics

Variables d’environnement#

Derrière un reverse proxy#

Définissez GLOBATICS_TRUST_PROXY=1 et assurez-vous que le proxy transmet l’adresse du visiteur, sinon chaque visiteur se voit attribuer la localisation du proxy. La vue en direct utilise les Server-Sent Events : ne les mettez pas en mémoire tampon.

analytics.example.com {
	reverse_proxy localhost:3000
}

Connexion avec Google#

« Continue with Google » apparaît sur les pages de connexion et d’inscription dès que GOOGLE_CLIENT_ID et GOOGLE_CLIENT_SECRET sont définies. Sans elles, le bouton est masqué et les routes Google répondent 404. La connexion repose sur OpenID Connect (code d’autorisation avec PKCE) et ne demande que le nom et l’adresse e-mail vérifiée.

• Dans la console Google Cloud, ouvrez API et services → Identifiants, créez un ID client OAuth de type Application Web, et configurez l’écran de consentement (nom de l’application, e-mail d’assistance, les champs d’application openid, email et profile).
• Origine JavaScript autorisée : votre origine publique, par exemple https://analytics.example.com.
• URI de redirection autorisé : https://analytics.example.com/api/auth/google/callback, à l’identique (schéma, hôte, sans barre oblique finale).
• Définissez les deux variables et redémarrez. L’URI de redirection est construit à partir de l’origine publique (GLOBATICS_PUBLIC_URL, puis NEXT_PUBLIC_APP_URL, puis le domaine de production Vercel), jamais à partir d’une URL de déploiement Vercel : il correspond donc à ce que vous avez enregistré.

GOOGLE_CLIENT_ID=1234567890-abc.apps.googleusercontent.com
GOOGLE_CLIENT_SECRET=GOCSPX-…

Un compte Google dont l’e-mail vérifié correspond à un compte existant y est rattaché à la première utilisation ; sinon, un nouveau compte est créé, sans mot de passe. Les utilisateurs gèrent ce rattachement, ou définissent un mot de passe, dans Account → Connected accounts.

Les offres sur votre serveur#

L’application auto-hébergée a les mêmes offres et limites que Cloud, et rien à acheter : aucun paiement n’est configuré, donc par défaut un compte bénéficie de l’essai de 7 jours, puis il est verrouillé. Pour désactiver la facturation, définissez GLOBATICS_BILLING=off et redémarrez : chaque compte obtient toutes les fonctionnalités, sans quota d’événements, sans essai, sans paywall, et ses données ne sont jamais supprimées faute d’offre.

Pour garder la facturation active et décider compte par compte, attribuez à vos propres comptes l’offre dont ils ont besoin (starter, pro ou business, qui inclut toutes les fonctionnalités) avec une seule requête SQL :

UPDATE globatics.users
SET plan = 'business', plan_source = 'complimentary'
WHERE email = 'you@example.com';

La modification s’applique sous 30 secondes, et aucun événement ni essai ultérieur ne la modifie. Il faut un client SQL sur PostgreSQL (DATABASE_URL) ; la base embarquée n’a pas de console SQL. Voir Offres et limites pour le contenu de chaque offre.

Sauvegardes#

Tout se trouve dans le schéma globatics de votre base de données. Faites-en une copie cohérente sans arrêter le serveur (ou utilisez les sauvegardes de votre hébergeur, comme celles de Supabase) :

pg_dump "$DATABASE_URL" --schema=globatics --format=custom \
  --file="backups/globatics-$(date +%F).dump"

Pour restaurer, arrêtez le serveur et lancez pg_restore --clean --dbname="$DATABASE_URL" sur la sauvegarde. Avec la base embarquée, arrêtez le serveur et copiez son dossier (GLOBATICS_PGLITE_DIR).

Mises à jour#

git pull
npm ci
npm run build
# redémarrez le processus : les migrations de la base s’exécutent automatiquement au démarrage

Faites une sauvegarde avant toute mise à jour. Des questions sur ce qui est enregistré ? Voir Champs de données et confidentialité.