Akaunting kurulumu: sunucu gereksinimleri ve ilk gün kontrol listesi

Akaunting kurulumu için PHP 8.1 veya üstü, desteklenen bir veritabanı (MySQL, MariaDB, PostgreSQL ya da SQLite), URL yeniden yazmayı destekleyen bir web sunucusu ve bir grup PHP eklentisi gerekiyor. Kurulum sihirbazını bitirmek işin kolay kısmı; asıl iş, kurulumdan sonra cron'un, giden e-postanın, HTTPS'in ve yedeğin gerçekten çalıştığını kanıtlamak. Bu yazıda önce sunucu seçimini, sonra ilk gün kontrol listesini adım adım anlatıyoruz.

Akaunting 3.x sunucu gereksinimleri

Akaunting'in resmî gereksinim sayfası şu tabloyu veriyor:

Kurulum sihirbazı bu maddeleri kontrol ediyor ve eksik varsa ilerlemiyor. Ancak sihirbazın görmediği, sonradan sorun çıkaran maddeler de var:

• CLI PHP ile web PHP'si aynı mı? Sihirbaz tarayıcıdan çalışan PHP'yi kontrol ediyor. Cron ve artisan komutları ise komut satırındaki PHP'yi kullanıyor. Paylaşımlı hostinglerde komut satırındaki php çoğu zaman daha eski bir sürüm; doğru sürüm php8.2 gibi ayrı bir isimle ya da tam yolla çağrılıyor.
• proc_open ve proc_get_status açık mı? Bazı hosting firmaları güvenlik gerekçesiyle bu fonksiyonları kapatıyor ve kurulum bir noktada sebepsizce duruyor.
• Bellek ve süre sınırları: düşük memory_limit ve max_execution_time, kurulumu veritabanı tablolarını oluştururken kesebiliyor. Yarım kalan kurulum, tekrar denemede "tablo zaten var" hatası veriyor.
• Dosya yükleme sınırı: upload_max_filesize ve post_max_size, fatura eklerinin ne kadar büyük olabileceğini belirliyor.
• Dışa erişim: Akaunting sürüm kontrolü, güncelleme ve uygulama kurulumu için akaunting.com'a HTTPS ile bağlanıyor. Dışa kapalı bir sunucuda güncellemeler başarısız oluyor.

Veritabanı seçimi

Resmî liste dört veritabanı sayıyor, ama hepsi eşit derecede yaygın kullanılmıyor. Bizim varsayılan önerimiz MySQL ya da MariaDB; Akaunting ekosisteminde en sık karşılaşılan ortamlar bunlar. Özel bir gerekçeniz yoksa bunlardan birini seçmek, ileride karşılaşacağınız bir sorunun başkası tarafından daha önce yaşanmış ve çözülmüş olma ihtimalini artırır. SQLite deneme kurulumları için pratik, ama birden fazla kullanıcının aynı anda çalıştığı bir üretim ortamı için önermiyoruz.

Veritabanının karakter setinin utf8mb4 olduğundan emin olun. Türkçe karakterler (ı, ş, ğ) ve müşteri adlarındaki özel karakterler ancak böyle sorunsuz saklanır. Bir de yedekleme planını veritabanı seçerken düşünün: MySQL ya da MariaDB için mysqldump gibi araçlar her sunucuda hazır bulunur.

Akaunting'in ne olduğunu ve lisans sınırlarını henüz incelemediyseniz, önce Akaunting nedir yazımıza göz atmanızı öneririz; hangi katmanda lisansa ihtiyaç duyacağınız sunucu planını da etkiliyor.

Paylaşımlı hosting, VPS ya da Docker?

Üç seçeneğin de yeri var; doğru seçim, sunucuya kimin bakacağına bağlı.

Paylaşımlı hosting ucuz görünür, ama yukarıdaki maddelerden ikisi üçü genellikle eksik çıkar. Kullanacaksanız, hosting firmanızdan yazılı olarak CLI PHP sürümünü, kapalı fonksiyon listesini ve gerçek cron desteğini isteyin.

VPS, çoğu işletme için en öngörülebilir seçenek. PHP-FPM ile Nginx ya da Apache, bir veritabanı, otomatik yenilenen bir TLS sertifikası ve bir cron kaydı; hepsi sizin kontrolünüzde.

Docker, ekibinizde konteyner bilen biri varsa iyi bir seçim. İki noktaya dikkat edin: kullandığınız imajın Akaunting'in güncel sürümünün gerisinde kalıp kalmadığını kontrol edin ve storage klasörü ile veritabanının konteyner silindiğinde kaybolmayacak şekilde kalıcı birimlerde durduğundan emin olun. Zamanlanmış görevler için ayrı bir konteyner ya da sunucu cron'u gerekiyor; konteyner içinde kendiliğinden çalışmıyor.

Kurulumun kendisi: dikkat edilecek beş nokta

1. Kök dizini doğru ayarlayın. Mümkünse web sunucusunun kök dizinini uygulamanın public klasörüne yönlendirin. Akaunting'i mevcut bir sitenin public_html klasörünün içine açmak, hem güvenlik hem karışıklık açısından sorun çıkarır.
2. Veritabanını boş ve ayrı açın. Akaunting'e özel bir veritabanı ve yalnızca o veritabanında yetkisi olan bir kullanıcı oluşturun.
3. Süre sınırını kurulum için yükseltin. Komut satırından kurulum yapıyorsanız süre sınırı genellikle sorun olmaz; tarayıcıdan yapıyorsanız max_execution_time değerini geçici olarak yükseltin.
4. Ortam dosyasını kontrol edin. Kurulumdan sonra .env dosyasında APP_KEY değerinin üretildiğini, APP_URL değerinin gerçek adresle (https dahil) aynı olduğunu ve APP_DEBUG değerinin false olduğunu doğrulayın. Açık bırakılan hata ayıklama modu, hata sayfalarında yapılandırma bilgisi gösterebilir.
5. Dosya izinlerini daraltın. Web sunucusunun yazması gereken yerler storage ve bootstrap/cache klasörleri. "Çalışsın diye" bütün klasörlere 777 vermek, sorunu çözmez, yenisini açar.

İlk gün kontrol listesi

Kurulum ekranının "tebrikler" demesi, sistemin işe hazır olduğu anlamına gelmiyor. Aşağıdaki maddelerin her biri bir kez kanıtlanmalı, varsayılmamalı.

• Cron gerçekten çalışıyor. Sunucuda dakikada bir php artisan schedule:run çalıştıran bir kayıt var ve bu kayıttaki php, web tarafıyla aynı sürüm. Kanıt: bugün tarihli bir tekrarlayan fatura tanımlayın ve oluştuğunu görün.
• Giden e-posta ulaşıyor. SMTP ayarları girildi; alan adınız için SPF ve DKIM kayıtları tanımlı, mümkünse DMARC da. Kanıt: bir faturayı PDF ekiyle gerçek bir Gmail ya da Outlook adresine gönderin ve spam klasörüne değil gelen kutusuna düştüğünü görün.
• HTTPS zorunlu ve otomatik yenileniyor. Sertifika kuruldu, http adresi https'e yönleniyor, yenileme otomatik.
• İzinler doğru. Yazma yetkisi yalnızca gereken klasörlerde; .env dosyası tarayıcıdan erişilemiyor.
• Saat dilimi, para birimi ve biçimler ayarlı. Uygulama ayarlarında saat dilimi Europe/Istanbul, varsayılan para birimi TRY, tarih biçimi ve ondalık/binlik ayırıcılar Türkiye'ye göre. Sunucunun saat dilimini de kontrol edin; cron'un "bugün" kabul ettiği gün buna bağlı.
• Yönetici hesabı korunuyor. Güçlü ve benzersiz bir parola, kişiye özel e-posta adresi. Ayrıca kasada duran ikinci bir acil durum yönetici hesabı; kendinize yanlış rol verip kilitlenmek, sık yaşanan bir durum.
• Yedek alınıyor ve bir kez geri yüklendi. Veritabanı, storage klasörü ve .env dosyası düzenli olarak sunucu dışına kopyalanıyor. Kanıt: bu yedeği ayrı bir ortama geri yükleyip bir faturayı ekiyle birlikte açın.

Son maddenin önemini abartmak zor. .env içindeki APP_KEY kaybolursa, şifrelenmiş bazı değerler okunamaz hale gelebilir; storage yoksa bütün fatura ekleri kaybolur. Yalnızca veritabanını alan bir yedek, çoğu zaman geri yükleme gününe kadar eksik olduğu fark edilmeyen bir yedektir.

Kurulumdan sonra ilk haftalar

İlk gün kontrol listesi tamamlandıktan sonra birkaç alışkanlık edinmek, ileride yaşanacak sorunların çoğunu önlüyor:

• Hangi sürümde olduğunuzu ve hangi uygulamaları kurduğunuzu not edin. Güncelleme zamanı geldiğinde bu liste ilk ihtiyaç duyacağınız şey.
• Uygulama günlüklerine bakmayı öğrenin. Hatalar storage/logs klasöründeki dosyalara düşüyor. Bir şey ters gittiğinde ilk bakılacak yer burası.
• Güncellemeyi canlı sistemde ilk kez denemeyin. Bir kopya ortam hazırlayıp güncellemeyi önce orada yapmak, bir günlük ekstra iş gibi görünür; yarıda kalmış bir güncellemeyi kurtarmaktan çok daha ucuzdur. Bu işin nasıl planlandığını sürüm yükseltme ve kurtarma sayfamızda anlattık.
• Mali müşavirinizle hesap planını ve vergi oranlarını erkenden konuşun. Kayıtlar biriktikten sonra yapı değiştirmek, başta doğru kurmaktan zordur.

Nereden başlamalı?

Elinizde bir sunucu varsa, ilk adım ona yukarıdaki gereksinim tablosunu ve kapalı fonksiyon listesini uygulamak. Cevap "bu sunucuda olmaz" çıkarsa, bunu kurulumdan önce öğrenmek size zaman kazandırır. Teknik ekibiniz varsa bu yazıdaki kontrol listesi, işi kendiniz yapmanız için yeterli bir başlangıç noktası.

İşi devretmek isterseniz, Akaunting kurulum hizmetimizde önce sunucuyu yazılı olarak kontrol ediyor, ardından kurulumu cron'u, e-postası ve geri yüklemesi denenmiş yedeğiyle birlikte teslim ediyoruz. Sorularınız için iletişim sayfamızdan bize ulaşabilirsiniz.