Yedekleme & yükseltme

Yedek üç şeyden oluşur: PostgreSQL veritabanı, yüklenen dosyalar (ekler ve metne gömülen görseller, app-uploads birimi) ve gizli anahtarları taşıyan .env.onprem ayar dosyası. Yalnız veritabanını almak yetmez; geri yüklediğinde görevler ve sayfalar gelir ama ekleri açılmaz. Paketle gelen iki betik bu işi senin yerine yapar: ./scripts/backup.sh yedek alır, ./scripts/restore.sh geri yükler. Komutları kurulum dizininde çalıştır. Yükseltme tek komuttur: ./scripts/update.sh en son paketi indirir, önce yedek alır ve güncellemeyi uygular (v1.67.2 ve sonrası); internet erişimi olmayan sunucuda başka bir bilgisayarda indirilip sunucuya kopyalanan paketi ./scripts/update.sh --package <dosya> aynı imza doğrulaması, yedek ve geri dönüşle kurar (v1.110.0); yeni sürüm açılmazsa önceki sürüme kendiliğinden döner (v1.96.0).

Yedek alma

./scripts/backup.sh

Yedek uygulama çalışırken alınabilir; pg_dump tutarlı bir anlık görüntü alır. Her çalıştırma kurulum dizinindeki backups/ altında tarih, saat ve kurulu sürümle adlandırılmış yeni bir klasör açar, örneğin backups/2026-10-02-023000-v1.61.0. Sürüm diskte açılmış paketten değil kurulu uygulama konteynerinden okunur; güncellemeden önce alınan yedek bu yüzden eski sürümün adını taşır. Klasöre yalnız betiği çalıştıran kullanıcı erişir (izin 700). Veritabanı konteyneri çalışmıyorsa betik dökümü alamayacağını söyleyip durur.

Betik yedeği kendisi doğrular: iki arşiv de geçerli gzip mi, dosya arşivi sorunsuz listeleniyor mu, döküm pg_dump’ın bitiş işaretiyle bitiyor mu (yarıda kesilmemiş), döküm makul sayıda tablo oluşturuyor mu (varsayılan en az 20). Yedek önce adı .partial ile biten bir klasöre yazılır ve ancak doğrulandıktan sonra asıl adını alır; adı .partial ile bitmeyen her klasör eksiksizdir. Bir kontrol tutmazsa betik açık bir hata mesajıyla sıfırdan farklı bir kodla çıkar ve yarım klasörü siler.

Saklama: en yeni 7 eksiksiz yedek tutulur, eskileri silinir. Yalnız yedek adı kalıbına uyan ve manifest.txt dosyası status: ok diyen klasörler sayılır ve silinir; backups/ altına koyduğun başka bir şeye dokunulmaz.

./scripts/backup.sh --keep 14
./scripts/backup.sh --dir /mnt/nas/myway-backups
./scripts/backup.sh --verify backups/2026-10-02-023000-v1.61.0

Günlük otomatik yedek

Kurulum betiği günlük yedeği kurmayı önerir ve "Set up a daily automatic backup? [Y/n]" diye sorar; varsayılan evettir. Kabul edersen her gece 02:30’da ./scripts/backup.sh --quiet çalışır, en yeni 7 yedek backups/ altında tutulur ve çıktı logs/backup.log dosyasına yazılır. Cevap .env.onprem içine MYWAY_DAILY_BACKUP=yes ya da no olarak kaydedilir ve sonraki çalıştırmalarda yeniden sorulmaz. Soru ilk kurulumda sorulur; v1.61.1’den eski bir kurulumu güncellerken de cevap henüz kayıtlı olmadığı için bir kez gelir. Terminal olmadan çalışan bir kurulumda (otomasyon) günlük yedek varsayılan olarak açılır.

Yedeğin sonucu Ayarlar > Sağlık ekranında görünür. Uygulama çalışıyorsa ./scripts/backup.sh her yedeğin sonucunu (başarılı ya da hata, boyut, tablo ve dosya sayısı, süre) uygulamaya bildirir; bu yalnız gece yedeği için değil, elle alınan yedek için de geçerlidir, --verify ile yapılan denetim ise bildirilmez. Zamanlanmış işler tablosundaki "Yedekleme" satırı son yedeği, sonucunu ve sonraki çalışmayı gösterir. Son yedek 26 saatten eskiyse satır "Gecikti", hatayla bittiyse "Hata" olur; henüz hiç sonuç gelmemişse (örneğin günlük yedek kapalı ve elle de yedek alınmamışsa) "Çalışmadı" görünür. Bildirim yedeği hiçbir zaman başarısız saymaz: uygulamaya ulaşılamazsa betik yalnız bir uyarı yazar, çıkış kodu değişmez. Uygulama kapalıyken alınan yedek bildirilmez. v1.62.0’dan eski bir kurulumu güncellerken alınan yedek, henüz eski sürümde çalışan uygulamaya bildirilemez; betik bunu bir uyarıyla söyleyebilir, yedek bundan etkilenmez.

Geri yükleme

./scripts/restore.sh backups/2026-10-02-023000-v1.61.0

Betik hiçbir şeye dokunmadan önce yedeği doğrular. Sonra yedeğin tarihini ve sürümünü kurulu sürümle yan yana, tablo ve dosya sayılarıyla gösterir ve "Type RESTORE to continue:" diye sorar. Devam etmek için RESTORE yazarsın; başka bir cevap hiçbir şeyi değiştirmeden çıkar. Betik terminal olmadan çalışacaksa (örneğin başka bir betikten) onay --yes ile verilir. Onaydan sonra:

1. 1Uygulamayı durdurur; veritabanı konteyneri çalışmaya devam eder.
2. 2Dökümü yeni, boş bir veritabanına tek işlemde yükler ve yükleme başarılı olunca adını değiştirerek mevcut veritabanının yerine koyar. Yükleme başarısız olursa mevcut veritabanına dokunulmamıştır ve uygulama yeniden başlatılır.
3. 3Önceki veritabanını uygulama sağlıklı açılana kadar <veritabanı adı>_pre_restore adıyla saklar, sonra siler.
4. 4Yüklenen dosyalar birimini boşaltır ve yedekteki arşivi açar.
5. 5Uygulamayı başlatır (bekleyen migrasyonlar her zamanki gibi uygulanır) ve sağlıklı açılmasını bekler. Geri yüklemeden önce oturum açmış kullanıcıların yeniden giriş yapması gerekebilir.

.env.onprem varsayılan olarak geri yüklenmez; betik yalnız yedektekinden farklı olan ayarların ADLARINI listeler, değerlerini göstermez. Yedeği yeni bir sunucuya taşıyorsan --with-env ekle; mevcut dosya .env.onprem.before-restore-<zaman> olarak saklanır. Kayıtlı GitLab erişim anahtarları SESSION_SECRET ve GITLAB_TOKEN_KEK ile şifrelidir: bu değerler yedektekinden farklıysa betik uyarır ve --with-env ile yeniden çalıştırmanı ya da GitLab’ı sonradan yeniden bağlamanı önerir. Kişisel erişim anahtarları da SESSION_SECRET ile imzalıdır: değer yedektekinden farklı kalırsa CLI, betik ve asistanların anahtarları çalışmaz, yeniden oluşturulmaları gerekir.

# yeni sunucuya taşıma: paketi kur, yedek klasörünü sunucuya kopyala
# moving to a new server: install the package, copy the backup directory over
./scripts/install.sh
./scripts/restore.sh --with-env backups/2026-10-02-023000-v1.61.0

Elle yedek (betiksiz)

Betikleri kullanamadığın bir durumda aynı işi elle yaparsın. Compose dosyasının adı varsayılan değil, bu yüzden her komut -f docker-compose.onprem.yml ve --env-file .env.onprem ile verilir. .env.onprem dosyasını da ayrıca güvenli bir yere kopyala.

# veritabanı / database
docker compose -f docker-compose.onprem.yml --env-file .env.onprem \
  exec -T postgres sh -c 'pg_dump --no-owner --no-privileges -U "$POSTGRES_USER" "$POSTGRES_DB"' \
  | gzip > myway-db-$(date +%F).sql.gz

# yüklenen dosyalar / uploaded files
docker run --rm -v myway-onprem_app-uploads:/data:ro postgres:16-alpine \
  tar czf - -C /data . > myway-uploads-$(date +%F).tar.gz

Elle geri yüklerken önce uygulamayı durdur. Döküm BOŞ bir veritabanına yüklenmelidir; dolu bir veritabanının üstüne yüklemek "already exists" hatalarıyla yarım kalır. Aşağıdaki komutlar mevcut veritabanını silip boş olarak yeniden oluşturur, yani betikten farklı olarak yükleme başarısız olursa geri dönüş yolu yoktur.

C="docker compose -f docker-compose.onprem.yml --env-file .env.onprem"
$C stop app
$C exec -T postgres sh -c 'psql -U "$POSTGRES_USER" -d postgres -c "DROP DATABASE \"$POSTGRES_DB\" WITH (FORCE)" -c "CREATE DATABASE \"$POSTGRES_DB\""'
gunzip -c myway-db-YYYY-MM-DD.sql.gz | \
  $C exec -T postgres sh -c 'psql -v ON_ERROR_STOP=1 -U "$POSTGRES_USER" -d "$POSTGRES_DB"'
docker run --rm -i -v myway-onprem_app-uploads:/data postgres:16-alpine \
  sh -c 'find /data -mindepth 1 -delete && tar xzf - -C /data && chown -R 1000:1000 /data' \
  < myway-uploads-YYYY-MM-DD.tar.gz
$C up -d

Yükseltme

cd myway-onprem   # kurulum dizininiz / your install directory
./scripts/update.sh

v1.67.2’den beri kurulum dizinindeki ./scripts/update.sh yükseltmeyi tek adımda yapar. .env.onprem içindeki LICENSE_KEY ile en son paketi indirir ve kurmadan önce imzasını doğrular (v1.90.0), sonra paketteki sürümü kurulu sürümle karşılaştırır; aynıysa "Already up to date." yazar ve hiçbir şeye dokunmaz; kurulu sürümden eski bir paketi hiçbir koşulda kurmaz (v1.110.0). Kurmadan önce ./scripts/update.sh --check hiçbir şeyi değiştirmeden kurulu sürümü, paketteki sürümü, imza durumunu, aradaki sürümleri, geri dönüşün hazır olup olmadığını ve boş disk alanını gösterir (v1.110.0). Yeni sürüm varsa doğrulanmış paketi kurulum dizininin üstüne açar (.env.onprem ve backups/ değişmez), ./scripts/install.sh --backup ile önce kurulu sürümün yedeğini alıp güncellemeyi uygular ve yeni sürüm açılana kadar bekler: önce uygulama konteynerinin sağlıklı olup olmadığına, sonra PUBLIC_URL tanımlıysa /api/health’e bakar. Bekleme süresi .env.onprem içindeki MYWAY_UPDATE_HEALTH_TIMEOUT ile değişir (varsayılan 150 saniye). Yeni sürüm bu sürede açılmazsa ya da kurulum hata verirse önceki sürüme kendiliğinden döner (aşağıda, Güncellemeyi geri alma). Başarılı güncellemeden sonra eski imajları siler (aşağıda, İmaj saklama).

İmza: MyWay paketleri imzalıdır (v1.90.1 ve sonrası). Paketteki SHA256SUMS dosyası her dosyanın özetini taşır ve MyWay’in sürüm anahtarıyla imzalanır. v1.108.1’den beri update.sh imzayı her zaman kendi içine gömülü MyWay açık anahtarıyla doğrular; anahtar ne paketten ne bir dosyadan gelir, dosya eksik olsa da doğrulama atlanmaz. Paketin getirdiği anahtar dosyası bundan farklıysa paket kurulmaz ("The package carries a different signing key"); ardından her dosyayı listeyle karşılaştırır ve listede olmayan dosyaya izin vermez. İmzasız ya da tutmayan paket kurulmaz: "The package is not signed, so it was NOT installed." ya da "The package signature or its contents do not match, so it was NOT installed." yazar. Doğrulama sunucuda OpenSSL 3 varsa onunla, yoksa kurulu uygulama imajının içinden ağsız bir konteynerle yapılır; ikisi de yoksa betik durur. İmzalı ilk sürüme geçen güncelleme imzayı henüz denetleyemez, çünkü anahtar o paketle gelir; sonraki her güncelleme doğrulanır.

Kurulumunda scripts/update.sh hiç yoksa (v1.67.2’den eski) yükseltme ilk kurulumla aynı betikle yapılır: paketi MEVCUT kurulum dizininin üstüne açın, asla yeni bir dizine değil; yeni dizinde ./scripts/install.sh yeni parolalarla ikinci, boş bir kurulum oluşturur ve mevcut veritabanıyla açılmaz. Betik mevcut ayarlarını (adres, portlar, lisans anahtarı, e-posta yapılandırması) korur, yalnız eksik yeni ayarları tamamlar, yeni imajları yükler, veritabanı migrasyonlarını uygular ve zamanlanmış görevleri tazeler. Yeni bir sürüm çıktığında Ayarlar > Güncellemeler ekranında görünür; "Şimdi kontrol et" ile beklemeden de bakabilirsin.

Güncellemeden önce yedek: betik mevcut bir kurulum bulduğunda, yeni imajları yüklemeden ÖNCE "Back up before updating? [Y/n]" diye sorar; varsayılan evettir. Evet dersen ./scripts/backup.sh ile kurulu (eski) sürümün yedeğini alır ve doğrular. Yedek alınamazsa güncelleme UYGULANMAZ ve hiçbir şey değişmemiş olur; sorunu giderip betiği yeniden çalıştırırsın. Veritabanı çalışmıyorsa yedek için yalnız veritabanı başlatılır, uygulama kapalı kalır. İlk kurulumda bu soru sorulmaz. Terminal olmadan çalıştırıldığında (otomasyon) ve seçenek verilmemişse betik güvenli tarafı seçer: güncellemeden önce yedek alır ve bunu çıktıda belirtir.

1. 1Sürüm notlarını oku; "Dikkat" işaretli maddeler davranış değişikliğidir ve ekibini etkileyebilir.
2. 2Yükseltme sırasında paket boyutunun yaklaşık 3 katı boş disk bulundur (paket yaklaşık 200 MB, yani en az 600 MB): yeni imaj yazılırken eskisi hâlâ diskte durur. Güncellemeden önce alınan yedek de kurulum dizinindeki backups/ altında yer kaplar.
3. 3Yeni paketi indir ve sunucuda kurulum dizininin üstüne çıkart.
4. 4./scripts/install.sh çalıştır. Kurulumdaki sorular yeniden sorulmaz, kayıtlı ayarların kullanılır; "Back up before updating? [Y/n]" sorusunu cevaplarsın (Enter evet demektir). v1.61.1’den eski bir kurulumda önce bir kez "Set up a daily automatic backup? [Y/n]" de sorulur.
5. 5Betik önce eski sürümün yedeğini alıp doğrular, sonra yeni imajları yükler. Migrasyonlar açılışta kendiliğinden uygulanır; betik sonunda zamanlanmış görevleri bir kez deneyip sonucu bildirir. Güncellemede "ilk kayıt olan yönetici olur" uyarısı çıkmaz, onun yerine mevcut kullanıcıların, verinin ve ayarların değişmediği yazılır.
6. 6Kurulum betiğiyle güncellediysen eski imajları ./scripts/prune-images.sh ile temizle (önce --dry-run ne silineceğini gösterir). Kurulu sürümle bir öncekini bırakır, geri dönüş için gereken imaj yerinde kalır. docker image prune -a kullanma: geri dönüşün açacağı önceki imajı da silebilir.

# paketi elle indirdiyseniz: kurulum dizininin üstüne çıkart, sonra
# if you downloaded the package yourself: extract it over the install directory, then
cd myway-onprem   # kurulum dizininiz / your install directory
./scripts/install.sh   # önce yedek almayı sorar (varsayılan evet) / asks to back up first (default yes)

İnternet erişimi olmayan sunucu

1. 1İnternete açık bir bilgisayarda paketi indir: süper yönetici Ayarlar > Güncellemeler > "İnternet erişimi olmayan sunucu" bölümünde "İndirme bağlantısını kopyala" ve "Sürüm listesi bağlantısını kopyala" düğmelerini kullanır. Satın alma e-postasındaki bağlantı da her zaman en son paketi verir. Bağlantılar lisans anahtarını içerir, ekranda gösterilmez; kimseyle paylaşma.
2. 2Paketi (myway-onprem.tar.gz) scp ya da USB bellekle sunucuya, kurulum dizininin dışına (örneğin ev dizinine) kopyala; adını değiştirme, açma.
3. 3Kurulum dizininde önce ./scripts/update.sh --package ~/myway-onprem.tar.gz --check, sonra --check olmadan çalıştır. Paketin sürümü paketteki VERSION dosyasında, notları CHANGELOG.md dosyasındadır; ikisi de imzanın kapsamındadır.
4. 4Komut "Updated: MyWay ... is running." satırıyla biter; Ayarlar > Güncellemeler ve /api/health yeni sürümü gösterir. Başarısız olursa önceki sürüme kendiliğinden döner; yeniden denemek için .env.onprem’deki IMAGE_TAG satırını silip aynı --package komutunu çalıştır.

./scripts/update.sh --package ~/myway-onprem.tar.gz --check
./scripts/update.sh --package ~/myway-onprem.tar.gz

# notları kurmadan oku / read the notes without installing
tar -xzOf ~/myway-onprem.tar.gz myway-onprem/CHANGELOG.md | less

Güncellemeyi geri alma

v1.96.0’dan beri ./scripts/update.sh (ve uygulama içinden güncelleme), yeni sürüm MYWAY_UPDATE_HEALTH_TIMEOUT saniye içinde (varsayılan 150) sağlıklı açılmazsa ya da kurulum veya bir migrasyon hata verirse önceki sürüme kendisi döner. Önce .env.onprem içine IMAGE_TAG=<önceki sürüm> yazar ve önceki sürümü açar; migrasyonlar yalnız ekleme yaptığı için önceki sürüm yeni şemayla çalışır, veri yerinde kalır. Önceki sürüm de açılmazsa bu güncellemenin başında alınan yedeği, önceki sürüm sabitken restore.sh ile geri yükler. Sonuç Ayarlar > Güncellemeler geçmişinde "Geri alındı" olarak, hangi yolla dönüldüğü ve şu an çalışan sürümle görünür. IMAGE_TAG satırı bilerek kalır, yeniden başlatma yeni sürümü açmasın diye; satır dururken update.sh başlamaz. Sorunu giderdikten sonra satırı silip ./scripts/update.sh’i yeniden çalıştırın.

Elle geri alma: update.sh indirme ya da imza adımında durduysa hiçbir şey değişmemiştir, sorunu giderip yeniden deneyin. Yeni sürüm açılmıyor ama veritabanı sağlamsa .env.onprem’e önceki sürümü yazıp konteynerleri yeniden oluşturun; bu saniyeler sürer, veri yerinde kalır. Önceki imaj da açılmıyorsa ya da veri bozulduysa önce aynı şekilde önceki sürümü sabitleyin, sonra o sürümün güncelleme öncesi yedeğini geri yükleyin. Yeniden yeni sürüme geçmek için IMAGE_TAG satırını silip ./scripts/update.sh çalıştırın.

# önceki imajla aç / start the previous image
# .env.onprem: IMAGE_TAG=v1.102.0
docker compose -f docker-compose.onprem.yml --env-file .env.onprem up -d

# gerekirse yedekten / if needed, from the backup
./scripts/restore.sh --yes backups/2026-11-01-101500-v1.102.0

İmaj saklama

Başarılı bir güncellemeden sonra update.sh en yeni MYWAY_KEEP_IMAGES sürümün imajlarını tutar (varsayılan 2: kurulu sürüm ve otomatik geri dönüşün açacağı önceki sürüm), daha eskilerini siler. Çalışan ya da duran bir konteynerin kullandığı imaja, IMAGE_TAG ile sabitlenene ve başka depoların imajlarına dokunmaz. Elle çalıştırmak için ./scripts/prune-images.sh kullanın; --dry-run ne silineceğini gösterir, --keep N sayıyı o seferlik değiştirir.

./scripts/prune-images.sh --dry-run   # ne silinecek / what would go
./scripts/prune-images.sh

Uygulama içinden güncelleme

Ayarlar > Güncellemeler v1.110.0’da yeniden düzenlendi. Ekran kurulumun gerçek dizinindeki tek komutu (cd <dizin> ve ./scripts/update.sh) kopyalama düğmesiyle ve "Komut ne yapar" adımlarıyla gösterir; eski elle açma adımları kalktı. Yeni sürüm varsa ya da güncelleme servisine ulaşılamıyorsa "Güncellemeden önce" kutusu bakım saati seçmeyi, yaklaşık 600 MB boş diski, yedekleri başka makineye kopyalamayı, sürüm notlarını okumayı ve güncelleme hakkı bittiyse önce lisansı yenilemeyi önerir. Güncelleme denetimi açıkken "Güncelleme nasıl yapılır" özeti ve açılır "İnternet erişimi olmayan sunucu" bölümü her zaman durur; sunucu servise ulaşamıyorsa bu bölüm açık gelir. Bağlantı kopyalama düğmeleri yalnız süper yöneticide görünür.

v1.90.0’dan beri yeni sürüm sunucuya girmeden de kurulabilir: süper yönetici Ayarlar > Güncellemeler’deki Otomatik güncelleme kutusundan "Şimdi güncelle" ile hemen kurar ya da bir tarih ve saat seçip "Planla" der. Özellik varsayılan olarak kapalıdır ve kurulumda bir kez açılır: ./scripts/install.sh --auto-update. Kapatmak için ./scripts/install.sh --no-auto-update çalıştırın, ajan zamanlanmış görevlerden kaldırılır. Cevap .env.onprem içine MYWAY_AUTO_UPDATE olarak yazılır ve sonraki kurulumlarda yeniden sorulmaz; terminal olmadan çalışan kurulum, --auto-update verilmedikçe kapalı bırakır.

Uygulama güncellemeyi kendisi yapmaz ve Docker’a erişmez; yalnız isteği veritabanına yazar. Kurulumu ana makinedeki küçük bir ajan (scripts/update-agent.sh) yapar: kurulum betiğini çalıştıran kullanıcının crontab’ına dakikada bir çalışan bir satır olarak eklenir, ayrı bir servis değildir ve port açmaz. Her dakika bir yoklama yazar, zamanı gelmiş isteği üstlenir ve ./scripts/update.sh’ı çalıştırır; update.sh paketi indirir, imzasını doğrular, yedek alır ve kurar, sonuç ekrana geri yazılır. İki çalıştırma üst üste binmez; 90 dakikadan uzun süren bir kurulum yarıda kalmış sayılır ve Başarısız olarak işaretlenir. Zamanlanmış görevleri kapatan NO_CRON=1 ile ajan da kurulmaz.

• Kutunun başında ajanın durumu yazar: "Sunucudaki güncelleme ajanı çalışıyor", "Güncelleme ajanı yanıt vermiyor" (5 dakikadır yoklama yoksa), "Güncelleme ajanı kurulu ama sunucuda çalışamıyor" (kurulumda açılmış ama hiç yoklamamış; macOS’ta korumalı klasör, bkz. Kurulum) ya da "Bu sunucuda otomatik güncelleme açık değil"; ajan çalışmıyorsa düğmeler yerine açma komutu gösterilir
• "Şimdi güncelle" kurulumu iki dakika sonraya planlar, o sırada uygulamada olanlar işini kaydedebilsin. Planlama en fazla 30 gün ileriye yapılır ve seçilen saat sizin saat diliminizdedir (Ayarlar > Tercihler, seçilmemişse tarayıcınızınki); ajan dakikada bir baktığı için kurulum planlanan saatten sonraki dakika içinde başlar
• Aynı anda tek plan olabilir. Plan başlamadan "Planı iptal et" ile kaldırılır, başlamış kurulum iptal edilemez. Planlama ve iptal Çalışma Alanı Denetim Kaydı’na yazılır
• Planlamak için yeni sürüm olması, lisansın güncelleme hakkının sürmesi ve ajanın çalışıyor olması gerekir. Ajan, planlandığı anda gösterilen sürümü değil, kurulum anındaki en son paketi kurar
• Planlanan saatten 15 dakika önce ve kurulum sürerken bütün kullanıcıların ekranının üstünde uyarı bandı çıkar; kurulum sırasında sistem genellikle birkaç dakika kapalı kalır
• "Son güncellemeler" listesi sonuçları (Başarılı, Başarısız, Geri alındı, İptal edildi) eski ve yeni sürümle gösterir; Geri alındı satırı hangi yolla dönüldüğünü (önceki imaj ya da güncelleme öncesi yedek) ve şu an çalışan sürümü yazar; başarısız kurulumda "Hata ayrıntısı" kaydın son satırlarını açar. Ajanın kaydı logs/update-agent.log, her kurulumun kaydı logs/update-<istek>.log dosyasındadır

Bakım sayfası (v1.90.0): güncelleme ya da yeniden başlatma sırasında uygulamaya ulaşılamadığında, ürünle gelen ters vekil (Caddy) tarayıcının hata sayfası yerine kendiliğinden yenilenen bir bakım sayfası gösterir; sistem açılınca kullanıcı kaldığı adrese döner. Bu yalnız uygulama içinden güncellemede değil, elle güncellemede ve her yeniden başlatmada da çalışır. MyWay’i kendi ters vekilinizin arkasına aldıysanız bu sayfa onda yoktur.