Як розгорнути Actual Budget на власному сервері у 2026 році: синхронізація, HTTPS і резервне копіювання фінансових даних

Невдале розгортання Actual Budget не завжди завершується аварією. Сервіс може показувати сторінку входу, навіть якщо каталог синхронізації є тимчасовим або проксі обрізає великі запити синхронізації. Натомість одразу виконайте наскрізну перевірку: створіть або імпортуйте бюджет, додайте транзакції, синхронізуйте другий браузер і створіть експорт на рівні застосунку.

Ця перевірка відповідає заявленому призначенню Actual Budget: бюджетування за методом конвертів зі зберіганням даних на власному диску. Вона також раніше виявляє відсутні залежності, неправильні припущення щодо проксі та тимчасове сховище, ніж це може зробити перевірка доступності.

Відокремте Actual Budget від його залежностей

Почніть із мережевого простору Actual Budget: його web listener працює на порту 5006, а не на host-порті, скопійованому з інструкції для ноутбука. Локальна вимога середовища виконання — один постійний том даних і підтримуваний браузер для початкового налаштування. Явно зафіксуйте життєвий цикл, щоб переміщення Actual Budget між хостами непомітно не змінило поведінку.

Після виконання вимоги запустіть повний сценарій — створіть або імпортуйте бюджет, додайте транзакції, синхронізуйте другий браузер і створіть експорт на рівні застосунку. Записуйте логи та показники розміру файлу бюджету, трафіку синхронізації й сховища сервера, а не інтенсивних обчислень на стороні сервера. Ці дані стануть першою перевіреною архітектурою та дадуть змогу тестувати подальші переміщення між обчислювальними ресурсами Dockup і під’єднаним сервером.

Запустіть перший production-подібний екземпляр

Мінімальна команда корисна, коли вона показує, чим згодом керуватиме платформа.

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

Тут порт 5006 залишається приватним для хоста, а кожен необхідний шлях задано явно. Перед відкриттям доступу підтвердьте локальну вимогу: один постійний том даних і підтримуваний браузер для початкового налаштування. Перевірте запуск за допомогою логів і специфічного для застосунку підтвердження: створіть або імпортуйте бюджет, додайте транзакції, синхронізуйте другий браузер і створіть експорт на рівні застосунку. Після перевірки зафіксуйте версію image, щоб звичайна заміна не змінила поведінку непомітно.

Зробіть публічний origin однозначним

Виберіть остаточне ім’я хоста Actual Budget до того, як користувачі збережуть callback-адреси або налаштування клієнтів, а потім використовуйте стабільний HTTPS URL, щоб клієнти синхронізації довіряли серверу. Маршрут платформи має завершувати TLS один раз і спрямовувати трафік на приватний порт 5006.

Виконайте acceptance transaction із зовнішньої мережі. Якщо клієнт узагалі не досягає Actual Budget, скористайтеся чеклістом перевірки SSL для перевірки DNS і сертифіката. Якщо запит досягає Actual Budget, але каталог синхронізації є тимчасовим або проксі обрізає великі запити синхронізації, припиніть змінювати перенаправлення проксі та перевірте відповідну межу на рівні застосунку.

Зробіть відновлення Actual Budget вимірюваним

Створіть маніфест відновлення для Actual Budget: файли сервера та періодичні експорти бюджетів на рівні застосунку. Підключіть /data до bootstrap, запишіть безпечні тестові дані та замініть container, щоб довести фактичну постійність цього шляху. Перевірте права власника й вільне місце зараз, оскільки підключений, але недоступний для запису шлях практично нічим не відрізняється від відсутності постійного сховища.

Створюйте резервні копії в окремому від запущеного сервера домені відмови. Відтворіть Actual Budget із зафіксованого image і переконайтеся, що відновлений сервер синхронізує ті самі рахунки та баланси, а незалежний експорт також можна імпортувати. Посібник із постійних томів допоможе перетворити цю процедуру на політику snapshot і зберігання резервних копій.

Захистіть Actual Budget після bootstrap

Облікові дані bootstrap є тимчасовими, а модель довіри — постійною. Для Actual Budget звертайте увагу на публікацію фінансового сервера до налаштування його пароля. Установіть пароль сервера до відкриття доступу та використовуйте HTTPS, оскільки екземпляр містить повну фінансову історію.

ACTUAL_PORT керує поведінкою, а не конфіденційністю. Перевіряйте його тип і значення, а справжні облікові дані Actual Budget зберігайте окремо. Запускайте image без непотрібних Linux capabilities і відкривайте лише публічний маршрут застосунку. Стежте за діями адміністраторів, не записуючи секретні значення.

Експлуатуйте Actual Budget з урахуванням реального вузького місця

Створюйте dashboards на основі розміру файлу бюджету, трафіку синхронізації та сховища сервера, а не інтенсивних обчислень на стороні сервера. Графік CPU без контексту цього навантаження не пояснить, чому Actual Budget працює повільно. Додайте synthetic або заплановану перевірку, яка намагається створити або імпортувати бюджет, додати транзакції, синхронізувати другий браузер і створити експорт на рівні застосунку, використовуючи безпечні тестові дані.

Перед оновленням врахуйте специфічний для цього застосунку ризик: міграції даних Actual Budget потрібно тестувати, маючи для rollback і файли сервера, і експортований бюджет. Відновіть свіжу резервну копію в ізольованому розгортанні, виконайте там міграції та порівняйте поведінку. Якщо каталог синхронізації є тимчасовим або проксі обрізає великі запити синхронізації, перевірте відповідну межу — публічний origin, сховище або залежність — перш ніж змінювати сторонні налаштування.

Які дані зібрати до запуску Actual Budget

Створіть невеликий одноразовий fixture Actual Budget і зберігайте його для кожного release. Fixture має перевіряти реальний робочий процес: створення або імпорт бюджету, додавання транзакцій, синхронізацію другого браузера та створення експорту на рівні застосунку. Запишіть digest image, зовнішнє ім’я хоста, адресу залежності й очікуваний результат, щоб наступний оператор міг повторити тест без додаткової інтерпретації цього посібника.

Запустіть fixture тричі. Спочатку використайте свіже розгортання. Потім замініть container, не змінюючи постійний стан. Втретє відновіть резервну копію в порожньому середовищі. Третій запуск вважається успішним лише тоді, коли відновлений сервер синхронізує ті самі рахунки та баланси, а незалежний експорт також можна імпортувати. Під час кожного запуску фіксуйте затримку та використання ресурсів для розміру файлу бюджету, трафіку синхронізації й сховища сервера, а не інтенсивних обчислень на стороні сервера; це стане базовим рівнем для alerts замість довільного відсотка CPU.

Нарешті, навмисно перевірте негативний сценарій: надішліть безпечні тестові дані, близькі до обмеження ресурсу або формату, пов’язаного з цією межею: каталог синхронізації є тимчасовим або проксі обрізає великі запити синхронізації. Переконайтеся, що Actual Budget явно повідомляє про помилку, не пошкоджуючи стан, відновіть правильну умову та повторіть успішну транзакцію. Запис про release, що містить ці чотири результати, є переконливішим доказом, ніж скриншоти dashboard або одноразова відповідь curl.

Перенесіть повторювану інфраструктурну роботу в Dockup

Dockup може відповідати за замінні компоненти платформи: спрямовувати трафік на порт 5006, видавати домен і сертифікат, передавати секрети, підключати постійне сховище та з’єднувати Actual Budget із керованими або приватно під’єднаними сервісами. Це можна робити на інфраструктурі Dockup або на сервері, який ви під’єднаєте.

Приймання Actual Budget залишається явним. Після one-click deployment використовуйте стабільний HTTPS URL, щоб клієнти синхронізації довіряли серверу, підтвердьте локальну вимогу — один постійний том даних і підтримуваний браузер для початкового налаштування — та запустіть цей сценарій: створіть або імпортуйте бюджет, додайте транзакції, синхронізуйте другий браузер і створіть експорт на рівні застосунку. Такий розподіл навмисний: Dockup усуває повторюване налаштування інфраструктури, але не робить вигляд, що ролі застосунку, облікові дані провайдера або політика відновлення визначаються самі собою.

Поширені запитання

Що потрібно Actual Budget для production-розгортання?

Спрямуйте container Actual Budget на порту 5006 через один HTTPS origin. Локальна вимога середовища виконання — один постійний том даних і підтримуваний браузер для початкового налаштування. Не вважайте Actual Budget готовим, доки не зможете створити або імпортувати бюджет, додати транзакції, синхронізувати другий браузер і створити експорт на рівні застосунку.

Які дані Actual Budget потрібно включати до резервної копії?

Зберігайте /data і включайте до одного маніфесту відновлення файли сервера та періодичні експорти бюджетів на рівні застосунку. Відновлення Actual Budget є коректним лише тоді, коли відновлений сервер синхронізує ті самі рахунки та баланси, а незалежний експорт також можна імпортувати.

Чи потрібен Actual Budget HTTPS за reverse proxy?

Використовуйте HTTPS для публічного origin Actual Budget, а порт 5006 залишайте у внутрішньому маршруті. Правильно застосуйте налаштування Actual Budget: використовуйте стабільний HTTPS URL, щоб клієнти синхронізації довіряли серверу. Для Actual Budget HTTPS захищає облікові дані або вміст користувачів під час передавання та забезпечує узгоджену поведінку клієнта, чутливу до origin.

Як тестувати оновлення Actual Budget?

Відновіть поточний стан Actual Budget в ізольованому розгортанні, застосуйте candidate version і повторіть acceptance transaction. Зверніть особливу увагу на те, що міграції даних Actual Budget потрібно тестувати, маючи для rollback і файли сервера, і експортований бюджет. Зберігайте попередній image Actual Budget, доки не буде зрозумілою межа міграції даних і rollback.