Comment auto-héberger Actual Budget en 2026 : synchronisation, HTTPS et sauvegardes des données financières

Un déploiement Actual Budget en échec ne se traduit pas toujours par un crash. Il peut afficher une page de connexion alors que le répertoire de synchronisation est éphémère ou qu’un proxy supprime les requêtes de synchronisation volumineuses. Commencez plutôt par une vérification de bout en bout : créez ou importez un budget, ajoutez des transactions, synchronisez un second navigateur et produisez un export au niveau de l’application.

Cette vérification correspond à la vocation répertoriée d’Actual Budget : la gestion budgétaire par enveloppes, avec des données conservées sur votre disque. Elle révèle également plus tôt les dépendances manquantes, les hypothèses incorrectes sur le proxy et les données éphémères qu’un simple test de disponibilité.

Séparer Actual Budget de ses dépendances

Commencez par l’espace de noms réseau d’Actual Budget : son listener web utilise le port 5006, et non un port hôte copié depuis un tutoriel pour ordinateur portable. L’exigence du runtime local se résume à un volume de données durable et à un navigateur compatible pour la configuration initiale. Explicitez son cycle de vie afin que le déplacement d’Actual Budget entre différents hôtes ne modifie pas son comportement silencieusement.

Une fois cette exigence satisfaite, exécutez le scénario complet — créez ou importez un budget, ajoutez des transactions, synchronisez un second navigateur et produisez un export au niveau de l’application. Consignez les logs et les mesures concernant la taille des fichiers de budget, le trafic de synchronisation et le stockage du serveur, plutôt que des calculs lourds côté serveur. Ces éléments constituent la première architecture validée et rendent testables les déplacements ultérieurs entre le compute Dockup et un serveur attaché.

Exécuter une première instance représentative de la production

Une commande minimale est utile lorsqu’elle révèle ce que la plateforme prendra ensuite en charge.

docker run -d \
  --name actual-budget \
  --restart unless-stopped \
  -p 127.0.0.1:5006:5006 \
  -v actual-budget-data:/data \
  -e ACTUAL_PORT=5006 \
  actualbudget/actual-server:latest

Ici, le port 5006 reste privé sur l’hôte et chaque chemin requis est explicite. Confirmez l’exigence locale avant toute exposition : un volume de données durable et un navigateur compatible pour la configuration initiale. Vérifiez le démarrage à la fois dans les logs et avec une preuve propre à l’application : créez ou importez un budget, ajoutez des transactions, synchronisez un second navigateur et produisez un export au niveau de l’application. Une fois la vérification terminée, verrouillez la version de l’image afin qu’un remplacement courant ne modifie pas silencieusement le comportement.

Rendre l’origine publique non ambiguë

Choisissez le hostname Actual Budget définitif avant que les utilisateurs n’enregistrent des callbacks ou des paramètres client, puis utilisez une URL HTTPS stable afin que les clients de synchronisation fassent confiance au serveur. La route de la plateforme doit terminer TLS une seule fois et cibler le port privé 5006.

Exécutez la transaction d’acceptation depuis l’extérieur. Si le client n’atteint jamais Actual Budget, utilisez la checklist de validation SSL pour vérifier le DNS et le certificat. Si la requête atteint Actual Budget mais que le répertoire de synchronisation est éphémère ou qu’un proxy supprime les requêtes de synchronisation volumineuses, cessez de modifier les redirections du proxy et examinez plutôt la limite propre à l’application.

Rendre mesurable la récupération d’Actual Budget

Créez un manifeste de récupération pour Actual Budget : les fichiers du serveur ainsi que des exports de budget périodiques au niveau de l’application. Montez /data avant le bootstrap, écrivez des données d’exemple inoffensives et remplacez le conteneur pour prouver que ce chemin est réellement persistant. Vérifiez dès maintenant les permissions et l’espace libre, car un chemin monté mais non accessible en écriture se comporte exactement comme une absence de persistance.

Effectuez les sauvegardes dans un failure domain distinct du serveur en fonctionnement. Recréez Actual Budget à partir de son image dont la version est verrouillée et vérifiez que le serveur restauré synchronise les mêmes comptes et soldes et que l’export indépendant peut également être importé. Le guide des volumes persistants vous aide à traduire cet exercice en politique de snapshots et de rétention.

Sécuriser Actual Budget après le bootstrap

Les identifiants de bootstrap sont temporaires ; le modèle de confiance est permanent. Avec Actual Budget, veillez à ne pas publier un serveur financier avant d’avoir configuré son mot de passe, et définissez le mot de passe du serveur avant toute exposition. Utilisez HTTPS, car l’instance contient un historique financier complet.

ACTUAL_PORT contrôle le comportement, pas la confidentialité ; validez son type et sa valeur, et stockez séparément les véritables identifiants Actual Budget. Exécutez l’image sans capabilities Linux inutiles et n’exposez que la route de l’application publique. Gardez l’activité des administrateurs visible sans enregistrer de valeurs secrètes.

Exploiter Actual Budget en fonction de son véritable goulot d’étranglement

Construisez les dashboards autour de la taille des fichiers de budget, du trafic de synchronisation et du stockage du serveur, plutôt qu’autour de calculs lourds côté serveur. Un graphique CPU dépourvu de ce contexte de charge ne peut pas expliquer pourquoi Actual Budget est lent. Ajoutez un test synthétique ou planifié qui tente de créer ou d’importer un budget, d’ajouter des transactions, de synchroniser un second navigateur et de produire un export au niveau de l’application avec des données de test inoffensives.

Avant une mise à niveau, tenez compte de ce risque propre à l’application : les migrations de données d’Actual doivent être testées avec les fichiers du serveur et un budget exporté disponibles pour un rollback. Restaurez une sauvegarde récente dans un déploiement isolé, exécutez-y les migrations et comparez le comportement. Si le répertoire de synchronisation est éphémère ou qu’un proxy supprime les requêtes de synchronisation volumineuses, examinez la limite concernée — origine publique, stockage ou dépendance — avant de modifier des paramètres sans rapport.

Éléments à recueillir avant la mise en production d’Actual Budget

Créez une fixture Actual Budget réduite et jetable, et conservez-la pour chaque release. Cette fixture doit reproduire le workflow réel : créer ou importer un budget, ajouter des transactions, synchroniser un second navigateur et produire un export au niveau de l’application. Consignez le digest de l’image, le hostname externe, l’adresse de la dépendance et le résultat attendu afin qu’un opérateur puisse répéter le test ultérieurement sans devoir interpréter ce guide.

Exécutez la fixture trois fois. Premièrement, utilisez le déploiement vierge. Deuxièmement, remplacez le conteneur sans toucher à l’état durable. Troisièmement, restaurez la sauvegarde dans un environnement vide. Le troisième passage n’est réussi que lorsque le serveur restauré synchronise les mêmes comptes et soldes et que l’export indépendant peut également être importé. Pendant chaque passage, mesurez la latence et l’utilisation des ressources autour de la taille des fichiers de budget, du trafic de synchronisation et du stockage du serveur, plutôt que des calculs lourds côté serveur ; ces données deviennent la référence des alertes, au lieu d’un pourcentage CPU arbitraire.

Enfin, testez volontairement le chemin négatif : envoyez une entrée inoffensive proche de la limite de ressource ou de format associée à cette limite : le répertoire de synchronisation est éphémère ou un proxy supprime les requêtes de synchronisation volumineuses. Vérifiez qu’Actual Budget échoue de manière visible sans corrompre l’état, rétablissez la condition correcte et répétez la transaction réussie. Un compte rendu de release contenant ces quatre résultats constitue une preuve plus solide que des captures d’écran d’un dashboard ou qu’une réponse curl ponctuelle.

Déplacer le travail d’infrastructure répétable vers Dockup

Dockup peut prendre en charge les éléments remplaçables de la plateforme : acheminer le trafic vers le port 5006, émettre le domaine et le certificat, injecter les secrets, attacher le stockage persistant et connecter Actual Budget à des services gérés ou attachés en privé. Il peut le faire sur l’infrastructure Dockup ou sur un serveur que vous attachez.

Le travail d’acceptation d’Actual Budget reste explicite. Après le déploiement en un clic, utilisez une URL HTTPS stable afin que les clients de synchronisation fassent confiance au serveur, confirmez l’exigence locale — un volume de données durable et un navigateur compatible pour la configuration initiale — puis exécutez ce scénario : créez ou importez un budget, ajoutez des transactions, synchronisez un second navigateur et produisez un export au niveau de l’application. Cette séparation est intentionnelle : Dockup élimine la configuration d’infrastructure répétitive sans prétendre que les rôles applicatifs, les identifiants des fournisseurs ou la politique de restauration se choisissent d’eux-mêmes.

Foire aux questions

De quoi Actual Budget a-t-il besoin pour un déploiement en production ?

Acheminez le conteneur Actual Budget sur le port 5006 via une seule origine HTTPS. L’exigence du runtime local se résume à un volume de données durable et à un navigateur compatible pour la configuration initiale. Ne considérez pas Actual Budget comme prêt tant que vous ne pouvez pas créer ou importer un budget, ajouter des transactions, synchroniser un second navigateur et produire un export au niveau de l’application.

Quelles données d’Actual Budget doivent figurer dans une sauvegarde ?

Rendez /data persistant et incluez les fichiers du serveur ainsi que des exports de budget périodiques au niveau de l’application dans le même manifeste de récupération. Une restauration propre d’Actual Budget n’est réussie que lorsque le serveur restauré synchronise les mêmes comptes et soldes et que l’export indépendant peut également être importé.

Actual Budget nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique d’Actual Budget et gardez le port 5006 sur la route interne. Appliquez correctement le paramètre Actual Budget : utilisez une URL HTTPS stable afin que les clients de synchronisation fassent confiance au serveur. Pour Actual Budget, HTTPS protège les identifiants ou le contenu utilisateur en transit et préserve la cohérence du comportement client sensible à l’origine.

Comment tester une mise à niveau d’Actual Budget ?

Restaurez l’état actuel d’Actual Budget dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les migrations de données d’Actual doivent être testées avec les fichiers du serveur et un budget exporté disponibles pour un rollback. Conservez l’image précédente d’Actual Budget jusqu’à ce que les limites de migration des données et de rollback soient bien comprises.