Kurulum (self-host)

MyWay, Next.js uygulaması + PostgreSQL veritabanından oluşur. En hızlı yol Docker Compose ile ayağa kaldırmaktır.

Gereksinimler

• Docker Engine 24+ ve Docker Compose v2
• 2 vCPU / 2 GB RAM (önerilen 4 GB)
• 10 GB boş disk; yükseltme sırasında geçici olarak ~1 GB fazlası
• Alan adı (opsiyonel: iç ağda sunucunun IP adresiyle de kurulur)

Adımlar

1. 1Satın alma e-postandaki paketi indir ve sunucuna çıkart.
2. 2./scripts/install.sh çalıştır. Hazır imajları yükler (derleme yok) ve adresi, yayın portlarını ve LİSANS ANAHTARINI sorar; adres bir alan adıysa sertifika bildirimleri için bir e-posta da ister. Ardından günlük otomatik yedeği kurmayı önerir ve uygulama içinden güncellemeyi açmak isteyip istemediğini sorar ("Turn on in-app updates? [y/N]", varsayılan hayır; bkz. Yedekleme & yükseltme). Bellek sınırını da bir kez sorar ("App memory cap [no cap]:"); boş bırakmak sınır yok demektir ve sunucu yalnız MyWay’e ayrıldıysa önerilen budur (v1.109.1).
3. 3Adres: alan adın varsa onu yaz. Yoksa Enter’a bas; kurulum sunucunun IP adresini bulup onu kullanır.
4. 4Port: varsayılan 80/443 için Enter. O portları başka bir servis kullanıyorsa 8080/8443 gibi bir çift verebilirsin.
5. 5Uygulama başlar; migrasyonlar otomatik uygulanır.
6. 6Tarayıcıdan adrese gir ve kaydol. Kaydolan ilk kullanıcı otomatik yönetici (superadmin) olur; kurulum betiği bunu ilk kurulumun sonunda hatırlatır, güncellemede bu uyarı çıkmaz.

# extract the package, then:
cd myway-onprem
./scripts/install.sh    # asks for address, ports, LICENSE_KEY (+ certificate email for a domain) and the daily backup, loads images, starts

İç ağa kurulum (alan adı olmadan)

Sunucunun alan adı yoksa kurulum sunucunun IP adresiyle yapılır; betik adresi kendisi bulup önerir. Bu durumda Let’s Encrypt devreye girmez (bir sertifika otoritesi IP adresini doğrulayamaz) ve uygulama kendi ürettiği sertifikayla yayınlanır. Tarayıcı ilk girişte bir kez uyarı gösterir; kalıcı olarak kaldırmak için kurulum dizinine bırakılan myway-root-ca.crt dosyasını istemci bilgisayarlara güvenilen kök sertifika olarak kurun.

macOS’ta kurulum

macOS, cron’un İndirilenler, Masaüstü, Belgeler ve iCloud Drive klasörlerini okumasına izin vermez. Paket bu klasörlerden birine açılırsa zamanlanmış görevler (uygulama içinden güncelleme ajanı, günlük yedek, bildirimler) her dakika "Operation not permitted" hatasıyla düşer ve Ayarlar > Güncellemeler "Güncelleme ajanı kurulu ama sunucuda çalışamıyor" der. Kurulum betiği bu durumu görünce uyarır (v1.102.0). İki çözümden birini uygulayın: cron’a Tam Disk Erişimi verin (Sistem Ayarları > Gizlilik ve Güvenlik > Tam Disk Erişimi > +, Cmd+Shift+G ile /usr/sbin/cron yazıp ekleyin ve açın) ya da kurulumu ~/myway-onprem gibi korumasız bir klasöre taşıyıp ./scripts/install.sh’ı orada yeniden çalıştırın. Veri Docker birimlerinde durduğu için taşımada kaybolmaz. Düzelip düzelmediğini kurulum dizininde ./scripts/macos-cron-check.sh ile denetleyin; sorun yoksa hiçbir şey yazmaz.

Portu değiştirme

Kurulum 80 ve 443 portlarını kullanır. Sunucuda bu portları başka bir servis tutuyorsa kurulumda farklı bir çift verebilirsiniz; seçim saklanır ve sonraki güncellemelerde yeniden sorulmaz. Standart dışı portta Let’s Encrypt doğrulama yapamayacağı için kurulum kendi sertifikasına geçer: güvenilir sertifika istiyorsanız ya 80/443’te kalın ya da MyWay’i TLS’i kendisi sonlandıran mevcut proxy’nizin arkasına alın.

# soruları görmeden kurmak / installing without the prompts
DOMAIN=myway.company.com HTTP_PORT=8080 HTTPS_PORT=8443 ./scripts/install.sh

E-posta gönderimi (opsiyonel)

Kurulum e-posta olmadan da tam çalışır; varsayılan budur. Bu durumda pano davet bağlantısı da, Ayarlar > Kullanıcılar > "Kullanıcı oluştur" ile açılan hesabın parola belirleme bağlantısı da yöneticiye ekranda gösterilir ve yönetici bunu kişiye kendisi iletir. Parolayı Ayarlar > Kullanıcılar’dan yönetici sıfırlar; süper yöneticinin parolasını yalnız bir süper yönetici sıfırlayabilir (v1.108.1). E-posta göndermek istersen .env.onprem dosyasına kendi SMTP sunucunu tanımlarsın: Exchange, Postfix, Google Workspace, AWS SES; hepsi SMTP konuşur. Dışarıya bağlanan bir servis eklemiş olmazsın, mail kendi sunucundan çıkar.

MAIL_DRIVER=smtp
MAIL_FROM="MyWay <no-reply@yourcompany.com>"
MAIL_SMTP_HOST=smtp.yourcompany.com
MAIL_SMTP_PORT=587          # 465 = implicit TLS, 587/25 = STARTTLS
MAIL_SMTP_USER=username
MAIL_SMTP_PASSWORD=password

Env değişikliği restart ile okunmaz; konteyneri yeniden oluşturman gerekir. Ardından davet e-postası, parola sıfırlama, e-posta adresi doğrulama ve bildirim e-postaları kendiliğinden çalışır. Sunucu geçici bir hata verirse (4xx yanıtı, bağlantı kopması) gönderim iki saniye sonra bir kez yeniden denenir; bu kayıtlar Uygulama günlüğünde "Dış servis" türüyle görünür. Bildirim e-postaları v1.106.0’dan beri ayrıca kuyruktan gider: istek beklemez, uygulamanın içindeki gönderici birkaç saniyede bir yollar ve gönderilemeyeni 1 dk, 5 dk, 30 dk ve 2 saat arayla toplam beş kez dener. Davet, parola sıfırlama ve e-posta doğrulama kuyruğa girmez, doğrudan gider. Bağlantılar PUBLIC_URL üzerinden üretilir; bu adresin kullanıcılarınca erişilebilir olduğundan emin ol.

docker compose -f docker-compose.onprem.yml --env-file .env.onprem up -d

Ayarın uygulamaya gerçekten ulaştığını sağlık ucundan doğrulayın: /api/health yanıtındaki mailConfigured alanı true olmalıdır. Yanlış yazılmış ya da konteynere hiç geçmemiş bir e-posta ayarı ekranda hata üretmez, yalnız e-posta gitmez; bu alan o sessiz durumu görünür kılar.

# e-posta ayarı uygulamaya ulaştı mı / did the email settings reach the app
curl -s https://myway.company.com/api/health | grep mailConfigured

# kendi sertifikasıyla çalışan kurulumda (IP adresi ya da standart dışı port)
# on an install with its own certificate (IP address or non-standard ports)
curl -s --cacert myway-root-ca.crt https://10.0.0.5/api/health | grep mailConfigured

Saat dilimi

v1.98.0’dan beri saatler uygulamada, e-postalarda ve dışa aktarmalarda her kişinin kendi saat diliminde, komut satırında bilgisayarın yerel diliminde gösterilir. Dilim tarayıcıdan kendiliğinden alınır, kişi Ayarlar > Tercihler > Saat dilimi’nden elle de seçebilir. .env.onprem içindeki DEFAULT_TIME_ZONE kurulumun varsayılan dilimidir: dilimi henüz bilinmeyen bir alıcıya giden e-postada, formül alanında başlama, bitme ve oluşturulma anının hangi gün ve saate düştüğünün hesabında (iş saati sonucu buna bağlıdır, v1.105.0) ve performans widget’larında kullanılır; boşsa sunucunun dilimi geçerlidir (Docker’da genelde UTC). IANA adı yazın, örneğin DEFAULT_TIME_ZONE=Europe/Istanbul; değişiklik için konteyneri yeniden oluşturun. Son tarih gibi gün değerleri hiçbir dilimde kaymaz.

# .env.onprem
DEFAULT_TIME_ZONE=Europe/Istanbul

# ardından / then
docker compose -f docker-compose.onprem.yml --env-file .env.onprem up -d

Kaynak sınırları (isteğe bağlı)

v1.109.1’den beri uygulama konteynerinde varsayılan bellek sınırı yoktur (APP_MEM_LIMIT=0); Node kendi bellek tavanını seçer. Sunucuyu başka servislerle paylaşıyorsanız .env.onprem içinde APP_MEM_LIMIT ile bir sınır verin, örneğin 4g; yüklenen dosya bellekte tamponlandığı için MAX_UPLOAD_MB yüksekse sınırı da cömert tutun. Veritabanı bağlantı havuzunun üst sınırı PG_POOL_MAX (varsayılan 10), sorgu zaman aşımı PG_STATEMENT_TIMEOUT_MS’dir (milisaniye, varsayılan 30000). v1.109.0’daki APP_NODE_HEAP_MB artık kullanılmaz. Değişiklik için konteyneri yeniden oluşturun; yeniden başlatmak yetmez.

# .env.onprem
APP_MEM_LIMIT=4g

# then recreate the containers
docker compose -f docker-compose.onprem.yml --env-file .env.onprem up -d

Yükleme boyutu sınırı

Ekler ve metne gömülen görseller için üst sınır varsayılan olarak 25 MB’tır, en fazla 500 MB’a çıkarılabilir. v1.87.0’dan beri süper yönetici bunu Ayarlar > Sistem sınırları’ndaki "En büyük dosya (MB)" alanından değiştirir, konteyneri yeniden oluşturmak gerekmez. .env.onprem içindeki MAX_UPLOAD_MB (megabayt) hâlâ okunur ama yalnız varsayılanı belirler: ekranda bir değer kaydedilmişse o geçerlidir. v1.109.1’den beri ürünle gelen ters vekil (Caddy) istek boyutunu uygulamaya ulaşmadan denetler: dosya yüklemelerinde ayarın çıkabileceği tavanın (500 MB) üstünü, öteki isteklerde 40 MB’ın üstünü reddeder; geçerli dosya sınırı yine bu ayardır. Tam etkisi için Caddy imajı güncel olmalıdır: docker compose -f docker-compose.onprem.yml pull caddy. v1.110.0’dan beri sınırı aşan dosya gönderilmeye çalışılmaz, seçildiği anda dosya adı ve sınırla birlikte uyarı çıkar. MyWay’i kendi proxy’nizin arkasına aldıysanız onun istek gövdesi sınırını da yükseltin, yoksa yükleme proxy’de kesilir. İzin verilen dosya tipleri sabittir: görsel (PNG, JPG, GIF, WebP), video (MP4, WebM), ses (MP3, OGG), PDF, Word, Excel, metin (TXT, CSV, Markdown), ZIP ve draw.io; SVG ve HTML de yüklenebilir ama içlerine betik gömülebildiği için her zaman indirilecek dosya olarak sunulur, tarayıcıda açılmaz.

MAX_UPLOAD_MB=100

Sistem sınırları

Ayarlar > Sistem sınırları sekmesini yalnız süper yönetici görür (v1.87.0). Sınırlar kurulumun tamamı için geçerlidir. Her alanın altında varsayılanı ve izin verilen aralığı yazar; hiçbiri sıfıra ya da sınırsıza çekilemez. Boş bırakılan alan varsayılanda kalır, "Varsayılana dön" alanı boşaltır. Bir sınırı düşürürken "Sınırlar düşürülsün mü?" onayı çıkar. Değişiklik en geç 30 saniye içinde uygulanır ve Çalışma Alanı Denetim Kaydı’na düşer. Giriş ve kayıt deneme sınırları ile istek boyutu sınırı saldırılara karşı koruma olduğu için buradan değiştirilemez. Yazma hızı sınırları kullanıcı başınadır.

app.themyway.app/settings/limits

Ayarlar menüsü, Kullanım sayfası ve kullanıcı ayrıntısı

Ayarlar menüsü üç gruptur: Hesabım (Hesap, Tercihler, Bildirimler, Bağlı hesaplar, Erişim anahtarları), Çalışma alanı (Kullanıcılar, Gruplar, Pano Kodları, Entegrasyonlar, Lisans, Güncellemeler) ve yalnız süper yöneticide Sistem (Sağlık, Kullanım, Sistem sınırları, Sistem raporları). Kişinin göremediği sekme ve boş kalan grup gösterilmez; gruplar başlığından kapatılır, menü tek düğmeyle gizlenir (v1.94.0, v1.95.0). Ayarlar > Kullanım (v1.101.0) günlük, haftalık ve aylık etkin kullanıcıları, kullanım yoğunluğunu (gün x saat), panolarda geçen süreyi, uzun süredir hareketsiz panoları, tek kişiye bağlı panoları, en çok ve hiç kullanılmayan özellikleri, panel kartlarını, dışa aktarma biçimlerini, API/CLI kullanımını, koltukları ve uzun süredir etkileşimsiz kullanıcıları gösterir. Sağlık ekranında ya da Kullanıcılar listesinde bir kişiye tıklayınca Kullanıcı etkinliği paneli açılır: durum, son etkileşim, son API/CLI kullanımı, katkılar ve erişim özeti (panolar, gruplar, etkin erişim anahtarları, bağlı GitLab hesabı). Bu paneli açmak denetim kaydına yazılır.

Ayrıntılı etkinlik kaydı varsayılan olarak kapalıdır ve yalnız süper yönetici Ayarlar > Kullanım’dan açar. Açıkken her kişinin hangi panoda, hangi görünümde ve sayfada ne kadar süre geçirdiği kaydedilir, yalnız sekme ön plandayken ve etkileşim varken. Saklama süresi 7 ile 365 gün arasıdır, varsayılan 90. Kayıt açıkken bütün kullanıcılar bunu Ayarlar > Hesap’ta görür ve "Etkinliğim" ile kendi kaydına bakabilir. Kaydı kapatmak tutulmuş ayrıntılı etkinliği kalıcı olarak siler. Özellik kullanım sayaçları (hangi görünüm, dışa aktarma, CLI kullanımı) kişi bilgisi tutmaz ve bu ayardan bağımsız olarak her zaman sayılır.

Zamanlanmış görevler

Bazı işler bir kullanıcı isteğiyle tetiklenmez, birinin saate bakması gerekir. Son tarihin gelmesi bir olay değildir: kimse bir şey yapmadığı için uygulamaya ulaşan bir istek de olmaz. MyWay bu tür iki iş çalıştırır ve v1.32.6 sürümünden beri bunları KURULUM BETİĞİ kendisi kurar; elle crontab girdisi yazmanız gerekmez. Sistem raporu e-postaları ve bildirim e-postası kuyruğu cron’a bağlı değildir, uygulamanın kendisi zamanlar; NO_CRON=1 bunları etkilemez.

Kurulum betiği girdileri yazar, kurulum sonunda işi bir kez deneyip sonucu ekrana bildirir ve ek yapılandırma istemez: gereken sır tanımlı değilse mevcut kurulum anahtarlarınızdan türetilir. Güncellemede girdiler tazelenir, çiftlenmez; sunucudaki başka zamanlanmış işlere dokunulmaz. v1.64.0’dan önceki sürümlerin kurduğu olay temizliği girdisini güncelleme kendisi kaldırır. İşler her gün 06:00 (son tarih bildirimleri) ve 07:00’de (gözden geçirme hatırlatmaları) çalışır, çıktıları kurulum dizinindeki logs/cron.log dosyasına yazılır; kurmak istemiyorsanız betiği NO_CRON=1 ile çalıştırın (bu durumda günlük otomatik yedek de zamanlanmaz). İşler PUBLIC_URL adresini çağırdığı için sunucu kendi adresine erişebilmelidir. Sağlık ucundaki cronConfigured alanı yalnız yapılandırmayı gösterir; işlerin gerçekten çalışıp çalışmadığını Ayarlar > Sağlık ekranındaki Zamanlanmış işler tablosu gösterir (aşağıdaki Sağlık ekranı bölümüne bakın).

# zamanlanmış görevler kuruldu mu / are the scheduled jobs configured
curl -s https://myway.company.com/api/health | grep cronConfigured

Sağlık ekranı

Ayarlar > Sağlık sekmesini yalnız superadmin görür; kurulumun durumunu tek ekranda özetler. Üstte toplamlar yer alır: görev (açık ve biten), pano (arşivdekiler ayrıca), kullanıcı (koltuk sınırıyla), doküman sayfası, yorum ve ek dosya (toplam boyutuyla). Altında Sunucu kaynakları, En kötü değerler, Depolama ve Kontroller kartları, sonra şu an çevrimiçi olanların tamamı (liste kendi içinde kayar), aktiflik (bugün ve bu hafta aktif, 30+ gündür girmemiş, hiç görülmemiş, deaktif hesap; e-posta yapılandırılmışsa doğrulanmamış e-posta) ve sistem bilgisi (sürüm, yapı, veri, e-posta ve depolama sürücüsü) gelir. Ekran açıkken kaynak ve kontrol kartları 10 saniyede bir tazelenir (v1.86.2). "Komut satırı ve MCP" kartı (v1.108.0) komut satırı aracını ya da Claude Desktop araçlarını kullanan kişileri, kullandıkları sürüm ve son kullanım zamanıyla listeler; sunucunun dağıttığından eski sürümler işaretlenir, kişi myway self-update ile güncelleyebilir.

Sunucu kaynakları kartında İşlemci, Bellek ve Disk (yüklemeler) için halka göstergeler vardır; durum renkle birlikte kelimeyle de yazar: Normal, Yüksek, Kritik ya da Ölçülemedi. Eşikler işlemcide %70 ve %90, bellekte sunucu belleğinin %90 ve %95 dolu olması, diskte %85 ve %95 doluluktur. Yanlarında veritabanı boyutu, event loop gecikmesi (p99), uygulama ve sunucu çalışma süresi yazar. Altta işlemci, uygulama belleği, ağ trafiği (gelen ve giden) ve event loop gecikmesi için son bir saatin grafikleri vardır. Değerler uygulama konteynerinin içinden (cgroup v2 ve /proc) 10 saniyede bir ölçülür, Docker soketi kullanılmaz; bu grafikler uygulama yeniden başlayınca sıfırlanır. En kötü değerler kartı son 24 saatin en yüksek işlemci, bellek, event loop ve ağ değerlerini ve en az boş diski ne zaman olduklarıyla gösterir, altında son 30 günün günlük en kötü değerleri tablo hâlinde durur; bu değerler saat başına tutulur, 31 gün saklanır ve yeniden başlatmadan etkilenmez (v1.91.0). Depolama kartı yükleme diskini Veritabanı, Dosyalar, Diğer (uygulama, imajlar, yedekler, sistem) ve Boş diye böler, eklerle en çok yer kaplayan beş panoyu listeler (v1.87.0).

Ölçülemeyen satırlar (ör. TLS, güncelleme beslemesi) kritik değil, Ölçülemedi durumunda görünür. Kontroller kartı her satırın altında ne yapılacağını da yazar. Aktiflik kartındaki sayılara ya da çevrimiçi kartındaki "Kişileri ve son görülme zamanlarını gör" düğmesine tıklayınca o grubun kişileri son görülme tarih ve saatiyle açılır; pencerede gruplar arasında geçilir (Çevrimiçi, Bugün aktif, Bu hafta aktif, 30+ gündür girmemiş, Hiç girmemiş, Devre dışı), ad, e-posta ya da kullanıcı adıyla aranır, son görülmeye ya da ada göre sıralanır. 30+ gündür girmemiş grubu, koltuk planlamasında boşa duran hesapları bulmak içindir. Çevrimiçi listesinde her kişinin yanında durumu (Aktif, Boşta ya da Çevrimdışı) ve son etkileşim zamanı yazar; durum yalnız gerçek etkileşimden hesaplanır: son 2 dakikada etkileşen Aktif, 15 dakikaya kadar Boşta, sonrası Çevrimdışıdır. Arka plandaki sorgular, komut satırı ve yapay zekâ asistanı istekleri kişiyi çevrimiçi göstermez; bunlar aktiflik kartında ayrıca sayılır. Bir kişinin adına tıklayınca Kullanıcı etkinliği paneli açılır (v1.101.0).

Zamanlanmış işler tablosu her iş için zamanlamayı, son çalışmayı, sonucu, süreyi ve sonraki çalışmayı gösterir. Sonuç "Başarılı", "Hata", "Gecikti" ya da "Çalışmadı" olur ve altında işin sayaçları (örneğin kaç bildirim gönderildiği) ya da hata mesajı yazar. Son çalışması 26 saatten eski iş "Gecikti", hiç çalışmamış iş "Çalışmadı" olarak işaretlenir; hiçbir iş çalışmamışsa tablonun üstünde ayrıca bir uyarı çıkar. Zamanlama sütunu sunucu saatidir, çünkü cron ana makinenin saat diliminde çalışır; sonraki çalışma sizin saat diliminizle gösterilir. Gece yedeği de bu tabloda "Yedekleme" satırıyla yer alır (bkz. Yedekleme & yükseltme).

app.themyway.app/settings/health

Aynı ekrandaki Uygulama günlüğü kartı, uygulamanın ürettiği uyarı ve hata kayıtlarını listeler; bilgi ve ayrıntı (debug) seviyesindeki satırlar burada tutulmaz, yalnız konteyner logunda kalır. Kayıtlar veritabanında 30 gün saklanır: konteyner logunun aksine yeniden başlatma ve güncellemeden etkilenmez, böylece güncellemeden önce yaşanan bir hata da sonradan bulunur. Liste seviyeye (Tüm seviyeler, Hata, Uyarı), türe (Tüm türler, Olası bug, Dış servis, Yapılandırma, Kullanıcı girdisi) ve tarih-saat aralığına (Başlangıç, Bitiş; bitiş dakikası dahildir, "Tarihi temizle" aralığı kaldırır) göre süzülür; arama kutusu mesajda geçen bir metni ya da bir başvuru kodunun tamamını kabul eder. "Filtrelenenleri dışa aktar" yalnız seviye, tür, metin ve tarih süzgecine uyan kayıtları JSON dosyası olarak indirir (en fazla 5000); destek paketi bundan bağımsızdır ve eksiksizdir. Her satırda zaman, seviye, tür, işlemi yapan kullanıcı (v1.71.0 sonrası kayıtlarda), mesaj ve başvuru kodu görünür. Tür kaydın içeriğinden hesaplanır, eski kayıtlarda da gösterilir; tanınmayan her kayıt olası bug sayılır. Türün üstüne gelince ya da satıra tıklayınca gerekçesi ve ne yapılabileceği yazar (ör. e-posta sunucusu geçici olarak reddetti, gönderim bir kez yeniden denenir); ayrıntısı olan satıra tıklayınca hatanın bağlamı açılır: isteğin yöntemi ve geldiği yol (örneğin PATCH /api/tasks/…, sorgu dizgisi alınmaz). Ayrıntıdaki kullanıcı kimliklerinin yanında kişinin adı yazar. Beklenmeyen veritabanı hatalarında hata kodu, ilgili kısıt, tablo, kolon ve sorgu değerleri de görünür, böylece hatanın hangi kayıtta çıktığı anlaşılır; parola özeti, token ve şifreli anahtar gibi değerler maskeli kalır. Liste 50 kayıtlık sayfalarla gelir, devamı "Daha eski kayıtlar" ile yüklenir. Saklama süresi dolan kayıtlar yeni kayıt yazılmasa da silinir (v1.110.0).

Kayıt yazılmadan önce adı parola, gizli anahtar, belirteç (token), çerez, Authorization başlığı ya da lisans anahtarı olduğunu söyleyen alanların değeri [redacted] ile değiştirilir; sır taşıyan kolonlara (parola özeti, token, şifreli anahtar) giden sorgu değerleri ve sır biçimindeki değerler maskelenir. Destek paketinde sorgu parametreleri tümden kesilir. Döngüye giren bir hatanın tabloyu doldurmaması için dakikada 30, günde 5000 kayıt sınırı vardır: sınırı aşan kayıtlar tabloya yazılmaz, yerlerine kaç kaydın bastırıldığını bildiren tek bir uyarı satırı düşer. Konteyner logunda ise her satır yine yer alır. v1.110.0’dan beri aynı seviye ve mesajla 60 saniye içinde tekrarlanan kayıt tek satır olarak yazılır ve tekrar sayısı kaydın ayrıntısında tutulur; tekrarlar sınıra sayılmaz. Hız sınırına takılma kullanıcı başına bir kez, "Kullanıcı girdisi" türünde yazılır. Sekme kapanınca yarıda kalan istekler hata sayılmaz. GitLab yetki ve yapılandırma sorunları uyarı düzeyinde tek satırdır.

Kartın üstündeki "Destek paketi indir" düğmesi, uygulamanın kendi gördüğü tanı bilgisini tek bir JSON dosyası olarak indirir (myway-support-<tarih-saat>.json). Dosyada sürüm ve yapı bilgisi, veri, e-posta ve depolama sürücüleri, zamanlanmış işlerin durumu, lisans durumu, toplamlar, çevrimiçi kullanıcıların yalnız sayısı, komut satırı ve MCP kullanıcıları kişi yerine sürüme göre toplam sayı olarak, zararsız birkaç ayarın değeri, diğer ayarların ise yalnız dolu olup olmadığı ve son 7 günün uygulama günlüğü (en fazla 1000 kayıt) bulunur. Kişi adları, sorgu değerleri ile parola ve anahtar değerleri dosyaya girmez. Günlük satırlarındaki e-posta adreslerinin kullanıcı kısmı maskelenir (alan adı kalır), e-posta konu satırları pakete girmez (v1.110.0). Ters vekil ve veritabanı logları ile konteynerlerin durumu bu dosyada yoktur; onlar için aşağıdaki destek paketi betiğini kullanın (bkz. Loglar ve destek).

app.themyway.app/settings/health

Loglar ve destek

Bir hatanın izini sürmek için iki kaynak vardır: uygulamanın içindeki Uygulama günlüğü ve sunucudaki konteyner logları. Hangisine bakacağınız, kaydın ne kadar eski olduğuna ve sorunun nerede yaşandığına bağlıdır.

Kullanıcı beklenmeyen bir sunucu hatasıyla karşılaştığında hata mesajının sonunda bir başvuru kodu görür, örneğin "(Başvuru kodu: 7f3a9c2b1e04)". Kod her isteğe ayrı verilen 12 karakterlik bir kimliktir ve o isteğin log satırlarına yazılır. Kullanıcının kodu yöneticiye iletmesi yeterlidir: superadmin kodu Ayarlar > Sağlık’taki Uygulama günlüğü kartının arama kutusuna yapıştırır ve o isteğin kaydını ayrıntısıyla bulur. Aynı kod konteyner logunda da aranabilir. Bizden destek isterken de bu kodu iletin.

# başvuru koduyla konteyner logunda arama / find a reference code in the container log
docker compose -f docker-compose.onprem.yml --env-file .env.onprem logs app | grep 7f3a9c2b1e04

Uygulama hiç açılmıyorsa ya da sorun ters vekilde, veritabanında veya konteynerlerde ise kurulum dizininde ./scripts/support-bundle.sh betiğini çalıştırın; desteğe göndereceğiniz her şeyi tek dosyada toplar ve uygulama ayakta olmasa da çalışır. Betik varsayılan olarak son 24 saati toplar; --since ile aralık (30m, 72h, 3d gibi), --out ile dosyanın yazılacağı dizin değişir. Sonuç kurulum dizinindeki support/ altında myway-support-<tarih-saat>.tar.gz adlı tek dosyadır ve yalnız betiği çalıştıran kullanıcı okuyabilir. Bu dosyayı destek talebinize ekleyin.

./scripts/support-bundle.sh               # son 24 saat / last 24 hours
./scripts/support-bundle.sh --since 72h   # daha geniş aralık / a wider window
./scripts/support-bundle.sh --out /tmp    # başka bir dizine yaz / write elsewhere

• Tarih, sunucu, kurulu sürüm, Docker ve Compose sürümleri
• Konteynerlerin durumu ve, uygulama ayaktaysa, sağlık ucunun yanıtı
• Disk kullanımı ve Docker’ın disk kullanımı
• .env.onprem ayarlarından hangilerinin dolu olduğu: değer yalnız adres, port, sertifika modu, imaj sürümü, sürücüler, SMTP sunucusu ve portu, log seviyesi, yükleme sınırı gibi zararsız ayarlar için yazılır, diğerleri yalnız "<set>" ya da "<empty>" olarak geçer
• Crontab’daki MyWay bloğu (zamanlanmış işler)
• Tüm servislerin (app, caddy, postgres, migrate ve diğerleri) seçilen aralıktaki konteyner logları
• logs/cron.log ve logs/backup.log dosyalarının son 2000 satırı

Ürünle gelen ters vekil (Caddy) her HTTP isteğini; hangi istemcinin hangi adrese ne zaman istek yaptığını ve dönen durum kodunu JSON satırı olarak kendi konteyner loguna yazar. Oturum çerezi ve Authorization başlığı kayda açık yazılmaz. Davet, parola sıfırlama ve e-posta doğrulama bağlantılarının adresindeki tek kullanımlık anahtar kayıtta [redacted] olarak görünür; logu okuyan biri bu bağlantıları yeniden kullanamaz.

Konteyner logları boyut sınırıyla döndürülür ve aylarca açık kalan bir kurulumda diski doldurmaz: app, caddy ve postgres için konteyner başına en fazla 5 dosya, her biri 10 MB; sınır dolunca en eski dosya silinir. Tek seferlik servislerde (migrate, volume-init) sınır yoktur, logları birkaç satırdır. docker compose ... logs her zamanki gibi çalışır.

Ayrıntı seviyesi .env.onprem dosyasındaki LOG_LEVEL ile değişir: debug, info, warn ya da error; varsayılan info. Destek ekibi istediğinde geçici olarak debug yapın, sorun çözülünce geri alın: debug çok ayrıntılıdır ve logların daha hızlı dönmesine yol açar. Değişiklik env okunduğu için konteynerin yeniden oluşturulmasını ister, restart yetmez. Seviyeyi error yaparsanız uyarılar Uygulama günlüğü’ne de düşmez.

# .env.onprem
LOG_LEVEL=debug

# ardından / then
docker compose -f docker-compose.onprem.yml --env-file .env.onprem up -d

Logları kendi SIEM sisteminize göndermek için kurulum dizinine bir docker-compose.override.yml dosyası koyun ve app, caddy ve postgres servislerinin Docker log sürücüsünü (örneğin syslog, gelf ya da fluentd) orada değiştirin. Uygulama ve Caddy logları satır başına bir JSON nesnesidir, ek ayrıştırıcı gerekmez. Paket bu dosyayı içermez, bu yüzden güncellemede üzerine yazılmaz. Kurulum, yedek ve geri yükleme betikleri ile destek paketi betiği dosya varsa onu kendiliğinden kullanır; güncellemede ayarınız kaybolmaz. Docker, compose dosyası -f ile verildiğinde override dosyasını kendiliğinden okumadığından, elle yazdığınız compose komutlarında iki dosyayı birlikte verin:

docker compose -f docker-compose.onprem.yml -f docker-compose.override.yml --env-file .env.onprem up -d