API & AI ajanları

GitLiman'ın tamamı bir API token'ıyla otomatikleştirilebilir. Masaüstündeki bir AI ajanı (Cursor, Claude Code, kendi script'in) tek token'la uygulama kurar, dosya gönderir, komut çalıştırır, veritabanı oluşturur — sunucuya hiç girmeden.

Kimlik doğrulama

Konsol → Ayarlar → API Token ile bir glp_ token oluştur. Her istekte başlık olarak gönder:

Authorization: Bearer glp_...

Temel adres: https://gitliman.com/api/v1. Token-gerektirmeyen GET /api/v1 ucu, tüm uçları listeleyen bir kendini-tanımlama (self-doc) JSON'u döner — AI ajanları önce onu okuyabilir.

Uçlar

Örnek: bir Laravel projesini masaüstünden yayına al

TOKEN="glp_..."
API="https://gitliman.com/api/v1"

# 1) Uygulamayı bul (ya da POST /deploy ile oluştur)
curl -s $API/deployments -H "Authorization: Bearer $TOKEN"

# 2) Masaüstü klasörünü gönder (tar.gz olarak) → /var/www/html/uygulama
tar czf proje.tar.gz -C ./proje .
curl -s -X POST $API/deployments/12/files \
  -H "Authorization: Bearer $TOKEN" \
  -F "[email protected]" -F "path=uygulama"

# 3) Bağımlılık + göç (uzun sürer → async)
curl -s -X POST $API/deployments/12/exec \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"cmd":"cd /var/www/html/uygulama && composer install && php artisan migrate --force","async":true}'
# → {"command_id": 5, "poll": ".../commands/5"}

# 4) Durumu yokla
curl -s $API/deployments/12/commands/5 -H "Authorization: Bearer $TOKEN"

Senkron vs async komut

Kısa komutlar (ls, php -v) senkron çalışır ve çıktıyı hemen döner. Uzun komutlar (composer install, npm run build, migrate, paket kurulumu) async:true ile kuyruğa alınmalıdır — aksi halde istek ~60 sn'de zaman aşımına uğrar. Async çağrı anında command_id döner; GET /deployments/{id}/commands/{cid} ile durumu (queued/running/ completed/failed) ve çıktıyı yoklarsın.

LAMP kutusunda çoklu site yönetimi

LAMP/LEMP paketi tek kutuda birçok siteyi barındırır (cPanel'in "addon domain"i). Panelden yapılan işin tamamı API'den de yapılabilir — 20 siteyi tek tek elle eklemek yerine bir betik ya da AI ajanı kurabilir. Site açmak yalnız kutunun içindeki sanal sunucu tanımını (vhost) üretir; alan adını GitLiman konsolundan bağlamayı (CNAME) ayrıca yapman gerekir, SSL sonra otomatik gelir.

# Siteleri listele
curl -s $API/deployments/12/sites -H "Authorization: Bearer $TOKEN"
# → {"sites":[{"domain":"a.com","folder":"a","aliases":"www.a.com","exists":true,"size":93}]}

# Yeni site aç (klasör verilmezse alan adının ilk parçasından türetilir, www alias'ı varsayılan AÇIK)
curl -s -X POST $API/deployments/12/sites \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"domain":"yilmazemlak.com","folder":"yilmazemlak"}'
# → 201 {"ok":true,"site":{"folder":"yilmazemlak","docroot":"/var/www/html/sites/yilmazemlak"}}
# → 409 aynı klasörle site zaten var · 422 geçersiz alan adı / Apache ayarı reddetti

# Site dosyalarını gönder (docroot: /var/www/html/sites/<klasör>)
tar czf site.tar.gz -C ./musteri-sitesi .
curl -s -X POST $API/deployments/12/files \
  -H "Authorization: Bearer $TOKEN" -F "[email protected]" -F "path=sites/yilmazemlak"

# Sitenin PHP sürümünü değiştir (7.4 · 8.0 · 8.1 · 8.2 · 8.3 · 8.4)
curl -s -X PATCH $API/deployments/12/sites/yilmazemlak \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d '{"php":"7.4"}'

# Siteye özel veritabanı + KENDİ kullanıcısı (site kodunda root KULLANMA)
curl -s -X POST $API/deployments/12/databases \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d '{"name":"yilmazemlak_db"}'
# → 201 {"ok":true,"database":{"name":"...","user":"...","password":"...","host":"localhost"}}

# Site logları ("dün neden 500 verdi")
curl -s "$API/deployments/12/sites/yilmazemlak/logs?type=error&lines=100" -H "Authorization: Bearer $TOKEN"

# Siteyi kaldır — VARSAYILAN OLARAK DOSYALAR KALIR (yalnız tanım silinir, geri alınabilir)
curl -s -X DELETE $API/deployments/12/sites/yilmazemlak -H "Authorization: Bearer $TOKEN"

# Dosyaları da silmek GERİ ALINAMAZ, bilerek istenmeli:
curl -s -X DELETE $API/deployments/12/sites/yilmazemlak \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d '{"purge":true}'

Site tanımı bozuk bir Apache ayarı üretirse otomatik geri alınır — hatalı bir istek kutudaki diğer siteleri düşürmez. Bu uçlar yalnız LAMP/LEMP paketinde çalışır; başka bir imajda "bu uygulama site yönetimini desteklemiyor" (422) döner.

20 siteyi tek betikle taşımak

Her site için dört çağrı yeter — site, dosyalar, veritabanı, alan adı:

for s in yilmazemlak akdenizotel bircanburak; do
  # 1) site (PHP sürümünü siteye göre seçebilirsin)
  curl -s -X POST $API/deployments/12/sites -H "Authorization: Bearer $TOKEN"     -H "Content-Type: application/json" -d "{\"domain\":\"$s.com\",\"folder\":\"$s\",\"php\":\"8.1\"}"

  # 2) dosyalar (arşivi klasörün İÇİNDEN paketle; ≥95 MB ise /files-presign yolunu kullan)
  tar czf $s.tar.gz -C ./siteler/$s .
  curl -s -X POST $API/deployments/12/files -H "Authorization: Bearer $TOKEN"     -F "file=@$s.tar.gz" -F "path=sites/$s"

  # 3) veritabanı + kendi kullanıcısı, ardından dökümü aktar
  curl -s -X POST $API/deployments/12/databases -H "Authorization: Bearer $TOKEN"     -H "Content-Type: application/json" -d "{\"name\":\"${s}_db\"}"
  curl -s -X POST $API/deployments/12/databases/${s}_db/import     -H "Authorization: Bearer $TOKEN" -F "sql=@./dumps/$s.sql.gz"

  # 4) alan adı (CNAME/TXT yayılınca verify)
  curl -s -X POST $API/deployments/12/domains -H "Authorization: Bearer $TOKEN"     -H "Content-Type: application/json" -d "{\"domain\":\"$s.com\"}"
done

Veritabanı bilgisini site config'ine yazmak için GET /databases/{ad} yanıtındaki kullanıcı/parolayı kullan (root DEĞİL). WordPress'te bunu tek komutla da yaptırabilirsin:

curl -s -X POST $API/deployments/12/exec -H "Authorization: Bearer $TOKEN"   -H "Content-Type: application/json" -d '{"cmd":"cd /var/www/html/sites/yilmazemlak && wp config set DB_NAME yilmazemlak_db --allow-root"}'

Yüklenen dosyaların sahipliği siteye otomatik devredilir — WordPress eklenti/tema güncellemesi ve medya yüklemesi çalışır durumda kalır.

Not — iki farklı "veritabanı" var, karıştırma: /api/v1/databases = konsoldan açtığın yönetilen veritabanları (ayrı sunucu/cluster). /api/v1/deployments/{id}/databases = LAMP kutusunun içindeki gömülü MySQL şemaları. İkincisinde her şema kendi kullanıcısıyla doğar: bir sitenin wp-config.php'si sızsa bile diğer sitelerin verisi kapalı kalır — bu yüzden site kodunda root kullanma.

Veritabanı bilgisini AI'a verme

GET /api/v1/databases/{id} bağlantı bilgisini (host/port/kullanıcı/şifre/URL) döner. AI ajanı bunu okuyup uygulamanın config dosyasına (.env, wp-config.php) yazabilir ya da PATCH /env ile ortam değişkeni olarak enjekte edebilir.

Kalıcı yükleme klasörleri

Git dağıtımlarında yükleme klasörleri otomatik kalıcı diske (/data) bağlanır (Laravel storage/app/public, Django media, Rails storage, uploads/public/uploads) — redeploy ve hard-redeploy'da kaybolmaz. Ek klasör kalıcılaştırmak için ortam değişkeni: GL_PERSIST_PATHS=uploads,public/media (virgülle ayrılmış göreli yollar).

Yükleme klasörünü git'e commit ETMEYİN. Upload'lar zaten kalıcı + yedeklidir; git'e yalnızca kod ve sabit tasarım asset'leri (ör. public/images, public/css) girer.

İpucu: Repoya yeni dosya eklerken git add yapmayı unutmayın — git commit -am yalnızca izlenen (tracked) dosyaların değişikliğini alır, yeni dosyaları atlar. Canlıda eksik görsel/asset'in en sık nedeni budur.

Sürekli yedek (sunucu kaybına karşı) — otomatik, her pakete dahil

Sunucu değişse bile veri kaybolmaz:

• Yüklemeler artımlı olarak sürekli yedeklenir; yeni bir sunucuda boş diskle açılınca otomatik geri yüklenir.
• Yönetilen MySQL sürekli binlog + periyodik tam yedek (base) alır → sunucu kaybında point-in-time recovery ile ~saniye/dakika kayıpla geri gelir.

Yani 1× (tek instance) planda bile sunucu kaybında upload'lar ve veritabanı geri gelir. 3× (HA) planlarda ise veri zaten instance'lar arasında replike edilir — anında devir, kayıp yok. Yedekler bizim tarafımızda tutulur (uygulama container'ında depolama sırrı bulunmaz).