2026'da Memos'u Self-Host Etme: Notlar, API Erişimi ve Yedekler

Memos'u bir Docker image'ı olarak değil, küçük bir sistem olarak ele alın. Memos'un kullanıcıya sunduğu hedef nettir: API'ye sahip hızlı Markdown notları. Ancak deployment, yalnızca private bir memo ve attachment oluşturabildiğiniz, bunları API üzerinden alıp düzenleyebildiğiniz ve container değiştirildikten sonra da kaldığını doğrulayabildiğiniz zaman kabul edilebilir.

Bu ayrım, operatörlerin local testlerden sonra karşılaştığı arızayı ortaya çıkarır: database dosyası container katmanında bulunur ve container değiştirildiğinde kaybolur. Ayrıca backup ve upgrade planını test edilebilecek kadar somut hâle getirir.

Local komutu incelenebilir bir servise dönüştürün

İlk container'ı silip yeniden oluşturmak kolay olmalıdır. Verileri writable layer'ın dışında tutun, 5230 portunu yalnızca proxy'nin erişebileceği şekilde bind edin ve configuration'ı runtime sırasında aktarın.

docker run -d \
  --name memos \
  --restart unless-stopped \
  -p 127.0.0.1:5230:5230 \
  -v memos-data:/var/opt/memos \
  neosmemo/memos:stable --mode prod --port 5230

İlk testten sonra image'ı sabitleyin. Son restart mesajı yerine en erken startup error'ını okuyun, her mount'u docker inspect ile doğrulayın ve private bir memo ile attachment oluşturup bunları API üzerinden alırken, düzenlerken ve container değiştirildikten sonra kaldığını doğrularken log'ları takip edin. Bu sıra, hatalı bir image komutunu dependency veya permission sorunundan ayırır.

Önce Memos için başarı kriterini tanımlayın

Memos için dört unsuru birbirinden ayırın: ingress, 5230 portunu dinleyen listener, kalıcı state ve supporting service'ler ya da local capacity. Local runtime gereksinimi, embedded database ve asset'ler için tek bir durable volume'dür. Bu sınırı yayınlamadan önce ve container değiştirildikten sonra yeniden test edin.

Bu ayrımı tamamlanmış kabul etmeden önce bilinen doğru transaction'ı — private bir memo ve attachment oluşturun, bunları API üzerinden alın, düzenleyin ve container değiştirildikten sonra kaldığını doğrulayın — çalıştırın. SQLite writes, attachment growth, API traffic ve biriken notlar üzerinde search metriklerini ölçün ve sonucu deployment kaydıyla birlikte saklayın. Bu sonuç hem bir acceptance criterion hem de ilk capacity baseline'ı sağlar.

Memos'a tüm host'u vermeyin

Memos için değerli surface mutlaka landing page değildir. En büyük hata, registration'ı gerekenden uzun süre açık bırakmaktır. Buna bilinçli şekilde karşı koyun: uygun olduğunda registration'ı kapatın ve private memo'ları güçlü bir account ile HTTPS arkasında tutun.

Memos'un bu baseline'da zorunlu bir bootstrap secret'ı yoktur; bunun yerine gerçek administrator account'unu veya upstream authentication'ı koruyun. Image destekliyorsa unprivileged container user kullanın ve ilgisiz hiçbir credential'ı mount etmeyin. Güvenilmeyen işlerin SQLite writes, attachment growth, API traffic ve biriken notlar üzerinde search kaynaklarını tüketebileceği ingress katmanında rate veya size limit'leri uygulayın.

TLS kolaydır; oluşturulan URL'ler değildir

Memos için geçici ve kalıcı public origin'lerden kaçının. Bunun yerine browser ve API client'ları için sabit bir HTTPS origin kullanın, seçtiğiniz DNS name'i platform route'una yönlendirin ve yalnızca 5230 portuna proxy yapın.

Bu işlemi host'un dışından test edin: private bir memo ve attachment oluşturun, bunları API üzerinden alın, düzenleyin ve container değiştirildikten sonra kaldığını doğrulayın. Ingress başarısız olursa 502 troubleshooting rehberi port ve listener hatalarını ele alır. Memos isteği alıyor ancak database dosyası container katmanında bulunuyor ve değiştirildikten sonra kayboluyorsa kanıt artık proxy'nin ötesindeki bir noktaya işaret eder.

Memos'un değişikliklerden sağ çıktığını kanıtlayın

Bir container image'ı yeniden indirilebilir; Memos database'i ve yüklenen kaynaklar yeniden indirilemez. Bootstrap işleminden önce /var/opt/memos'u mount edin, zararsız örnek veriler yazın ve bu path'in gerçekten kalıcı olduğunu kanıtlamak için container'ı değiştirin. Bir Compose filename'ına güvenmek yerine etkin mount'u inceleyin ve runtime user'ın Memos'un beklediği konuma yazabildiğini kontrol edin.

Retention politikasını ve off-host destination'ı seçin, ardından production'a dokunmadan recovery sürecini prova edin. Drill yalnızca user'lar, memo'lar, tag'ler ve kaynaklar geri geldiğinde ve API bilinen private memo'yu alabildiğinde başarılı olur. Database tabanlı state için storage snapshot'larını, point-in-time recovery ile snapshot'lar bölümünde açıklandığı gibi application-consistent export'larla birlikte kullanın.

Container health'ten daha güçlü beş kontrol

Memos için ilk user traffic'ini acceptance test olarak kullanmayın. Zararsız örnek state hazırlayın ve “private bir memo ve attachment oluştur, bunları API üzerinden al, düzenle ve container değiştirildikten sonra kaldığını doğrula” işleminin tamamını çalıştırın. Çalıştırmayla ilişkili tam public URL'yi, sonucu, image reference'ını ve log interval'ını not edin.

Container'ı değiştirin ve data'yı yeniden oluşturmadan işlemi tekrarlayın. Ardından empty bir host'a recovery yapın; recovery koşulu, user'ların, memo'ların, tag'lerin ve kaynakların geri gelmesi ve API'nin bilinen private memo'yu alabilmesidir. Her geçişte SQLite writes, attachment growth, API traffic ve biriken notlar üzerindeki search metriklerini gözlemleyin ve idle container metrikleri yerine transaction'ın bozulmasına göre bir alert tanımlayın.

Son bir kontrolü bilerek başarısız olacak şekilde tasarlayın: şu sınırla ilişkili resource veya format limitine yakın zararsız bir input gönderin: database dosyası container katmanında bulunur ve container değiştirildiğinde kaybolur. Ortaya çıkan Memos mesajının, data deletion'ı veya sonsuz bir restart'i tetiklemek yerine ilgili sınırı belirttiğini doğrulayın. Geçerli koşulu geri yükleyin ve aynı örnek transaction'ın başarılı olduğunu doğrulayın. Bu kısa drill'i release checklist'inde tutun.

Bir sonraki soruyu yanıtlayan log'lar

Her deployment sonrasında Memos smoke test'i olarak private bir memo ve attachment oluşturun, bunları API üzerinden alın, düzenleyin ve container değiştirildikten sonra kaldığını doğrulayın. Bu testi destekleyen metrikler SQLite writes, attachment growth, API traffic ve biriken notlar üzerindeki search'tür; bu kaynakların user action'ı bozacak bir noktaya yaklaştığı yerde alert oluşturun.

Başlıca change risk'i, tüm service state'i tek bir compact path'te bulunduğu için Memos database migration'larının bir kopya üzerinde prova edilmesi gerektiğidir. Güvenli bir release, geri yüklenebilir bir snapshot ile başlar ve traffic yönlendirilmeden önce tek yönlü state değişikliklerini doğrular. Database dosyası container katmanında bulunuyor ve container değiştirildiğinde kayboluyorsa configuration'ını ve ilk error'ını okuyana kadar başarısız container'ı koruyun.

Platform katmanı için Dockup kullanın

Dockup, Memos çevresindeki manuel reverse-proxy ve lifecycle işlemlerini ortadan kaldırır. Service, replacement işlemleri sırasında 5230'a sabit bir HTTPS route, injected configuration ve persistent storage alır. Bağlı bir customer server, Dockup-hosted compute ile aynı modeli izler.

Launch sonrasında application contract'ı karşılayın: browser ve API client'ları için sabit bir HTTPS origin kullanın, local gereksinimi — embedded database ve asset'ler için tek bir durable volume — koşulunu doğrulayın ve şu kanıtı çalıştırın: private bir memo ve attachment oluşturun, bunları API üzerinden alın, düzenleyin ve container değiştirildikten sonra kaldığını doğrulayın. Bu yaklaşım, Memos'u recoverable ve secure kılan ayrıntıları göz ardı etmeden one-click deneyimini kullanışlı tutar.

Sık sorulan sorular

Production deployment için Memos'un neye ihtiyacı vardır?

Memos container'ını 5230 portu üzerinden tek bir HTTPS origin'e yönlendirin. Local runtime gereksinimi, embedded database ve asset'ler için tek bir durable volume'dür. Private bir memo ve attachment oluşturabildiğiniz, bunları API üzerinden alıp düzenleyebildiğiniz ve container değiştirildikten sonra kaldığını doğrulayabildiğiniz ana kadar Memos'u hazır kabul etmeyin.

Memos verilerinin hangileri backup'a dahil edilmelidir?

/var/opt/memos'u kalıcı hâle getirin ve Memos database'ini ile yüklenen kaynakları aynı recovery manifest'ine dahil edin. Temiz bir Memos restore işlemi yalnızca user'lar, memo'lar, tag'ler ve kaynaklar geri geldiğinde ve API bilinen private memo'yu alabildiğinde başarılı sayılır.

Reverse proxy arkasında Memos için HTTPS gerekir mi?

Public Memos origin'i için HTTPS kullanın ve 5230 portunu internal route üzerinde tutun. Memos ayarını doğru uygulayın: browser ve API client'ları için sabit bir HTTPS origin kullanın. Memos için HTTPS, credentials veya user content'in transit sırasında korunmasını sağlar ve origin'e duyarlı client davranışının tutarlı kalmasına yardımcı olur.

Bir Memos upgrade'i nasıl test edilmelidir?

Güncel Memos state'ini isolated bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ını tekrarlayın. Özellikle dikkatli olun; Memos database migration'larının bir kopya üzerinde prova edilmesi gerekir, çünkü tüm service state'i tek bir compact path'te bulunur. Data migration ve rollback sınırları anlaşılana kadar önceki Memos image'ını saklayın.