Authentik Nedir ve Açık Kaynak Kimlik Sağlayıcı Kurulumu

Bir sunucuda beş on farklı uygulama çalıştırmaya başladığınızda hep aynı sorunla karşılaşırsınız: her uygulamanın kendi kullanıcı veritabanı, kendi parola politikası ve kendi giriş ekranı vardır. Bir çalışan işten ayrıldığında onu tek tek her panelden silmek, yeni birine erişim açmak için beş ayrı yerde hesap oluşturmak, üstelik hepsinde ikinci faktörü ayrı ayrı kurmaya çalışmak hem zaman kaybı hem de ciddi bir güvenlik açığıdır. İşte bu dağınıklığı toparlamak için merkezî bir kimlik katmanına, yani bir kimlik sağlayıcıya (Identity Provider) ihtiyaç duyarsınız.

Authentik, tam da bu ihtiyacı karşılayan modern ve açık kaynak bir kimlik sağlayıcıdır. Tek oturum açma (SSO), çok faktörlü kimlik doğrulama (MFA), kullanıcı ve grup yönetimi ile kendi native oturum açma özelliği olmayan uygulamaları bile koruyabilen bir proxy katmanını tek bir arayüzde birleştirir. Bu yazıda Authentik'in ne olduğuna, akış (flow) tabanlı mimarisinin neden farklı olduğuna, Docker Compose ile nasıl kurulduğuna, ilk uygulamayı ve sağlayıcıyı nasıl tanımlayacağınıza, MFA'yı ve proxy korumasını nasıl devreye alacağınıza kıdemli bir sistem yöneticisinin gözünden bakacağız.

Authentik Nedir ve Ne İşe Yarar?#

Authentik, Python/Django tabanlı bir sunucu çekirdeği ile Go dilinde yazılmış hafif bir proxy bileşeninden oluşan, kendi altyapınızda barındırabileceğiniz (self-hosted) bir kimlik ve erişim yönetimi platformudur. Temel görevi, kullanıcı kimliklerini tek bir merkezde tutmak ve bu merkezi, konuştuğu tüm uygulamalar için "güvenilir kaynak" hâline getirmektir. Bir kullanıcı Authentik'te bir kez oturum açtığında, ona bağlı diğer uygulamalara parola girmeden geçebilir; bir kullanıcıyı Authentik'ten kapattığınızda ise erişimi her yerde aynı anda kesilir.

Authentik'i benzer araçlardan ayıran en önemli nokta, konuştuğu protokol çeşitliliğidir. Aynı kurulum aynı anda birden fazla standardı sağlayabilir. Modern web uygulamaları için OAuth2/OpenID Connect (OIDC), kurumsal ve eski uygulamalar için SAML 2.0, dizin tabanlı sistemler için LDAP, kullanıcı senkronizasyonu için SCIM ve ağ ekipmanları için RADIUS aynı panelden yönetilir. Yani hem yeni bir Next.js uygulamanızı OIDC ile, hem 10 yıllık bir kurumsal yazılımı SAML ile, hem de bir Wi-Fi kontrolcüsünü RADIUS ile aynı kimlik havuzuna bağlayabilirsiniz.

Pratikte bu şu anlama gelir: Grafana, Nextcloud, Portainer, GitLab, Proxmox veya kendi yazdığınız iç panel — hepsi tek bir "Authentik ile Giriş Yap" düğmesinin arkasında birleşir. Kullanıcılarınız tek bir parola ve tek bir ikinci faktör hatırlar; siz de tek bir yerden kimin nereye erişebileceğini yönetirsiniz.

Öne Çıkan Özellikler#

Authentik, boyutuna göre kurumsal seviyede özellikler sunar. Öne çıkanlar şöyle sıralanabilir:

• Tek oturum açma (SSO): OIDC, SAML, LDAP, SCIM ve RADIUS sağlayıcılarının tamamı tek üründe. Bir uygulama hangi standardı destekliyorsa, Authentik ona uygun sağlayıcıyı sunar.
• Akış (flow) tabanlı kimlik doğrulama: Giriş, kayıt, parola sıfırlama ve MFA süreçleri, "stage" adı verilen bloklardan oluşan tamamen özelleştirilebilir akışlarla tanımlanır. Kutudan çıkan varsayılanları olduğu gibi kullanabilir ya da kendi senaryonuzu tasarlayabilirsiniz.
• Çok faktörlü doğrulama (MFA): TOTP tabanlı authenticator uygulamaları, WebAuthn/FIDO2 donanım anahtarları ve geçiş anahtarları (passkey), statik yedek kodlar, SMS ve Duo desteklenir.
• Proxy ve forward-auth koruması: Kendi giriş ekranı olmayan uygulamaların önüne bir kimlik duvarı çeker. Uygulama hiç değiştirilmeden, ters proxy üzerinden Authentik girişine zorlanır.
• Kullanıcı ve grup yönetimi: Kullanıcılar, gruplar, roller ve nitelik (attribute) tabanlı politikalarla ince ayrıntıya kadar yetkilendirme yapılır. Kimin hangi uygulamayı göreceğini politikalarla belirlersiniz.
• Kendi kendine servis (self-service): Kullanıcılar parolalarını sıfırlayabilir, MFA cihazlarını yönetebilir ve profillerini güncelleyebilir; siz her talep için müdahale etmek zorunda kalmazsınız.
• Denetim günlükleri ve dış dizin senkronizasyonu: Her oturum açma ve yönetim işlemi kaydedilir; LDAP/Active Directory gibi dış kaynaklardan kullanıcı içe aktarımı yapılabilir.

Bu özelliklerin çoğu ticari kimlik hizmetlerinde kullanıcı başına ücretlendirilirken, Authentik'in açık kaynak sürümünde ek maliyet olmadan gelir. Yalnızca gelişmiş kurumsal yönetim ve destek için ücretli bir "Enterprise" katmanı bulunur; ancak tipik bir KOBİ veya ekip için açık kaynak sürüm fazlasıyla yeterlidir.

Akış (Flow) Tabanlı Kimlik Mimarisi#

Authentik'i teknik olarak en özgün kılan kavram akışlardır (flows). Diğer birçok kimlik sağlayıcıda giriş süreci sabittir: kullanıcı adı, parola, belki bir MFA kodu ve bitti. Authentik ise bu süreci parçalara böler. Her adım bir stage'dir ve akış, bu stage'lerin sıralı bir dizisidir.

Örnek olarak tipik bir giriş akışı şu stage'lerden oluşur: kimlik belirleme (identification), parola doğrulama (password), authenticator doğrulama (MFA), oturum açma (login). Bunlara "consent" (onay), "user_write" (kullanıcı oluşturma/güncelleme) veya "email" (e-posta doğrulama) gibi stage'ler ekleyip çıkarabilirsiniz. Böylece "önce parola sor, sonra MFA iste" yerine "önce donanım anahtarı olanları parolasız geçir, olmayanlardan parola iste" gibi koşullu senaryolar kurabilirsiniz.

Bu yapının üzerine iki temel nesne oturur:

Bu ayrım başta biraz kavramsal görünse de büyük esneklik sağlar: bir uygulamayı bir protokolden diğerine taşımak, arkasındaki sağlayıcıyı değiştirmek kadar basittir; giriş deneyimini değiştirmek ise akışı düzenlemekten ibarettir. Uygulama kodu hiç dokunulmadan kalır.

Docker Compose ile Kurulum#

Authentik'in en yaygın kurulum yöntemi Docker Compose'dur. Kurulum dört konteynerden oluşur: PostgreSQL veritabanı, Redis önbelleği, server (web arayüzü ve API) ve worker (arka plan görevleri). Başlamadan önce sunucunuzda Docker ve Docker Compose kurulu olmalıdır.

Önce güçlü rastgele gizli anahtarlar üretip bir .env dosyasına yazın. Bu anahtarlar üretimde asla tahmin edilebilir olmamalıdır:

# PostgreSQL parolası ve Authentik gizli anahtarı üret
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
echo "AUTHENTIK_ERROR_REPORTING__ENABLED=false" >> .env

Ardından bir docker-compose.yml dosyası oluşturun. Aşağıdaki yapılandırma tipik bir üretim kurulumunu temsil eder:

services:
  postgresql:
    image: docker.io/library/postgres:16-alpine
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -d authentik -U authentik"]
      interval: 30s
      timeout: 5s
      retries: 5
    volumes:
      - database:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: ${PG_PASS}
      POSTGRES_USER: authentik
      POSTGRES_DB: authentik

  redis:
    image: docker.io/library/redis:alpine
    restart: unless-stopped
    command: --save 60 1 --loglevel warning
    volumes:
      - redis:/data

  server:
    image: ghcr.io/goauthentik/server:2025.6
    restart: unless-stopped
    command: server
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__NAME: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
    volumes:
      - ./media:/media
      - ./custom-templates:/templates
    ports:
      - "9000:9000"
      - "9443:9443"
    depends_on:
      - postgresql
      - redis

  worker:
    image: ghcr.io/goauthentik/server:2025.6
    restart: unless-stopped
    command: worker
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__NAME: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
    user: root
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./media:/media
    depends_on:
      - postgresql
      - redis

volumes:
  database:
  redis:

Ardından servisleri başlatın:

docker compose pull
docker compose up -d
docker compose ps   # dört konteynerin de "running" olduğunu doğrulayın

Konteynerler ayağa kalktıktan sonra ilk yönetici hesabını oluşturmak için tarayıcınızdan kurulum sihirbazına gidin. İlk kurulum adresi şudur:

https://sunucu-adresiniz:9443/if/flow/initial-setup/

Bu ekranda akadmin adlı yönetici hesabının e-postasını ve parolasını belirlersiniz. Bu andan sonra tüm yönetim işlemleri web arayüzünden yapılır. Kurulumun sağlığını komut satırından da izleyebilirsiniz:

docker compose logs -f server worker

İlk Uygulama ve Sağlayıcı Tanımlama#

Authentik ayağa kalktığında henüz hiçbir uygulamaya bağlı değildir. Bir servisi (örneğin Grafana'yı) SSO ile korumak için önce bir sağlayıcı, ardından o sağlayıcıyı kullanan bir uygulama oluşturursunuz. OIDC destekleyen modern uygulamalar için akış tipik olarak şöyle işler.

Yönetim panelinde Applications → Providers → Create yolunu izleyip "OAuth2/OpenID Provider" seçersiniz. Burada dönen anahtar alanlar şunlardır: Client ID ve Client Secret (Authentik bunları üretir), yetkilendirme akışı (authorization flow) ve en kritik alan olan Redirect URI. Redirect URI, uygulamanın giriş sonrası geri döneceği adrestir ve birebir eşleşmelidir. Grafana örneğinde bu şöyle görünür:

# Grafana tarafındaki OIDC yapılandırması (grafana.ini)
[auth.generic_oauth]
enabled = true
name = Authentik
client_id = <Authentik'in verdiği Client ID>
client_secret = <Authentik'in verdiği Client Secret>
scopes = openid email profile
auth_url = https://kimlik.siteniz.com/application/o/authorize/
token_url = https://kimlik.siteniz.com/application/o/token/
api_url = https://kimlik.siteniz.com/application/o/userinfo/

Sağlayıcıyı kaydettikten sonra Applications → Create ile bir uygulama oluşturur, az önceki sağlayıcıyı ona bağlar ve bir "slug" (URL kısaltması) verirsiniz. İsterseniz uygulamaya bir ikon ve açıklama ekleyerek kullanıcı gösterge panelinde düzgün görünmesini sağlarsınız.

Son adım yetkilendirmedir. Varsayılan olarak bir uygulamaya herkes erişemez; hangi grubun ya da kullanıcının erişebileceğini bir politika bağı (policy binding) ile belirlersiniz. Örneğin yalnızca grafana-adminleri grubuna izin verip diğer herkesi kapatabilirsiniz. Bu sayede tek bir kimlik havuzundan farklı uygulamalara farklı yetki setleri dağıtabilirsiniz. Aynı mantık SAML gerektiren eski uygulamalar için de geçerlidir; tek fark, sağlayıcı tipi olarak "SAML Provider" seçmeniz ve uygulamaya ACS URL'i ile issuer bilgisini vermenizdir.

Çok Faktörlü Kimlik Doğrulama (MFA) Yapılandırma#

Merkezî kimliğin en büyük getirilerinden biri, MFA'yı tek yerde zorunlu kılabilmenizdir. Kullanıcılarınız artık her uygulamada ayrı ayrı ikinci faktör kurmak zorunda kalmaz; Authentik'te bir kez kaydettikleri authenticator, bağlı tüm uygulamaları korur.

Authentik'te MFA, giriş akışına eklenen bir authenticator validation stage ile devreye girer. Kullanıcıların cihaz kaydetmesi için ise ilgili "authenticator setup" stage'lerini kullanırsınız. Desteklenen yöntemler ve tipik kullanım alanları şöyledir:

Pratik bir yaklaşım, giriş akışına bir politika ekleyip "MFA'sı olmayan kullanıcıları kayıt akışına yönlendirmek" ve belirli hassas gruplar için MFA'yı zorunlu kılmaktır. Böylece bir yandan kullanıcıları ikinci faktör kurmaya teşvik eder, bir yandan da yönetici gibi kritik hesaplarda MFA'yı isteğe bağlı olmaktan çıkarırsınız. Çok faktörlü doğrulamanın neden vazgeçilmez olduğunu ve yöntemler arasındaki farkları iki faktörlü doğrulama rehberimizde ayrıntılı bulabilirsiniz. Aynı disiplini parolalarınıza da uygulamak isterseniz Vaultwarden ile self-hosted parola yönetimi yazımız iyi bir tamamlayıcıdır.

Proxy Sağlayıcı ile Uygulama Koruması#

Authentik'in en pratik özelliklerinden biri, kendi giriş ekranı hiç olmayan uygulamaları bile koruyabilmesidir. Kütüphane arayüzü, bir izleme paneli veya statik bir yönetim aracı gibi kimlik doğrulama desteği olmayan bir servisiniz varsa, önüne bir "Proxy Provider" koyarak onu Authentik girişine zorlayabilirsiniz. Bu iş, outpost adı verilen ayrı bir bileşen ile yürütülür.

Yöntem, ters proxy'nizin (Nginx, Traefik veya Caddy) forward-auth yeteneğine dayanır: gelen her istek önce Authentik'e sorulur, kullanıcı oturum açmamışsa giriş ekranına yönlendirilir, açmışsa istek arka uçtaki uygulamaya iletilir. Nginx için tipik forward-auth yapılandırması şöyle görünür:

location / {
    auth_request /outpost.goauthentik.io/auth/nginx;
    error_page 401 = @goauthentik_proxy_signin;

    proxy_pass http://korunan-uygulama:8080;
    proxy_set_header X-Forwarded-Host $host;
    # Authentik'in döndürdüğü kullanıcı başlıklarını arka uca aktar
    auth_request_set $authentik_username $upstream_http_x_authentik_username;
    proxy_set_header X-authentik-username $authentik_username;
}

location @goauthentik_proxy_signin {
    internal;
    return 302 /outpost.goauthentik.io/start?rd=$request_uri;
}

Bu yaklaşımın güzelliği, korunan uygulamanın hiçbir şekilde değiştirilmemesidir. Uygulama, önüne yerleştirilen kimlik duvarından habersiz çalışmaya devam eder; kullanıcı ise ancak Authentik'te oturum açtıktan sonra ona ulaşabilir. Üstelik Authentik, doğrulanmış kullanıcının bilgilerini (X-authentik-username, e-posta, gruplar) HTTP başlıkları olarak arka uca iletebildiği için, bazı uygulamalar bu başlıkları okuyarak otomatik oturum bile açabilir.

Proxy sağlayıcı senaryosunu çalıştırmak için tüm trafiğin geçtiği ters proxy'nin doğru yapılandırılması ve geçerli bir TLS sertifikasının bulunması şarttır. Ters proxy mantığına daha derin girmek isterseniz genel sunucu yönetimi hizmetimiz ve SSL sertifikası çözümlerimiz işinizi kolaylaştırır.

Üretim İçin Güvenlik ve İşletim Notları#

Authentik güçlü bir temel sunar ancak gerçek güvenlik, doğru işletime bağlıdır. Bir kimlik sağlayıcı, tüm uygulamalarınızın anahtarını elinde tuttuğu için ele geçirilmesi hâlinde zincirin en zayıf halkası da en değerli hedefi de o olur. Bu yüzden şu noktalara özellikle dikkat edin:

• Her zaman HTTPS kullanın. Authentik'i asla şifresiz HTTP üzerinden yayınlamayın; girişler ve token'lar mutlaka TLS ile korunmalıdır. Ters proxy üzerinde geçerli bir sertifika şarttır.
• AUTHENTIK_SECRET_KEY ve veritabanı parolasını koruyun. Bu değerler .env dosyasında düz metin durur; dosya izinlerini sıkılaştırın ve sürüm kontrolüne (git) asla eklemeyin.
• Yönetici hesabında MFA zorunlu olsun. akadmin hesabı ele geçerse tüm sistem düşer; bu hesapta donanım anahtarı veya en azından TOTP kullanın.
• Düzenli yedek alın. PostgreSQL veritabanı, kullanıcılar, uygulama tanımları ve akışlar dâhil her şeyi içerir. Düzenli yedekleme olmadan bir kimlik sağlayıcı çalıştırmak büyük risktir.
• Yeni sürümleri takip edin. Authentik sık güncellenir; güvenlik yamalarını geciktirmeyin. Docker imaj etiketini sabit bir sürüme (2025.6 gibi) sabitleyip planlı olarak yükseltin.
• Erişim yüzeyini daraltın. Yönetim arayüzünü mümkünse yalnızca güvenilir ağlardan erişilebilir kılın; halka açık uygulamaları bir WAF arkasına almayı düşünün.

İşletim tarafında Authentik'in kaynak ihtiyacı da hafif değildir: dört konteyner ve bir veritabanı çalıştırdığı için makul bir RAM ister. Küçük kurulumlar 2 GB RAM ile başlayabilse de, birden çok uygulama ve aktif kullanıcı için 4 GB RAM'li bir VDS ya da sanal sunucu daha rahat çalışır. Komut satırı ve konteyner yönetimiyle uğraşmadan hazır kurulumla başlamak isterseniz benzer açık kaynak uygulamaları App Center kataloğumuzdan inceleyebilirsiniz.

Benzer Araçlarla Karşılaştırma#

Kimlik sağlayıcı pazarında Authentik yalnız değil. Öne çıkan açık kaynak alternatiflerle kısa bir karşılaştırma, doğru seçimi yapmanıza yardımcı olur:

Authentik'i ayrıştıran temel nokta, kurumsal düzeyde protokol desteğini modern ve anlaşılır bir arayüzle birleştirmesidir. Keycloak daha köklü ve özellik açısından çok geniştir ama yapılandırması ilk bakışta gözünüzü korkutabilir; Authelia son derece hafiftir fakat esas gücü forward-auth tarafındadır ve tam bir OIDC sağlayıcısı beklentisini her senaryoda karşılamayabilir. Hem tam bir SSO sağlayıcısı hem de kendi giriş ekranı olmayan uygulamalar için bir proxy koruması aynı üründe arıyorsanız, Authentik oldukça dengeli bir tercihtir. Yine de her ihtiyaç için "en iyisi" tek bir araç yoktur; ekibinizin aşinalığı ve uygulama envanteriniz seçimi belirlemelidir.

Sıkça Sorulan Sorular#

Authentik ile Keycloak arasındaki fark nedir?#

Her ikisi de açık kaynak kimlik sağlayıcılardır ve OIDC ile SAML gibi standartları destekler. Keycloak daha köklü, kurumsal dünyada yaygın ve son derece kapsamlı bir üründür; buna karşılık yapılandırması daha karmaşıktır ve öğrenme eğrisi diktir. Authentik ise daha modern bir arayüz, akış tabanlı esnek bir mimari ve kendi giriş ekranı olmayan uygulamaları koruyan yerleşik bir proxy özelliği sunar. Kendi giriş ekranı olmayan uygulamaları da korumak istiyorsanız Authentik pratik bir avantaj sağlar.

Authentik ücretsiz mi?#

Authentik'in açık kaynak sürümü tamamen ücretsizdir ve tipik bir ekip veya KOBİ için gereken tüm temel özellikleri içerir. Yalnızca gelişmiş kurumsal yönetim ve resmî destek isteyenler için ücretli bir Enterprise katmanı bulunur. Çoğu self-hosted kurulumda açık kaynak sürüm fazlasıyla yeterlidir; siz yalnızca çalıştıracağınız sunucunun maliyetini üstlenirsiniz.

Authentik'i çalıştırmak için ne kadar donanım gerekir?#

Authentik dört bileşenden oluştuğu için hafif bir uygulama sayılmaz. Deneme veya küçük ölçekli kurulumlar 2 GB RAM ile başlayabilir; ancak birden çok uygulama ve aktif kullanıcı yükü altında 4 GB RAM ve 2 vCPU çok daha rahat bir deneyim sunar. Disk tarafında birkaç GB genellikle yeterlidir; asıl belirleyici olan RAM ve veritabanı performansıdır.

Kendi giriş ekranı olmayan bir uygulamayı Authentik ile koruyabilir miyim?#

Evet, bu Authentik'in en güçlü yönlerinden biridir. Bir "Proxy Provider" ve bir outpost tanımlayıp ters proxy'nizin forward-auth özelliğini kullanarak, kimlik doğrulama desteği hiç olmayan bir uygulamanın önüne Authentik girişini yerleştirirsiniz. Uygulama hiç değiştirilmeden, yalnızca oturum açmış kullanıcılar erişebilir hâle gelir.

Authentik hangi kimlik doğrulama protokollerini destekler?#

Authentik aynı anda OAuth2/OpenID Connect (OIDC), SAML 2.0, LDAP, SCIM ve RADIUS sağlayıcıları sunabilir. Bu sayede modern web uygulamalarını OIDC ile, eski kurumsal yazılımları SAML ile, dizin tabanlı sistemleri LDAP ile ve ağ ekipmanlarını RADIUS ile tek bir kimlik havuzuna bağlayabilirsiniz. Uygulama hangi standardı destekliyorsa, o uygulama için uygun sağlayıcı tipini seçmeniz yeterlidir.

Authentik kurulumunda MFA zorunlu tutulabilir mi?#

Evet. MFA, giriş akışına eklenen bir authenticator doğrulama aşamasıyla devreye girer ve politikalar sayesinde belirli kullanıcı ya da grupları kapsayacak biçimde zorunlu kılınabilir. Örneğin yönetici grubunda MFA'yı zorunlu tutup diğer kullanıcılar için isteğe bağlı bırakabilir veya MFA'sı olmayanları kurulum akışına yönlendirebilirsiniz. TOTP, WebAuthn/FIDO2 donanım anahtarları ve statik yedek kodlar desteklenen başlıca yöntemlerdir.

Kapanış#

Authentik, dağınık kullanıcı hesaplarını ve tekrar tekrar kurulan giriş ekranlarını tek bir merkezî kimlik katmanında toplayan, açık kaynak ve modern bir çözümdür. OIDC ile SAML'i, MFA'yı ve kendi giriş ekranı olmayan uygulamaları koruyan proxy özelliğini aynı arayüzde birleştirerek hem güvenliğinizi artırır hem de yönetim yükünüzü azaltır. Akış tabanlı mimarisi başta biraz kavramsal görünse de, bir kez oturttuğunuzda giriş deneyiminizi tam olarak istediğiniz gibi şekillendirmenize olanak tanır.

Kendi kimlik sağlayıcınızı kurmak için önce sağlam bir zemine ihtiyacınız var. Authentik'in dört bileşenini rahatça çalıştıracak bir sanal sunucu veya daha fazla kaynak isteyen kurulumlar için bir VDS ile başlayabilir, kurulum ve bakım tarafında sunucu yönetimi hizmetimizden destek alabilirsiniz. Girişlerinizi güvenceye almak için SSL sertifikası ve gerekiyorsa WAF koruması ekleyerek üretime hazır, güvenli bir kimlik altyapısını Clou.TR altyapısı üzerinde kısa sürede ayağa kaldırabilirsiniz.