Slik selvhoster du Actual Budget i 2026: synkronisering, HTTPS og sikkerhetskopiering av økonomiske data
Distribuer Actual Budget med riktig port, persistent lagring, TLS, autentisering og sikkerhetskopier. Feilsøk når synkroniseringskatalogen er flyktig i produksjon.
En mislykket Actual Budget-distribusjon krasjer ikke alltid. Den kan vise en innloggingsside selv om synkroniseringskatalogen er flyktig, eller en proxy fjerner store synkroniseringsforespørsler. Start heller med en ende-til-ende-kontroll: opprett eller importer et budsjett, legg til transaksjoner, synkroniser en ekstra nettleser og opprett en eksport på applikasjonsnivå.
Denne kontrollen samsvarer med Actual Budgets dokumenterte formål: konvoluttbudsjettering med data lagret på din disk. Den avdekker også manglende avhengigheter, feil antakelser om proxyen og flyktige data tidligere enn en enkel uptime-sjekk kan.
Skill Actual Budget fra avhengighetene
Start med Actual Budgets network namespace: weblytteren bruker port 5006, ikke en host-port kopiert fra en laptop-veiledning. Det lokale runtime-kravet er ett persistent data volume og en støttet nettleser for førstegangsoppsett. Gjør livssyklusen eksplisitt, slik at flytting av Actual Budget mellom verter ikke endrer virkemåten i det stille.
Når kravet er oppfylt, kjører du hele scenarioet — opprett eller importer et budsjett, legg til transaksjoner, synkroniser en ekstra nettleser og opprett en eksport på applikasjonsnivå. Loggfør logger og målinger for budsjettfilstørrelse, synkroniseringstrafikk og serverlagring, i stedet for tung beregning på serversiden. Disse bevisene blir den første kjente fungerende arkitekturen og gjør senere flyttinger mellom Dockup compute og en tilkoblet server testbare.
Kjør den første produksjonslignende instansen
En minimal kommando er nyttig når den viser hva plattformen senere skal administrere.
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
Her forblir port 5006 privat på hosten, og alle nødvendige paths er eksplisitte. Bekreft det lokale kravet før eksponering: ett persistent data volume og en støttet nettleser for førstegangsoppsett. Bekreft oppstart både med logger og med det applikasjonsspesifikke beviset: opprett eller importer et budsjett, legg til transaksjoner, synkroniser en ekstra nettleser og opprett en eksport på applikasjonsnivå. Når dette er bekreftet, låser du image-versjonen slik at en rutinemessig utskifting ikke endrer virkemåten i det stille.
Gjør den offentlige origin-en entydig
Velg det endelige vertsnavnet for Actual Budget før brukerne lagrer callbacks eller klientinnstillinger, og bruk deretter en stabil HTTPS-URL slik at synkroniseringsklientene stoler på serveren. Plattformruten bør terminere TLS én gang og peke mot den private porten 5006.
Kjør akseptansetesten eksternt. Hvis klienten aldri når Actual Budget, kan du bruke sjekklisten for SSL-validering til DNS- og sertifikatkontroller. Hvis forespørselen når Actual Budget, men synkroniseringskatalogen er flyktig eller en proxy fjerner store synkroniseringsforespørsler, må du slutte å endre proxy-redirects og heller undersøke den applikasjonsspesifikke grensen.
Gjør gjenoppretting av Actual Budget målbar
Lag et gjenopprettingsmanifest for Actual Budget: serverfiler samt periodiske budsjetteksporter på applikasjonsnivå. Mount /data før bootstrap, skriv ufarlige eksempeldata og bytt ut containeren for å bevise at path-en faktisk er persistent. Kontroller eierskap og ledig plass nå, fordi en mountet, men ikke skrivbar path i praksis oppfører seg som om den ikke har persistent lagring.
Sikkerhetskopier til et failure domain som er separat fra serveren som kjører. Opprett Actual Budget på nytt fra det låste imaget, og bekreft at den gjenopprettede serveren synkroniserer de samme kontoene og saldoene, og at den uavhengige eksporten også kan importeres. Veiledningen for persistent volumes hjelper deg med å omsette denne øvelsen til en policy for snapshots og oppbevaring.
Sikre Actual Budget etter bootstrap
Bootstrap-legitimasjon er midlertidig; trust-modellen er permanent. Med Actual Budget må du passe på at du ikke publiserer en økonomiserver før passordet er konfigurert. Sett serverpassordet før eksponering, og bruk HTTPS fordi instansen inneholder en komplett økonomisk historikk.
ACTUAL_PORT styrer virkemåten, ikke konfidensialiteten. Valider type og verdi, og lagre ekte Actual Budget-legitimasjon separat. Kjør imaget uten unødvendige Linux capabilities, og eksponer bare den offentlige applikasjonsruten. Sørg for at administratoraktivitet er synlig uten å logge hemmelige verdier.
Drift Actual Budget rundt den reelle flaskehalsen
Bygg dashboards rundt budsjettfilstørrelse, synkroniseringstrafikk og serverlagring, i stedet for tung beregning på serversiden. En CPU-graf uten kontekst om denne arbeidsbelastningen kan ikke forklare hvorfor Actual Budget er tregt. Legg til en syntetisk eller planlagt sjekk som forsøker å opprette eller importere et budsjett, legge til transaksjoner, synkronisere en ekstra nettleser og opprette en eksport på applikasjonsnivå med ufarlige testdata.
Før en oppgradering må du ta høyde for denne applikasjonsspesifikke risikoen: Actuals datamigreringer bør testes med både serverfiler og et eksportert budsjett tilgjengelig for rollback. Gjenopprett en nylig sikkerhetskopi i en isolert distribusjon, kjør migreringene der og sammenlign virkemåten. Hvis synkroniseringskatalogen er flyktig eller en proxy fjerner store synkroniseringsforespørsler, må du undersøke den aktuelle grensen — offentlig origin, lagring eller avhengighet — før du endrer irrelevante innstillinger.
Bevis som bør samles inn før Actual Budget settes i produksjon
Opprett en liten, midlertidig Actual Budget-fixture og behold den for hver release. Fixturen bør utøve den faktiske arbeidsflyten: opprett eller importer et budsjett, legg til transaksjoner, synkroniser en ekstra nettleser og opprett en eksport på applikasjonsnivå. Registrer image digest, eksternt vertsnavn, avhengighetsadresse og forventet resultat, slik at en senere operatør kan gjenta testen uten å måtte tolke denne veiledningen.
Kjør fixturen tre ganger. Først bruker du den nye distribusjonen. Deretter bytter du ut containeren uten å endre persistent state. Til slutt gjenoppretter du sikkerhetskopien i et tomt miljø. Den tredje kjøringen er bare godkjent når den gjenopprettede serveren synkroniserer de samme kontoene og saldoene, og den uavhengige eksporten også kan importeres. Under hver kjøring måler du latency og ressursbruk rundt budsjettfilstørrelse, synkroniseringstrafikk og serverlagring, i stedet for tung beregning på serversiden. Dette blir baseline for alarmer, ikke en vilkårlig CPU-prosent.
Til slutt tester du den negative banen med hensikt: send inn ufarlige data nær ressurs- eller formatgrensen som gjelder for denne grensen: synkroniseringskatalogen er flyktig eller en proxy fjerner store synkroniseringsforespørsler. Bekreft at Actual Budget feiler synlig uten å korruptere state, gjenopprett riktig tilstand og gjenta den vellykkede transaksjonen. En release-oppføring som inneholder disse fire resultatene, er sterkere dokumentasjon enn skjermbilder av et dashboard eller et engangsresultat fra curl.
Flytt det repeterbare infrastrukturarbeidet til Dockup
Dockup kan håndtere de utskiftbare plattformdelene: rute trafikk til port 5006, utstede domenet og sertifikatet, injisere secrets, koble til persistent storage og koble Actual Budget til administrerte eller privat tilkoblede tjenester. Dette kan gjøres på Dockup-infrastruktur eller på en server du kobler til.
Akseptansearbeidet for Actual Budget forblir eksplisitt. Etter one-click-distribusjonen bruker du en stabil HTTPS-URL slik at synkroniseringsklientene stoler på serveren, bekrefter det lokale kravet — ett persistent data volume og en støttet nettleser for førstegangsoppsett — og kjører dette scenarioet: opprett eller importer et budsjett, legg til transaksjoner, synkroniser en ekstra nettleser og opprett en eksport på applikasjonsnivå. Denne arbeidsdelingen er bevisst: Dockup fjerner repetitivt infrastrukturarbeid uten å late som om applikasjonsroller, provider-legitimasjon eller gjenopprettingspolicy velger seg selv.
Vanlige spørsmål
Hva trenger Actual Budget for en produksjonsdistribusjon?
Rout Actual Budget-containeren på port 5006 gjennom én HTTPS-origin. Det lokale runtime-kravet er ett persistent data volume og en støttet nettleser for førstegangsoppsett. Ikke erklær Actual Budget klar før du kan opprette eller importere et budsjett, legge til transaksjoner, synkronisere en ekstra nettleser og opprette en eksport på applikasjonsnivå.
Hvilke Actual Budget-data bør inngå i en sikkerhetskopi?
Gjør /data persistent, og inkluder serverfiler samt periodiske budsjetteksporter på applikasjonsnivå i det samme gjenopprettingsmanifestet. En ren Actual Budget-gjenoppretting er bare godkjent når den gjenopprettede serveren synkroniserer de samme kontoene og saldoene, og den uavhengige eksporten også kan importeres.
Krever Actual Budget HTTPS bak en reverse proxy?
Bruk HTTPS for den offentlige Actual Budget-origin-en, og behold port 5006 på den interne ruten. Konfigurer Actual Budget-innstillingen riktig: bruk en stabil HTTPS-URL slik at synkroniseringsklientene stoler på serveren. For Actual Budget beskytter HTTPS legitimasjon og brukerinnhold under overføring, og sørger for at origin-avhengig klientatferd forblir konsistent.
Hvordan bør en Actual Budget-oppgradering testes?
Gjenopprett gjeldende Actual Budget-state i en isolert distribusjon, ta i bruk kandidatversjonen og gjenta akseptansetesten. Vær spesielt oppmerksom på at Actuals datamigreringer bør testes med både serverfiler og et eksportert budsjett tilgjengelig for rollback. Behold det forrige Actual Budget-imaget til grensen for datamigrering og rollback er forstått.