diff --git a/content/blog/creatorops-self-hosted-content-and-community-operations.md b/content/blog/creatorops-self-hosted-content-and-community-operations.md
new file mode 100644
index 0000000..29435d0
--- /dev/null
+++ b/content/blog/creatorops-self-hosted-content-and-community-operations.md
@@ -0,0 +1,104 @@
+---
+title: "CreatorOps: Self-Hosted Content and Community Operations"
+category: "General"
+date: "2026-07-09"
+readTime: "5 min read"
+author: "Poyraz Avsever"
+slug: "creatorops-self-hosted-content-and-community-operations"
+excerpt: "Social media management seems simple from the outside: find a few content ideas, prepare a draft, and publish. However, when teammates, community contributions, review cycles, and media files get involved, the process can quickly become scattered."
+coverImage: "/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-1.png"
+lang: "en"
+---
+
+# CreatorOps: Self-Hosted Content and Community Operations
+
+
+
+Social media management seems simple from the outside: find a few content ideas, prepare a draft, and publish. However, when teammates, community contributions, review cycles, and media files get involved, the process can quickly become scattered. Content ideas get lost in Notion, drafts in Google Docs, revisions in Slack, and visuals in Drive.
+
+I experienced this problem firsthand while managing the social media side of the Shipin community. What we needed wasn't just a regular "social media scheduling tool," but a "content ops" platform where we could manage all these processes end-to-end.
+
+CreatorOps was born out of this need. My goal was to bring the content calendar, revision workflows, data collection via public forms, dynamic form building, and team management together in the same system. Moreover, I designed all of this in a structure that teams who want to protect their data privacy can run on their own servers (self-hosted).
+
+## The Problem I Tried to Solve
+
+The main problem wasn't producing content, but managing the operation around the content. Let's say we want to collect a success story from the community. For this, a Typeform is opened, data is transferred to Airtable, taken from there and approved on Slack, and finally shared on social media using another tool.
+
+With CreatorOps, I solved this clutter in three stages:
+
+1. **Content Planning and Approval:** The entire calendar and revision process is unified in a single panel.
+2. **Community Contributions:** Offers an infrastructure to collect applications/content from the outside with a dynamic form builder.
+3. **Self-Hosted:** A structure where the data remains completely with you, featuring a single database and a single file upload layer.
+
+
+
+## Technical Architecture and Technologies Used
+
+While developing this project, I wanted to keep the architecture simple but scalable. The project was designed as a **Monorepo** (pnpm workspaces).
+
+### Why Monorepo?
+
+I divided the project into three as `apps/api`, `apps/web`, and `packages/db`. By making the Prisma schema and database types a separate package (`packages/db`), I used the same TypeScript types in both the frontend and backend projects. This way, when I change a field in the database, I can instantly get a type error on the frontend side. This structure provides tremendous convenience in terms of development speed and code consistency.
+
+### Tech Stack
+
+- **Frontend (Web):** React, Vite, TypeScript, React Router. I chose Vite to keep the panel as simple and fast as possible.
+- **Backend (API):** Node.js, Express, TypeScript. A simple and flexible structure to manage domain rules and API endpoints.
+- **Database and ORM:** PostgreSQL and Prisma.
+- **Deployment:** Docker and Docker Compose.
+
+```mermaid
+flowchart LR
+ User[User / Community] --> Web[React + Vite Web]
+ Web --> API[Express API]
+ API --> ORM[Prisma]
+ ORM --> DB[(PostgreSQL)]
+ API --> Uploads[Local Uploads]
+```
+
+## Core Features (What Did I Do?)
+
+### Content Calendar and Approval Workflow
+
+The calendar screen works as the team's daily operation center. What content is scheduled for which day, who it's assigned to, and its status (Draft, Pending Review, Approved) can be seen from a single screen. Content pending approval is clearly indicated in the list, and the revision cycle completely runs through this flow.
+
+
+
+### Public Forms and Dynamic Form Builder
+
+This is where CreatorOps steps out of being just an internal team tool. Managers can create dynamic forms with the question types they want (text, image upload, checkbox, etc.) via the **Form Builder**. These forms can be shared with a public link.
+
+When someone from the community or the outside fills out this form, the data drops directly into the operational flow inside CreatorOps. Thus, there is no need to pay for external form tools or set up integrations.
+
+
+
+### Media Management and Series
+
+I built a built-in media management system into the project. Visuals or PDF files added to the content are written directly to the server's local filesystem. You can also categorize content with the logic of "Series" and assign specific managers to each series.
+
+## Deployment (How is it Installed?)
+
+Self-hosting the application is quite easy. Using Docker Compose, you can bring up the entire structure with a single command.
+
+```mermaid
+flowchart LR
+ Nginx[Nginx] --> API[API Container]
+ Nginx --> Web[Web Container]
+ API --> DB[(PostgreSQL)]
+ API --> Vol[Uploads Volume]
+```
+
+In the production environment, Nginx serves the React project (Web) and routes requests to `/api` and `/uploads` directly to the API container. During the installation phase, the API container automatically runs Prisma migrations while booting up. This way, you don't have to deal with an extra database setup step.
+
+## Trade-offs (What Did I Sacrifice?)
+
+As with every architectural decision, I made some trade-offs here too:
+
+- **Local Upload Storage:** Media files are currently stored on the server's own disk. This makes installation incredibly simple for self-host scenarios, but when the data size grows significantly, an object storage integration like S3 will be required.
+- **Stateless Auth:** I intentionally kept the authentication process simple with JWT. It works well enough at this stage, but more complex auth needs, such as token revocation, can be added in the future.
+
+## Next Steps
+
+I am currently working on a feature to automatically publish content prepared and approved within CreatorOps directly to social media platforms (LinkedIn, Instagram). Once this integration is finished, CreatorOps will turn into a fully-fledged, end-to-end publishing engine.
+
+In summary, CreatorOps is not a project where I just piled on features; it became a product where I tried to solve the right problem with a simple, understandable, and sustainable architecture. If you want to manage your content operations from a single center, with your own data, you can examine the project and install it on your own server.
diff --git a/content/blog/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari.md b/content/blog/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari.md
new file mode 100644
index 0000000..117193f
--- /dev/null
+++ b/content/blog/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari.md
@@ -0,0 +1,103 @@
+---
+title: "CreatorOps: Self-Hosted İçerik ve Topluluk Operasyonları"
+category: "General"
+date: "2026-07-09"
+readTime: "5 min read"
+author: "Poyraz Avsever"
+slug: "creatorops-self-hosted-icerik-ve-topluluk-operasyonlari"
+excerpt: "Sosyal medya yönetimi dışarıdan bakıldığında basit duruyor: Birkaç içerik fikri bul, taslak hazırla ve yayınla. Ancak işin içine ekip arkadaşları, topluluk katkıları, onay (review) döngüleri ve medya dosyaları girince süreç hızla dağılabiliyor."
+coverImage: "/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-1.png"
+---
+
+# CreatorOps: Self-Hosted İçerik ve Topluluk Operasyonları
+
+
+
+Sosyal medya yönetimi dışarıdan bakıldığında basit duruyor: Birkaç içerik fikri bul, taslak hazırla ve yayınla. Ancak işin içine ekip arkadaşları, topluluk katkıları, onay (review) döngüleri ve medya dosyaları girince süreç hızla dağılabiliyor. İçerik fikirleri Notion'da, taslaklar Google Docs'ta, revizyonlar Slack'te, görseller ise Drive'da kayboluyor.
+
+Bu problemi bizzat Shipin topluluğunda sosyal medya tarafını yönetirken yaşadım. İhtiyacımız olan şey sıradan bir "sosyal medya planlama aracı" değil, tüm bu süreçleri uçtan uca yönetebileceğimiz bir "içerik operasyon (content ops)" platformuydu.
+
+CreatorOps bu ihtiyaçtan doğdu. Amacım, içerik takvimi, revizyon akışları, dışarıdan (public) formlar ile veri toplama, dinamik form oluşturma ve takım yönetimini aynı sistemde buluşturmaktı. Üstelik tüm bunları, veri gizliliğini korumak isteyen ekipler için kendi sunucularında (self-hosted) çalıştırabilecekleri bir yapıda kurguladım.
+
+## Çözmeye Çalıştığım Problem
+
+Asıl sorun içerik üretmek değil, içeriğin etrafındaki operasyonu yönetmekti. Diyelim ki topluluktan bir başarı hikayesi toplamak istiyoruz. Bunun için bir Typeform açılıyor, veriler Airtable'a aktarılıyor, oradan alınıp Slack'te onaylanıyor ve en son başka bir araçla sosyal medyada paylaşılıyor.
+
+CreatorOps ile bu dağınıklığı üç aşamada çözdüm:
+
+1. **İçerik Planlama ve Onay:** Tüm takvim ve revizyon süreci tek bir panelde birleşiyor.
+2. **Topluluk Katkıları:** Dinamik form builder ile dışarıdan başvuru/içerik toplama altyapısı sunuyor.
+3. **Self-Hosted:** Verinin tamamen sizde kaldığı, tek veritabanı ve tek dosya yükleme (upload) katmanı.
+
+
+
+## Teknik Mimari ve Kullanılan Teknolojiler
+
+Bu projeyi geliştirirken mimariyi sade ama ölçeklenebilir tutmak istedim. Proje bir **Monorepo** (pnpm workspaces) olarak tasarlandı.
+
+### Neden Monorepo?
+
+Projeyi `apps/api`, `apps/web` ve `packages/db` olarak üçe böldüm. Prisma şemasını ve veritabanı tiplerini ayrı bir paket (`packages/db`) yaparak hem frontend hem de backend projelerinde aynı TypeScript tiplerini kullandım. Bu sayede veritabanında bir alanı değiştirdiğimde, frontend tarafında anında tip hatası (type error) alabiliyorum. Bu yapı, geliştirme hızı ve kod tutarlılığı açısından müthiş bir kolaylık sağlıyor.
+
+### Teknoloji Yığını (Tech Stack)
+
+- **Frontend (Web):** React, Vite, TypeScript, React Router. Paneli olabildiğince sade ve hızlı tutmak için Vite tercih ettim.
+- **Backend (API):** Node.js, Express, TypeScript. Domain kurallarını ve API uç noktalarını (endpoints) yönetmek için basit ve esnek bir yapı.
+- **Veritabanı ve ORM:** PostgreSQL ve Prisma.
+- **Dağıtım (Deployment):** Docker ve Docker Compose.
+
+```mermaid
+flowchart LR
+ User[Kullanıcı / Topluluk] --> Web[React + Vite Web]
+ Web --> API[Express API]
+ API --> ORM[Prisma]
+ ORM --> DB[(PostgreSQL)]
+ API --> Uploads[Local Uploads]
+```
+
+## Temel Özellikler (Neler Yaptım?)
+
+### İçerik Takvimi ve Onay Akışı
+
+Takvim ekranı, ekibin günlük operasyon merkezi olarak çalışıyor. Hangi gün hangi içerik var, kime atanmış ve durumu ne (Draft, Pending Review, Approved) tek bir ekrandan görünüyor. Onay bekleyen içerikler listede açıkça belirtiliyor ve revizyon döngüsü tamamen bu akış üzerinden işliyor.
+
+
+
+### Public Forms ve Dinamik Form Oluşturucu
+
+CreatorOps'u sadece bir iç ekip aracı olmaktan çıkaran yer burası. Yöneticiler, **Form Builder** üzerinden istedikleri soru tipleriyle (metin, görsel yükleme, onay kutusu vb.) dinamik formlar oluşturabiliyor. Bu formlar herkese açık (public) bir link ile paylaşılabiliyor.
+
+Topluluktan veya dışarıdan biri bu formu doldurduğunda, veriler doğrudan CreatorOps'un içindeki operasyon akışına düşüyor. Böylece harici form araçlarına para ödemek veya entegrasyon kurgulamak gerekmiyor.
+
+
+
+### Medya Yönetimi ve Seriler
+
+Projeye yerleşik bir medya yönetim sistemi kurdum. İçeriklere eklenen görseller veya PDF dosyaları doğrudan sunucunun yerel diskine (local filesystem) yazılıyor. Ayrıca "Seriler" (Series) mantığıyla içerikleri kategorize edip, her seriye özel yöneticiler atayabiliyorsunuz.
+
+## Deployment (Nasıl Kuruluyor?)
+
+Uygulamayı self-host etmek oldukça kolay. Docker Compose kullanarak tüm yapıyı tek bir komutla ayağa kaldırabiliyorsunuz.
+
+```mermaid
+flowchart LR
+ Nginx[Nginx] --> API[API Container]
+ Nginx --> Web[Web Container]
+ API --> DB[(PostgreSQL)]
+ API --> Vol[Uploads Volume]
+```
+
+Production ortamında Nginx, React projesini (Web) sunuyor ve `/api` ile `/uploads` isteklerini doğrudan API container'ına yönlendiriyor. Kurulum aşamasında API container'ı ayağa kalkarken otomatik olarak Prisma migration'larını çalıştırıyor. Böylece ekstra bir veritabanı kurulum adımıyla uğraşmanıza gerek kalmıyor.
+
+## Trade-off'lar (Nelerden Feragat Ettim?)
+
+Her mimari kararda olduğu gibi burada da bazı ödünler verdim:
+
+- **Local Upload Storage:** Medya dosyaları şu an sunucunun kendi diskinde tutuluyor. Self-host senaryoları için kurulumu inanılmaz basitleştiriyor, ancak veri boyutu çok büyüdüğünde S3 gibi bir object storage entegrasyonu gerekecek.
+- **Stateless Auth:** Kimlik doğrulama sürecini JWT ile bilerek basit tuttum. Şu aşamada gayet yeterli çalışıyor, fakat ileride yetkilendirme iptalleri (token revocation) gibi daha kompleks auth ihtiyaçları eklenebilir.
+
+## Sonraki Adımlar
+
+Şu anda CreatorOps içerisinde hazırlanan ve onaylanan içerikleri doğrudan sosyal medya platformlarına (LinkedIn, Instagram) otomatik publish etme özelliği üzerinde çalışıyorum. Bu entegrasyon bittiğinde, CreatorOps baştan uca tam teşekküllü bir yayın motoruna dönüşecek.
+
+Özetle CreatorOps benim için öylesine özellik yığdığım bir proje değil; doğru problemi basit, anlaşılır ve sürdürülebilir bir mimariyle çözmeye çalıştığım bir ürün oldu. Eğer siz de içerik operasyonlarınızı tek bir merkezden, kendi verinizle yönetmek isterseniz projeyi inceleyebilir ve kendi sunucunuza kurabilirsiniz.
diff --git a/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-1.png b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-1.png
new file mode 100644
index 0000000..049347d
Binary files /dev/null and b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-1.png differ
diff --git a/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-10.png b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-10.png
new file mode 100644
index 0000000..b045736
Binary files /dev/null and b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-10.png differ
diff --git a/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-2.png b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-2.png
new file mode 100644
index 0000000..bf08d46
Binary files /dev/null and b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-2.png differ
diff --git a/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-3.png b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-3.png
new file mode 100644
index 0000000..0a0beb1
Binary files /dev/null and b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-3.png differ
diff --git a/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-4.png b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-4.png
new file mode 100644
index 0000000..d10d79b
Binary files /dev/null and b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-4.png differ
diff --git a/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-5.png b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-5.png
new file mode 100644
index 0000000..d5e7d95
Binary files /dev/null and b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-5.png differ
diff --git a/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-6.png b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-6.png
new file mode 100644
index 0000000..ce04a63
Binary files /dev/null and b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-6.png differ
diff --git a/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-7.png b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-7.png
new file mode 100644
index 0000000..b1a3254
Binary files /dev/null and b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-7.png differ
diff --git a/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-8.png b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-8.png
new file mode 100644
index 0000000..552ef17
Binary files /dev/null and b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-8.png differ
diff --git a/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-9.png b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-9.png
new file mode 100644
index 0000000..b0d8a07
Binary files /dev/null and b/public/blog/images/creatorops-self-hosted-icerik-ve-topluluk-operasyonlari-img-9.png differ