# WordPress, Docker Compose ve HTTPS ile nasıl kurulur

> WordPress'i resmi wordpress ve mariadb Docker imajlarıyla çalıştırın, gizli değerleri .env'de tutun, Caddy ile HTTPS üzerinden yayınlayın ve yedekleyin.

Zorluk: Başlangıç\
Denendiği sistemler: Ubuntu 24.04 LTS, Ubuntu 26.04 LTS, Debian 12, Debian 13

WordPress; bloglar, kurumsal siteler ve mağazalar için açık kaynaklı bir içerik yönetim sistemidir. WordPress'i Docker'da çalıştırmak PHP'yi, Apache'yi ve veritabanını sürümlenmiş imajlarda tutar, kurulumu başka bir sunucuda tekrarlanabilir kılar ve birbirinden yalıtılmış birkaç siteyi yan yana çalıştırmanıza izin verir.

Bu rehber Docker Hub'daki **resmi `wordpress` ve `mariadb` imajlarını** Docker Compose ile kullanır. Gizli değerler bir `.env` dosyasında, veriler adlandırılmış volume'larda durur ve WordPress yalnızca `127.0.0.1` üzerinde, HTTPS sağlayan **Caddy**'nin arkasında yayınlanır. Ayrıca PHP yükleme sınırlarını artırır, **WP-CLI**'ı resmi `cli` imajından çalıştırır, yedekleme, geri yükleme ve güncellemeyi ayarlarsınız. Konteyner olmadan klasik bir kurulumu tercih ederseniz [Nginx, PHP-FPM ve MariaDB üzerinde WordPress](/guides/install-wordpress-lemp) rehberine bakın.

## Ön koşullar

- Docker Engine ve Compose eklentisi kurulu, **Ubuntu 24.04 LTS**, **Ubuntu 26.04 LTS**, **Debian 12** veya **Debian 13** çalıştıran bir sunucu: [Ubuntu'ya Docker kurulumu](/guides/install-docker-ubuntu) veya [Debian'a Docker kurulumu](/guides/install-docker-debian) rehberine bakın.
- [Yeni bir Linux sunucusunu güvenli hale getirin](/guides/secure-a-new-linux-server) ve [SSH anahtarlarını ayarlayın](/guides/ssh-keys) rehberlerindeki gibi hazırlanmış, `sudo` yetkili ve SSH anahtarıyla giriş yapan root olmayan bir kullanıcı.
- `example.com` ve `www.example.com` için sunucuyu gösteren A (ve AAAA) kayıtlarına sahip `example.com` gibi bir alan adı.
- [Caddy reverse proxy](/guides/caddy-reverse-proxy) rehberiyle sunucuya kurulmuş Caddy.

WordPress PHP 8.3 veya daha yenisini ve MariaDB 10.11 veya daha yenisini önerir; bu rehberdeki imajlar ikisini de sağlar. WordPress CPU veya bellek için en düşük değer yayınlamaz; bu yüzden aşağıdaki değerleri tek bir site için temkinli bir başlangıç noktası olarak görün:

| Kaynak | En düşük (resmi) | Önerilen başlangıç |
|---|---|---|
| CPU | Yayınlanmamış | 1 vCPU |
| RAM | Yayınlanmamış | 2 GB |
| Disk | Yayınlanmamış | 20 GB SSD ve medya kütüphaneniz |

## Adım 1 — Proje klasörünü ve gizli değerleri oluşturun

Siteyi yönetici kullanıcınıza ait `/opt/wordpress` klasöründe tutun:

```bash
sudo mkdir -p /opt/wordpress
sudo chown $USER:$USER /opt/wordpress
cd /opt/wordpress
```

Veritabanı ayarlarını ve iki rastgele parolayı `.env` dosyasına yazın. Docker Compose bu dosyayı kendiliğinden okur:

```bash
cat > .env <<EOF
WORDPRESS_DB_NAME=wordpress
WORDPRESS_DB_USER=wordpress
WORDPRESS_DB_PASSWORD=$(openssl rand -hex 24)
MARIADB_ROOT_PASSWORD=$(openssl rand -hex 24)
EOF
chmod 600 .env
```

WordPress anahtarlarını ve salt değerlerini üretmeniz gerekmez: imaj `wp-config.php` dosyasını `WORDPRESS_*` değişkenlerinden oluştururken bunları benzersiz rastgele değerlerle doldurur.

PHP'nin yükleme ve bellek sınırlarını küçük bir `ini` dosyasıyla artırın. Resmi imaj belgeleri, PHP'nin `conf.d` klasöründeki dosyaların kendiliğinden yüklendiğini açıklar; Adım 2 bu dosyayı oraya bağlar:

```bash
mkdir -p /opt/wordpress/php
cat > /opt/wordpress/php/uploads.ini <<'EOF'
upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M
max_execution_time = 120
EOF
```

## Adım 2 — Compose dosyasını yazın

`/opt/wordpress/compose.yaml` dosyasını oluşturun. Dosya, imaj belgelerindeki örneği bir MariaDB sağlık kontrolü, yalnızca loopback adresinde yayınlanan bir port, PHP ayar dosyası ve isteğe bağlı bir WP-CLI servisiyle genişletir:

```yaml
services:
  wordpress:
    image: wordpress:php8.3-apache
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    ports:
      - "127.0.0.1:8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: ${WORDPRESS_DB_NAME}
      WORDPRESS_DB_USER: ${WORDPRESS_DB_USER}
      WORDPRESS_DB_PASSWORD: ${WORDPRESS_DB_PASSWORD}
      WORDPRESS_CONFIG_EXTRA: |
        define( 'DISALLOW_FILE_EDIT', true );
    volumes:
      - wordpress:/var/www/html
      - ./php/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini:ro

  db:
    image: mariadb:lts
    restart: unless-stopped
    environment:
      MARIADB_DATABASE: ${WORDPRESS_DB_NAME}
      MARIADB_USER: ${WORDPRESS_DB_USER}
      MARIADB_PASSWORD: ${WORDPRESS_DB_PASSWORD}
      MARIADB_ROOT_PASSWORD: ${MARIADB_ROOT_PASSWORD}
      MARIADB_AUTO_UPGRADE: "1"
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 10s
      timeout: 5s
      retries: 5
    volumes:
      - db:/var/lib/mysql

  wpcli:
    image: wordpress:cli-php8.3
    profiles: ["cli"]
    user: "33:33"
    environment:
      HOME: /tmp
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: ${WORDPRESS_DB_NAME}
      WORDPRESS_DB_USER: ${WORDPRESS_DB_USER}
      WORDPRESS_DB_PASSWORD: ${WORDPRESS_DB_PASSWORD}
    volumes:
      - wordpress:/var/www/html
    depends_on:
      - db

volumes:
  wordpress:
  db:
```

Seçimlerin anlamı:

- `wordpress:php8.3-apache`, PHP 8.3 üzerindeki Apache varyantıdır ve bugün `latest` etiketinin gösterdiği imaj da budur. PHP serisini adıyla belirtmek, PHP yükseltmesini bilinçli bir değişiklik haline getirir; imajın `php8.4` ve `php8.5` varyantları ile ayrı bir web sunucusu kullanan kurulumlar için PHP-FPM imajı da vardır.
- `WORDPRESS_CONFIG_EXTRA`, `wp-config.php` içinde değerlendirilir. Burada WordPress'in önerdiği bir sağlamlaştırma adımı olarak yerleşik tema ve eklenti dosya düzenleyicisini kapatır.
- `mariadb:lts`, MariaDB'nin güncel uzun süreli destek serisini izler. `MARIADB_AUTO_UPGRADE`, mevcut veriler üzerinde daha yeni bir sunucu sürümü başladığında `mariadb-upgrade` komutunu çalıştırır ve önce sistem tablolarının bir yedeğini alır.
- MariaDB konteyneri veritabanını ve kullanıcıyı `MARIADB_*` değişkenlerinden yalnızca ilk açılışta oluşturur. Bu değişkenlerde sonradan yapılan değişikliklerin mevcut veriler üzerinde etkisi olmaz.
- `wpcli` servisi `cli` profiline aittir; bu yüzden `docker compose up` onu başlatmaz, ihtiyaç duyduğunuzda `docker compose run` ile çağırırsınız.

## Adım 3 — WordPress'i başlatın

Yapıyı başlatın, veritabanının sağlıklı olduğunu bildirmesini bekleyin ve WordPress'in loopback portunda yanıt verdiğini kontrol edin:

```bash
cd /opt/wordpress
docker compose up -d
docker compose ps
curl -I http://127.0.0.1:8080
```

`db` servisi `healthy` göstermeli, `curl` ise `/wp-admin/install.php` adresine bir `302` yönlendirmesi döndürmelidir. PHP ayarlarının yüklendiğini doğrulayın:

```bash
docker compose exec wordpress php -i | grep -E 'upload_max_filesize|post_max_size'
```

İki değer de `64M` olmalıdır. Kurulum sihirbazını `127.0.0.1:8080` üzerinden açmayın: WordPress kurulumu yaptığınız adresi site adresi olarak kaydeder.

## Adım 4 — WordPress'i Caddy ile HTTPS üzerinden yayınlayın

Siteyi `/etc/caddy/Caddyfile` dosyasına ekleyin. İkinci blok `www` adresini çıplak alan adına yönlendirir; ana adres olarak `www.example.com` tercih ediyorsanız iki adı yer değiştirin:

```caddyfile
example.com {
    reverse_proxy 127.0.0.1:8080
}

www.example.com {
    redir https://example.com{uri} permanent
}
```

Caddy'yi yeniden yükleyin, yalnızca SSH ve web trafiğine izin verin ve test edin:

```bash
sudo systemctl reload caddy
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
curl -I https://example.com
```

Yanıt yine kurulum sihirbazına bir yönlendirmedir; bu kez geçerli bir sertifikayla HTTPS üzerinden gelir. HTTPS algılaması ek iş gerektirmez: Caddy `X-Forwarded-Proto: https` başlığını gönderir ve konteyneri `WORDPRESS_*` değişkenleriyle yapılandırdığınız için imaj, eşleşen `HTTP_X_FORWARDED_PROTO` kontrolünü `wp-config.php` dosyasına ekler. İmaj ayrıca özel ve loopback adreslerden gelen `X-Forwarded-For` başlığına güvenir; böylece WordPress gerçek ziyaretçi IP adreslerini görür. Caddy yerine Nginx kullanıyorsanız `proxy_set_header X-Forwarded-Proto $scheme;` satırını kendiniz ekleyin; [Nginx ve Certbot](/guides/nginx-reverse-proxy-certbot) rehberine bakın.

## Adım 5 — WordPress kurulum sihirbazını çalıştırın

`https://example.com` adresini açın, dili seçin ve site başlığını, bir yönetici kullanıcı adını, güçlü bir parolayı ve e-posta adresinizi girin. `admin` ve tahmin edilmesi kolay diğer kullanıcı adlarından kaçının; "Discourage search engines" seçeneğini yalnızca bir test sitesinde işaretleyin. Giriş yaptıktan sonra **Settings → Permalinks** (Ayarlar → Kalıcı bağlantılar) ekranını açın, **Post name** (Yazı adı) seçeneğini seçip kaydedin; Apache imajı rewrite modülünü içerdiği için okunaklı adresler hemen çalışır.

## Adım 6 — Resmi cli imajından WP-CLI kullanın

WP-CLI, WordPress volume'unu ve veritabanı ayarlarını paylaşan kısa ömürlü bir konteynerde çalışır. `cli` imajları Alpine tabanlıdır ve orada `www-data` kullanıcısının UID'si 82'dir; Debian tabanlı Apache imajı ise UID 33 kullanır. Bu nedenle imaj belgeleri WP-CLI'ı `HOME=/tmp` ile `33:33` olarak çalıştırmayı önerir; Compose dosyası bunu zaten yapar:

```bash
cd /opt/wordpress
docker compose run --rm wpcli wp core version
docker compose run --rm wpcli wp plugin list
docker compose run --rm wpcli wp option get siteurl
```

Son komut `https://example.com` yazdırmalıdır. Örneğin `wp user list` veya `wp search-replace` gibi her WP-CLI komutu için aynı kalıbı kullanın.

## Yedekleme ve geri yükleme

Site iki adlandırılmış volume'da, `wordpress` (çekirdek, temalar, eklentiler, yüklemeler, `wp-config.php`) ve `db` (MariaDB verileri), ayrıca `/opt/wordpress` içindeki dosyalarda yaşar. Compose volume adlarının başına proje klasörünün adını ekler; bu yüzden diskte adları `wordpress_wordpress` ve `wordpress_db` olur, bunu `docker volume ls` ile kontrol edin. Veritabanının dökümünü MariaDB'nin kendi aracıyla `docker compose exec` üzerinden alın, dosya volume'unu da geçici bir konteynerle arşivleyin:

```bash
sudo mkdir -p /opt/backups
sudo chown $USER:$USER /opt/backups
cd /opt/wordpress
docker compose exec -T db sh -c 'exec mariadb-dump --single-transaction -uroot -p"$MARIADB_ROOT_PASSWORD" "$MARIADB_DATABASE"' | gzip > /opt/backups/wordpress-db-$(date +%F).sql.gz
docker run --rm -v wordpress_wordpress:/data:ro -v /opt/backups:/backup alpine tar czf /backup/wordpress-files-$(date +%F).tar.gz -C /data .
tar czf /opt/backups/wordpress-config-$(date +%F).tar.gz -C /opt/wordpress .env compose.yaml php
chmod 600 /opt/backups/wordpress-*
```

Çekirdek dosyalar olmadan yalnızca içeriği istiyorsanız `.` yerine volume'un yalnızca `wp-content` alt klasörünü arşivleyin. `/opt/backups` klasörünü düzenli olarak sunucu dışına kopyalayın; aynı makinedeki bir yedek makineyle birlikte kaybolur.

Yeni bir sunucuya geri yüklemek için Docker'ı kurun, yapılandırma arşivini `/opt/wordpress` içine açın ve şunları çalıştırın:

```bash
cd /opt/wordpress
docker compose up -d --wait db
gunzip -c /opt/backups/wordpress-db-2026-10-09.sql.gz | docker compose exec -T db sh -c 'exec mariadb -uroot -p"$MARIADB_ROOT_PASSWORD" "$MARIADB_DATABASE"'
docker compose create wordpress
docker run --rm -v wordpress_wordpress:/data -v /opt/backups:/backup alpine tar xzf /backup/wordpress-files-2026-10-09.tar.gz -C /data
docker compose up -d
```

`--wait`, MariaDB sağlıklı hale geldiğinde geri döner; `docker compose create` ise dosya volume'unu WordPress'i başlatmadan oluşturur, böylece imaj önce volume'a yeni bir çekirdek kopyalamaz. Tarihleri kendi dosya adlarınızdakilerle değiştirin, ardından yeni sunucuya Adım 4'teki Caddy site bloğunu ekleyin.

## WordPress güncelleme

Güncel tutulması gereken iki katman vardır. **WordPress çekirdeği, eklentiler ve temalar** volume içinde yaşar ve her WordPress sitesindeki gibi güncellenir: küçük sürümler ve güvenlik sürümleri kendiliğinden kurulur, gerisini **Dashboard → Updates** (Başlangıç → Güncellemeler) ekranı halleder. Kabuktan da güncelleyebilirsiniz:

```bash
cd /opt/wordpress
docker compose run --rm wpcli wp core update
docker compose run --rm wpcli wp core update-db
docker compose run --rm wpcli wp plugin update --all
```

**İmajlar** PHP'yi, Apache'yi, sistem kütüphanelerini ve MariaDB'yi getirir. Önce yedek alın, ardından imajları çekip konteynerleri yeniden oluşturun:

```bash
cd /opt/wordpress
docker compose pull
docker compose up -d
docker compose ps
```

Yeni bir `wordpress` imajı çekmek volume'daki WordPress sürümünü değiştirmez. Daha yeni bir PHP serisine geçmek için eklentilerinizin bunu desteklediğini kontrol ettikten sonra `compose.yaml` içindeki iki `php8.3` etiketini de değiştirin. Büyük WordPress güncellemelerinden önce sürüm notlarını okuyun ve büyük değişiklikleri önce sitenin bir kopyasında test edin.

## Sorun giderme

### ERR_TOO_MANY_REDIRECTS

WordPress isteğin HTTP üzerinden geldiğini düşünüyor ve sürekli HTTPS'e yönlendiriyor. Proxy'nizin `X-Forwarded-Proto` gönderdiğinden (Caddy varsayılan olarak gönderir; Nginx'te `proxy_set_header X-Forwarded-Proto $scheme;` gerekir) ve sunucunun önündeki bir CDN'in sunucuya düz HTTP ile bağlanmadığından emin olun. Site adresi yanlış kaydedildiyse `docker compose run --rm wpcli wp option update home 'https://example.com'` ve `siteurl` için aynı komutla düzeltin.

### Error establishing a database connection

`docker compose ps` çıktısını kontrol edin: `db` servisi `healthy` olmalıdır. İlk açılıştan sonra `.env` içindeki parolaları değiştirdiyseniz MariaDB hâlâ eskilerini kullanır, çünkü `MARIADB_*` değişkenlerini yalnızca veri klasörü boşken okur. Orijinal değerleri geri koyun ya da kullanıcının parolasını MariaDB içinde `ALTER USER` ile değiştirin.

### The uploaded file exceeds the upload_max_filesize directive in php.ini.

PHP ayar dosyası bağlanmamış veya yolu yanlış. `/opt/wordpress/php/uploads.ini` dosyasının var olduğunu ve `compose.yaml` içindeki volume satırının `/usr/local/etc/php/conf.d/uploads.ini` hedefini gösterdiğini kontrol edin, ardından konteyneri yeniden oluşturmak için `docker compose up -d` çalıştırın. Caddy'nin önündeki bir proxy kendi gövde boyutu sınırını uygulayabilir.

### Installation failed: Could not create directory

Volume'daki dosyaların sahibi `www-data` değil; bu genellikle bir geri yüklemeden veya WP-CLI'ı root olarak çalıştırdıktan sonra olur. Sahipliği `docker compose exec wordpress chown -R www-data:www-data /var/www/html` ile düzeltin ve WP-CLI'ı her zaman `wpcli` servisi üzerinden çalıştırın.

### WordPress e-posta göndermiyor

Resmi imaj bir posta sunucusu içermez; bu yüzden PHP'nin `mail()` fonksiyonu mesajları teslim edemez. Bir SMTP eklentisi kurun ve onu `smtp.example.com` sunucusu, `587` numaralı port ve STARTTLS ile işlemsel e-posta sağlayıcısına bağlayın; ardından bir parola sıfırlamayla test edin.

> **Not**
>
> HyperDC VPS'lerde giden 25 numaralı port varsayılan olarak kapalıdır. 3 ay veya daha uzun süreyle satın alınan hizmetlerde talep üzerine açılır: [destek talebi açın](/guides/support-tickets). O zamana kadar e-postaları 587 numaralı port üzerinden bir SMTP relay ile gönderin.

## Sonraki adımlar

- WordPress'i doğrudan sunucuda çalıştırmayı mı tercih ediyorsunuz? [Nginx, PHP-FPM ve MariaDB ile WordPress](/guides/install-wordpress-lemp) rehberine bakın.
- Compose dosya biçimini [Docker Compose temelleri](/guides/docker-compose-basics) rehberinde öğrenin.
- WordPress siteleri için planları [WordPress hosting](/wordpress-web-hosting) sayfasında karşılaştırın.
- Tüm değişkenler ve varyantlar için resmi [wordpress imaj belgelerini](https://github.com/docker-library/docs/blob/master/wordpress/content.md) okuyun.

## Sık sorulan sorular

### Reverse proxy arkasında HTTPS için ek ayar gerekir mi?

Genellikle hayır. Resmi wordpress imajı, onu WORDPRESS_ ortam değişkenleriyle yapılandırdığınızda HTTP_X_FORWARDED_PROTO kontrolünü wp-config.php dosyasına kendiliğinden ekler; Caddy de X-Forwarded-Proto başlığını varsayılan olarak gönderir. Site adresinin doğru kaydedilmesi için WordPress'i HTTPS adresi üzerinden kurun.

### Yeni bir wordpress imajı çekmek WordPress'in kendisini günceller mi?

Hayır. İmaj WordPress'i volume'a yalnızca ilk açılışta kopyalar; sonrasında WordPress kendini volume içinde normal güncelleme mekanizmasıyla günceller. Yeni bir imaj çekmek PHP'yi, Apache'yi ve sistem kütüphanelerini günceller.

### WP-CLI konteyneri neden 33 numaralı kullanıcıyla çalışıyor?

cli imajı Alpine tabanlıdır ve orada www-data kullanıcısının UID'si 82'dir; Apache imajı ise UID'si 33 olan Debian www-data kullanıcısını kullanır. WP-CLI'ı imaj belgelerinin önerdiği gibi 33:33 olarak çalıştırmak paylaşılan volume'daki dosya sahipliğini doğru tutar.

### Docker'daki WordPress e-posta gönderebilir mi?

Evet, bir SMTP eklentisiyle; çünkü resmi imaj PHP'nin mail fonksiyonu için bir posta aktarım aracı içermez. HyperDC VPS'lerde giden 25 numaralı port varsayılan olarak kapalıdır. 3 ay veya daha uzun süreyle satın alınan hizmetlerde destek talebiyle açılır. O zamana kadar e-postaları 587 numaralı port üzerinden bir SMTP relay ile gönderin.

### Bunu bir HyperDC sunucusunda çalıştırabilir miyim?

Evet. Rehber, Docker kurulu olarak Ubuntu 24.04, Ubuntu 26.04, Debian 12 veya Debian 13 çalıştıran ve root erişiminiz olan bir HyperDC Linux VPS, VDS veya dedicated sunucuda çalışır. Sunucuyu trafiğinize ve medya dosyalarınıza göre boyutlandırın.

---

Kaynak: <https://hyperdc.com/tr/guides/tutorials/install-wordpress-docker>\
Son güncelleme: 2026-10-09