Så självhostar du Actual Budget 2026: synkronisering, HTTPS och säkerhetskopiering av ekonomiska data
Distribuera Actual Budget med rätt port, beständig lagring, TLS, autentisering och säkerhetskopiering. Felsök när synkroniseringskatalogen är temporär i produktion.
En misslyckad distribution av Actual Budget kraschar inte alltid. Den kan visa en inloggningssida trots att synkroniseringskatalogen är temporär eller att en proxy tar bort stora synkroniseringsförfrågningar. Börja i stället med en end-to-end-kontroll: skapa eller importera en budget, lägg till transaktioner, synkronisera en andra webbläsare och skapa en export på applikationsnivå.
Den kontrollen motsvarar Actual Budgets dokumenterade syfte: kuvertbudgetering med data som lagras på din disk. Den avslöjar också saknade beroenden, felaktiga antaganden om proxyn och temporär lagring tidigare än vad en enkel driftkontroll kan göra.
Separera Actual Budget från dess beroenden
Börja med Actual Budgets network namespace: dess webblyssnare använder port 5006, inte en host-port som kopierats från en laptopguide. Det lokala runtime-kravet är en beständig datavolym och en webbläsare som stöds för den första konfigurationen. Gör livscykeln tydlig, så att en flytt av Actual Budget mellan värdar inte i tysthet ändrar beteendet.
När kravet är uppfyllt kör du hela scenariot — skapa eller importera en budget, lägg till transaktioner, synkronisera en andra webbläsare och skapa en export på applikationsnivå. Dokumentera loggar och mätvärden för budgetfilens storlek, synkroniseringstrafik och serverlagring i stället för omfattande beräkningar på serversidan. Den informationen blir den första kända fungerande arkitekturen och gör senare flyttar mellan Dockup compute och en ansluten server testbara.
Kör den första produktionsliknande instansen
Ett minimalt kommando är användbart när det visar vad plattformen senare kommer att hantera.
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
Här förblir port 5006 privat på värden och alla nödvändiga sökvägar är explicit angivna. Bekräfta det lokala kravet innan exponering: en beständig datavolym och en webbläsare som stöds för den första konfigurationen. Verifiera uppstarten med både loggar och det applikationsspecifika beviset: skapa eller importera en budget, lägg till transaktioner, synkronisera en andra webbläsare och skapa en export på applikationsnivå. När allt är verifierat låser du image-versionen, så att ett rutinmässigt byte inte i tysthet ändrar beteendet.
Gör den publika origin-entydig
Välj det slutliga värdnamnet för Actual Budget innan användarna sparar callbacks eller klientinställningar, och använd sedan en stabil HTTPS-URL så att synkroniseringsklienterna litar på servern. Plattformens route ska avsluta TLS en gång och peka mot den privata porten 5006.
Kör acceptanstestet externt. Om klienten aldrig når Actual Budget använder du checklistan för SSL-validering för kontroller av DNS och certifikat. Om förfrågan når Actual Budget men synkroniseringskatalogen är temporär eller en proxy tar bort stora synkroniseringsförfrågningar ska du sluta ändra proxy-redirects och i stället granska den applikationsspecifika gränsen.
Gör återställning av Actual Budget mätbar
Skapa ett återställningsmanifest för Actual Budget: serverfiler plus återkommande budgetexporter på applikationsnivå. Montera /data före bootstrap, skriv ofarliga exempeldata och byt ut containern för att bevisa att sökvägen faktiskt är beständig. Kontrollera ägarskap och ledigt utrymme nu, eftersom en monterad men skrivskyddad sökväg i praktiken inte ger någon beständig lagring alls.
Säkerhetskopiera till en felisolering som är separat från den körande servern. Återskapa Actual Budget från dess låsta image och verifiera att den återställda servern synkroniserar samma konton och saldon och att den fristående exporten också kan importeras. Guiden om beständiga volymer hjälper dig att omsätta övningen i en policy för snapshots och lagringstid.
Säkra Actual Budget efter bootstrap
Bootstrap-uppgifter är tillfälliga; trust-modellen är permanent. Var med Actual Budget uppmärksam på att publicera en ekonomiserver innan lösenordet har konfigurerats, och ange serverlösenordet före exponering. Använd HTTPS eftersom instansen innehåller en fullständig ekonomisk historik.
ACTUAL_PORT styr beteendet, inte konfidentialiteten. Validera dess typ och värde och lagra riktiga Actual Budget-uppgifter separat. Kör imagen utan onödiga Linux capabilities och exponera endast den publika applikationsrouten. Håll administratörsaktivitet synlig utan att logga hemliga värden.
Drifta Actual Budget utifrån dess verkliga flaskhals
Bygg dashboards kring budgetfilens storlek, synkroniseringstrafik och serverlagring i stället för omfattande beräkningar på serversidan. En CPU-graf utan det arbetsbelastningssammanhanget kan inte förklara varför Actual Budget är långsamt. Lägg till en syntetisk eller schemalagd kontroll som försöker skapa eller importera en budget, lägga till transaktioner, synkronisera en andra webbläsare och skapa en export på applikationsnivå med ofarliga testdata.
Ta hänsyn till följande applikationsspecifika risk före en uppgradering: Actuals datamigreringar bör testas med både serverfiler och en exporterad budget tillgängliga för rollback. Återställ en aktuell säkerhetskopia i en isolerad distribution, kör migreringarna där och jämför beteendet. Om synkroniseringskatalogen är temporär eller en proxy tar bort stora synkroniseringsförfrågningar ska du granska den berörda gränsen — publik origin, lagring eller beroende — innan du ändrar orelaterade inställningar.
Bevis att samla in innan Actual Budget går live
Skapa en liten, temporär Actual Budget-fixture och behåll den för varje release. Fixturen ska testa det verkliga arbetsflödet: skapa eller importera en budget, lägg till transaktioner, synkronisera en andra webbläsare och skapa en export på applikationsnivå. Dokumentera image-digest, externt värdnamn, beroendeadress och förväntat resultat, så att en senare operatör kan upprepa testet utan att behöva tolka den här guiden.
Kör fixturen tre gånger. Använd först den nya distributionen. Byt sedan ut containern utan att röra den beständiga datan. Återställ slutligen säkerhetskopian i en tom miljö. Den tredje körningen godkänns endast när den återställda servern synkroniserar samma konton och saldon och den fristående exporten också kan importeras. Fånga under varje körning latens och resursanvändning kring budgetfilens storlek, synkroniseringstrafik och serverlagring i stället för omfattande beräkningar på serversidan. Det blir baslinjen för larm, i stället för en godtycklig CPU-procent.
Testa slutligen den negativa vägen medvetet: skicka ofarlig indata nära resurs- eller formatgränsen som hör till den här gränsen: synkroniseringskatalogen är temporär eller en proxy tar bort stora synkroniseringsförfrågningar. Bekräfta att Actual Budget misslyckas synligt utan att data korrumperas, återställ det korrekta tillståndet och upprepa den lyckade transaktionen. En releasepost som innehåller dessa fyra resultat är starkare bevis än skärmbilder av en dashboard eller ett engångssvar från curl.
Flytta det repeterbara infrastrukturarbetet till Dockup
Dockup kan hantera de utbytbara plattformsdelarna: dirigera trafik till port 5006, utfärda domän och certifikat, injicera secrets, ansluta beständig lagring och koppla Actual Budget till hanterade eller privat anslutna tjänster. Detta kan göras på Dockup-infrastruktur eller på en server som du ansluter.
Acceptansarbetet för Actual Budget förblir explicit. Efter one-click-distributionen använder du en stabil HTTPS-URL så att synkroniseringsklienterna litar på servern, bekräftar det lokala kravet — en beständig datavolym och en webbläsare som stöds för den första konfigurationen — och kör detta scenario: skapa eller importera en budget, lägg till transaktioner, synkronisera en andra webbläsare och skapa en export på applikationsnivå. Den uppdelningen är avsiktlig: Dockup tar bort repetitiv infrastrukturkonfiguration utan att låtsas att applikationsroller, leverantörsuppgifter eller återställningspolicy väljer sig själva.
Vanliga frågor
Vad behöver Actual Budget för en produktionsdistribution?
Dirigera Actual Budget-containern på port 5006 via en enda HTTPS-origin. Det lokala runtime-kravet är en beständig datavolym och en webbläsare som stöds för den första konfigurationen. Anse inte Actual Budget vara redo förrän du kan skapa eller importera en budget, lägga till transaktioner, synkronisera en andra webbläsare och skapa en export på applikationsnivå.
Vilka Actual Budget-data ska ingå i en säkerhetskopia?
Gör /data beständig och inkludera serverfiler samt återkommande budgetexporter på applikationsnivå i samma återställningsmanifest. En ren återställning av Actual Budget är godkänd först när den återställda servern synkroniserar samma konton och saldon och den fristående exporten också kan importeras.
Kräver Actual Budget HTTPS bakom en reverse proxy?
Använd HTTPS för den publika origin-adressen till Actual Budget och behåll port 5006 på den interna routen. Tillämpa Actual Budget-inställningen korrekt: använd en stabil HTTPS-URL så att synkroniseringsklienterna litar på servern. För Actual Budget skyddar HTTPS inloggningsuppgifter och användarinnehåll under överföring och håller origin-känsligt klientbeteende konsekvent.
Hur bör en uppgradering av Actual Budget testas?
Återställ det aktuella Actual Budget-tillståndet i en isolerad distribution, tillämpa kandidatversionen och upprepa acceptanstestet. Var särskilt uppmärksam eftersom Actuals datamigreringar bör testas med både serverfiler och en exporterad budget tillgängliga för rollback. Behåll den tidigare Actual Budget-imagen tills gränsen för datamigrering och rollback är förstådd.