Démarrez un backend PocketBase à version fixe, avec son API, son authentification, ses abonnements en temps réel, son stockage de fichiers et son interface d’administration protégée par des identifiants générés.
Version candidate
PocketBase
SOURCE
Git
REGION
de
ROUTE
HTTPS
01Source reçue
02Compilation terminée
03Environnement d’exécution démarré
04Vérification de santé réussie
Route promue en production
production.adios.run
Une mise en production adaptée à
Le parcours de mise en production
L’application ou le service ne représente qu’une partie de la production. Les résultats de compilation, l’état d’exécution, les contrôles de santé, les secrets, les journaux, les routes et la version promue doivent pouvoir être examinés ensemble.
Le modèle officiel télécharge PocketBase 0.40.2 pour amd64 ou arm64, vérifie sa somme de contrôle fixée, génère une clé de chiffrement et un mot de passe superutilisateur, et crée le premier administrateur de manière idempotente.
La base SQLite, les fichiers téléversés, les paramètres et les sauvegardes locales partagent un seul volume persistant /app/pb_data. Le modèle utilise volontairement une seule réplique pour conserver la cohérence de cet état.
Utilisez /api/health pour vérifier la disponibilité, ouvrez /_/ pour l’administration et sauvegardez le volume de données avec les secrets stables de chiffrement et du superutilisateur.
Du code source à la mise en production
Utilisez le code source et le fonctionnement en production déjà définis pour le projet. Le manifeste décrit ce que la plateforme doit compiler ou provisionner et les critères à remplir pour que le résultat soit prêt.
Importez le dépôt existant, ou examinez et déployez l’une des variantes de modèles précisément référencées ci-dessous.
$adios loginConsignez dans adios.yaml les commandes, la version de l’environnement d’exécution ou du service, les critères de santé et les références aux secrets.
$git diff -- adios.yamlSuivez les résultats de compilation et d’exécution, vérifiez la version candidate, puis ouvrez la route ou la connexion de service promue en production.
$adios uptype: api
replicas: 1
env:
PB_ENCRYPTION_KEY: secret://PB_ENCRYPTION_KEY
PB_SUPERUSER_EMAIL: admin@pocketbase.local
PB_SUPERUSER_PASSWORD: secret://PB_SUPERUSER_PASSWORD
secrets:
PB_ENCRYPTION_KEY: secret://generate:32
PB_SUPERUSER_PASSWORD: secret://generate:32
build_cmd: sh /app/install-pocketbase.sh
start_cmd: sh /app/start-pocketbase.sh
port: 8090
runtime:
health_path: /api/health
volumes:
- name: pocketbase-data
target: /app/pb_data
persistent: truePoints de départ déployables
Examinez le modèle PocketBase complet, clonez son dépôt autonome ou déployez-le directement avec la clé publique pocketbase.
Applications Web
PocketBase 0.40.2 avec données SQLite persistantes, identifiants de superutilisateur générés et API intégrées d’authentification et de temps réel.
git clone https://github.com/adiosdotdev/template-pocketbase.git
cd template-pocketbase
adios upAvant production
Pour sécuriser la première mise en production, partez d’une compilation ou d’une configuration de service reproductible et d’un aperçu qui sollicite les dépendances réellement utilisées en production.
Les réponses à vos questions
Vérifiez les limites de l’environnement d’exécution ou du service, le chemin du modèle, le comportement en cas d’échec et les contrôles de production avant de créer la première version.
Oui. Choisissez le modèle PocketBase correspondant à la version ou à la configuration souhaitée, stockez les identifiants dans des secrets Adios et déployez-le depuis la console ou avec adios up.
La base SQLite, les fichiers téléversés, les paramètres et les sauvegardes locales partagent un seul volume persistant /app/pb_data. Le modèle utilise volontairement une seule réplique pour conserver la cohérence de cet état.
Ouvrez /_/ sur la route HTTPS générée. Le modèle crée admin@pocketbase.local et enregistre son mot de passe généré dans un secret Adios.
Pas en toute sécurité avec cette configuration basée sur SQLite local et le stockage de fichiers. Elle utilise volontairement une seule réplique ; choisissez une autre architecture si l’application nécessite un état backend répliqué horizontalement.
Stockez les valeurs sensibles dans les secrets Adios et référencez-les avec secret://NAME. Ne placez pas les identifiants de production directement dans adios.yaml et ne les enregistrez pas dans Git.
Vérifiez l’authentification, la connectivité applicative, les écritures et lectures, la persistance après redémarrage, les besoins de sauvegarde ou de restauration, la capacité et le comportement en cas d’échec de chaque application dépendante.
Autres options de déploiement
Déployez le frontend, l’API ou le worker qui se connecte à Supabase. Adios exécute la version de l’application ; votre projet Supabase reste le service externe de base de données et de backend.
Déployez un processus web ou un worker Node.js persistant à partir de ses scripts de packages existants, avec les contrôles de santé de la version, les journaux, les secrets, le routage et l’historique Git associés.
Choisissez une version de PostgreSQL, conservez les identifiants de la base de données hors de Git, ajoutez un stockage persistant, connectez l’application et vérifiez les données après un redémarrage.
Publiez du HTML, du CSS, du JavaScript ou une compilation statique générée par un framework à partir d’un petit modèle Nginx, avec les routes, les domaines, TLS et l’état de la version associés.
La première version
Partez du dépôt ou d’un modèle, vérifiez le contrat de déploiement et examinez la version qui sera promue en production.