Why WriteFreely?

After years with various blogging platforms, I was looking for something simpler. Ghost was great, but:

• ✅ Native ActivityPub Integration – My blog is automatically available in the Fediverse
• ✅ Minimal Resource Usage – Single binary, no Node.js, no complex infrastructure
• ✅ Focus on Writing – No distractions, just writing
• ✅ Self-hosted – Full control over my data

• ✅ Markdown-native – No formatting battles

  Setup: WriteFreely on LXC (Proxmox)

Why Native Installation Instead of Docker?

After several frustrating hours with Docker mount problems, I decided on native installation. Best decision ever!

# Download WriteFreely binary
cd /opt
wget https://github.com/writefreely/writefreely/releases/download/v0.15.0/writefreely_0.15.0_linux_arm64.tar.gz
tar -xzf writefreely_0.15.0_linux_arm64.tar.gz
mv writefreely /opt/writefreely
cd /opt/writefreely

# Interactive configuration
./writefreely --config

Configuration (config.ini)

[server]
bind = 0.0.0.0  # Important for reverse proxy
port = 8080
https = false   # Reverse proxy handles HTTPS

[app]
site_name = My Blog
host = https://blog.example.com  # Your real domain!
single_user = true
federation = true  # This is the key!
public_registration = false

[database]
type = sqlite3  # Simpler than MySQL for single user
filename = writefreely.db

As systemd Service

# Create service file
sudo tee /etc/systemd/system/writefreely.service << 'EOF'
[Unit]
Description=WriteFreely
After=network.target

[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/opt/writefreely
ExecStart=/opt/writefreely/writefreely
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable writefreely
sudo systemctl start writefreely

Reverse Proxy (Traefik/Nginx)

Example configuration: – Frontend: blog.example.com – Backend: http://192.168.1.100:8080 – SSL: Automatic

Migration from Ghost

Export from Ghost

Ghost Admin → Settings → Labs → “Export content”

Migration Script (Python)

Since WriteFreely's import features are limited, I migrated most posts manually. For automatic migration:

#!/usr/bin/env python3
import json
import requests
from datetime import datetime

def migrate_ghost_to_writefreely(ghost_export, writefreely_url, token):
    with open(ghost_export, 'r') as f:
        data = json.load(f)
    
    posts = data['db'][0]['data']['posts']
    
    for post in posts:
        if post['status'] == 'published':
            # WriteFreely API Call
            payload = {
                'body': convert_html_to_markdown(post['html']),
                'title': post['title']
            }
            # ... API integration

My tip: For small blogs (< 20 posts), manual copying is often faster and cleaner.

Custom CSS: The Perfect Dark Theme

After many iterations, here's my final WriteFreely dark theme:

/* WriteFreely Custom Dark Theme */

/* === SANS-SERIF FONT === */
body, html, * {
    font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', system-ui, sans-serif !important;
}

/* === ANTHRACITE DESIGN === */
body, html {
    background: #2e2e2e !important;
    color: #f0f0f0 !important;
}

/* === COLORED HEADING HIERARCHY === */
body h1 { color: #ffffff !important; font-size: 1.8rem !important; }
body h2 { color: #7db3f3 !important; font-size: 1.5rem !important; }
body h3 { color: #98d982 !important; font-size: 1.3rem !important; }
body h4 { color: #f9cc81 !important; font-size: 1.2rem !important; }

/* === LINKS === */
body a { color: #7db3f3 !important; }
body a:hover { color: #98d982 !important; }

/* === CODE BOXES (This was a battle!) === */
body pre {
    background: #1e1e1e !important;
    color: #f0f0f0 !important;
    border: 1px solid #444 !important;
    border-radius: 8px !important;
    padding: 1rem !important;
}

body code {
    background: #1e1e1e !important;
    color: #f0f0f0 !important;
    border: 1px solid #444 !important;
    border-radius: 8px !important;
    padding: 0.2rem 0.4rem !important;
}

/* === IMAGES WITH ROUNDED CORNERS === */
body img {
    border-radius: 12px !important;
    max-width: 100% !important;
}

/* === REMOVE FOOTER === */
body footer { display: none !important; }

HTML Shortcuts for Beautiful Images

For consistent image presentation, I use these HTML shortcuts:

<!-- Standard image with shadow -->
<img src="https://cdn.example.com/images/image.png" alt="Description" 
     style="border-radius: 12px !important; 
            box-shadow: 0 8px 24px rgba(0,0,0,0.3) !important; 
            margin: 2rem auto !important; 
            display: block !important;">

<!-- Image with caption -->
<figure style="text-align: center; margin: 2rem auto;">
    <img src="https://cdn.example.com/images/image.png" alt="Description"
         style="border-radius: 12px !important; 
                box-shadow: 0 8px 24px rgba(0,0,0,0.3) !important;">
    <figcaption style="color: #8b949e; font-style: italic; margin-top: 1rem;">
        Caption here
    </figcaption>
</figure>

ActivityPub: Automatically in the Fediverse

The best thing about WriteFreely: It just works!

• My blog: @username@blog.example.com
• Followers: Automatically via Mastodon, Pleroma, etc.
• Posts: Automatically federated to the Fediverse
• Interaction: Comments via ActivityPub possible

Testing Federation

# Test WebFinger
curl https://blog.example.com/.well-known/webfinger?resource=acct:username@blog.example.com

# ActivityPub profile
curl -H "Accept: application/activity+json" https://blog.example.com/@username

Troubleshooting: Common Problems

Problem 1: Code boxes stay white

Solution: Edit WriteFreely's write.css directly:

cd /opt/writefreely/static/css
sudo nano write.css

# Search for: background:#f8f8f8
# Replace with: background:#1e1e1e

Problem 2: CSS not applied

Solution: Aggressively clear browser cache, test different browsers.

Problem 3: ActivityPub doesn't work

Solution: – federation = true in config.ini – host = https://your-real-domain.com (not localhost!) – Reverse proxy configured correctly

Webspace for Images

Separate container for static assets:

# docker-compose.yml for webspace
services:
  webspace:
    image: httpd:latest
    volumes:
      - ./webspace:/usr/local/apache2/htdocs
    labels:
      - "traefik.http.routers.webspace.rule=(Host(`cdn.example.com`))"
      # ... Additional labels

Conclusion: Is the Switch Worth It?

Definitely yes! After migration:

✅ Much faster – Page loads lightning fast ✅ Less maintenance – One binary, no updates, no Node.js ✅ Fediverse integration – My posts automatically reach more people ✅ Focus on writing – No distractions from complex themes/plugins ✅ Resource efficient – Runs smoothly on small LXC

Resources

• WriteFreely: https://writefreely.org
• ActivityPub Plugin (WordPress): https://wordpress.org/plugins/activitypub/
• Fediverse Test: https://fediverse.party

Credits

• Header Image by Daniel Thomas on Unsplash

Migration completed: ✅ Self-hosted, ✅ Fediverse-ready, ✅ Minimal & fast

TL;DR: It finally works smoothlyThe key takeaways upfront:

• ✅ Docker installation runs cleanly through
• ✅ .well-known federation is recognized immediately
• ✅ Element X with Sliding Sync works out-of-the-box
• ✅ Traefik integration without hickups
• ✅ IPv4 & IPv6 federation active from the start

In short: What used to cost hours or days now works in under an hour. But let me explain step by step...

The technical starting pointFor my setup I use:

• Synapse as Matrix homeserver
• PostgreSQL as database
• Traefik as reverse proxy with Let's Encrypt
• Docker Compose for orchestration

The target architecture:

• example.com as Matrix domain (for @username:example.com)
• matrix.example.com as technical server endpoint
• Well-Known delegation for clean separation

What used to be problematicDuring my last Matrix installation attempts a few years ago, these were the usual stumbling blocks:

Database permissions

# This was standard:
psql: FATAL: password authentication failed for user "synapse"
permission denied for table xyz

Federation debugging

# Federation tester always resulted in:
"CanReachViaHTTPS": false,
"DNSCheck": false

Well-Known endpoints

The .well-known/matrix/client and .well-known/matrix/server configuration was always a trial-and-error process with cryptic error messages.

Element X and Sliding

SyncSliding Sync didn't even exist yet, and when it did, it came with separate proxy containers and complicated configuration.

The 2025 installation: Surprisingly smooth

1. Docker Compose setup

My compose.yml has become refreshingly compact:

services:
  synapse:
    image: matrixdotorg/synapse:latest
    restart: unless-stopped
    environment:
      SYNAPSE_SERVER_NAME: example.com
      SYNAPSE_REPORT_STATS: "no"
    volumes:
      - ./data:/data
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=proxy"
      
      # Client API (über websecure/443 mit CrowdSec-Schutz)
      - "traefik.http.routers.matrix-client.entrypoints=websecure"
      - "traefik.http.routers.matrix-client.rule=(Host(`matrix.example.com`))"
      - "traefik.http.routers.matrix-client.tls=true"
      - "traefik.http.routers.matrix-client.tls.certresolver=http_resolver"
      - "traefik.http.routers.matrix-client.service=matrix-client"
      - "traefik.http.routers.matrix-client.middlewares=default@file"
      - "traefik.http.services.matrix-client.loadbalancer.server.port=8008"

      # Federation API (über Port 443, OHNE CrowdSec!)
      - "traefik.http.routers.matrix-federation.entrypoints=matrix-federation"
      - "traefik.http.routers.matrix-federation.rule=(Host(`matrix.example.com`))"
      - "traefik.http.routers.matrix-federation.tls=true"
      - "traefik.http.routers.matrix-federation.tls.certresolver=http_resolver"
      - "traefik.http.routers.matrix-federation.service=matrix-federation"
      - "traefik.http.services.matrix-federation.loadbalancer.server.port=8008"
      
  postgres:
    image: postgres:15
    restart: unless-stopped
    environment:
      POSTGRES_DB: synapse
      POSTGRES_USER: synapse
      POSTGRES_PASSWORD: secure_random_password

That's it. No complicated volume mounts, no permission fixes, no custom Dockerfiles.

2. Homeserver configuration

The homeserver.yaml has become significantly more user-friendly. The most important changes for 2025:

# Element X Support eingebaut
experimental_features:
  msc3575_enabled: true

unstable_features:
  org.matrix.simplified_msc3575: true

# Public Base URL für saubere Links  
public_baseurl: "https://matrix.example.com"

# Well-Known Federation
server_name: "example.com"

# Federation über Port 8008
listeners:
  - port: 8008
    tls: false
    type: http
    x_forwarded: true
    resources:
      - names: [client, federation]
        compress: false

That's it! No separate Sliding Sync proxy, no complicated MSC feature activation.

3. Well-Known delegation

The .well-known/matrix/client on example.com:

{
  "m.homeserver": {
    "base_url": "https://matrix.example.com"
  },
  "m.identity_server": {
    "base_url": "https://vector.im"
  }
}

And .well-known/matrix/server:

{
  "m.server": "matrix.example.com:443"
}

Result: Federation tester shows green immediately!

Element X: The game changer

The biggest difference from before is Element X. Installation was trivial:

1. Install app
2. Enter server: example.com
3. Login: @username:example.com
4. Sliding Sync works automatically

No separate proxy containers, no experimental API endpoints, no beta features. It just works.

The performance is noticeably better than Element Classic:

• Instant synchronization between devices
• Rooms load significantly faster
• Offline support is more robust

Federation: Finally hassle-free

Everything green, IPv4 and IPv6 work, federation runs immediately.

Performance and resource consumption

The current setup is surprisingly efficient:

CONTAINER           CPU %     MEM USAGE / LIMIT     MEM %
matrix-synapse-1    0.52%     222.5MiB / 23.41GiB   0.93%
matrix-postgres-1   0.10%     117.9MiB / 23.41GiB   0.49%

Absolutely fine for a single-user server – under 1% CPU load and less than 350MB RAM total. The PostgreSQL integration runs stable, no memory leaks or performance issues.

What I learned

1. The Matrix ecosystem has matured

The development of recent years shows: Matrix has evolved from an interesting experiment to a production-ready platform. Installation has become significantly more user-friendly.

2. Element X makes the difference

Sliding Sync isn't just a technical feature – it fundamentally changes the user experience. Matrix finally feels as responsive as modern messengers.

3. Well-Known delegation is brilliant

The ability to use @username:example.com as Matrix ID while running the technical server on matrix.example.com is perfect for branding and flexibility.

4. Docker Compose is completely sufficient

No Kubernetes, no complex orchestration tools needed. Docker Compose with Traefik is absolutely adequate for self-hosting setups.

Lessons learned and tips

Do's ✅

• Use PostgreSQL instead of SQLite – even for single-user setups
• Enable Sliding Sync directly in Synapse instead of separate proxies
• Use Well-Known delegation for clean domain separation
• Test federation immediately with the Matrix Federation Tester

Don'ts ❌

• No complex identity servers for private setups
• No Element Web if you only use native apps
• No excessive resource limits – Matrix has become more efficient
• Don't optimize too early – the defaults work well

Conclusion: Matrix is finally self-hosting-ready

After years of “almost, but not quite” experiences, I can say: Matrix self-hosting is finally seamlessly possible in 2025.

Development has reached the point where installation is no longer the most difficult part. Instead, you can focus on what Matrix is designed for: decentralized, secure communication without vendor lock-in.

Who want to reach me directly and encrypted? @matthias:klein.ruhr 🔐

After completing the full migration and running in production for weeks, I can confidently say GoToSocial is ready for serious use.

Perfect For: ✅

• Self-hosters with limited resources (VPS with 1-2GB RAM? No problem!)
• Single-user or small family instances (works great up to ~50 users based on community reports)
• Homelab enthusiasts who value efficiency and simplicity
• Privacy-conscious users who want full control over their data
• Developers who appreciate clean, well-documented APIs

Think Twice If: ⚠️

• Large communities (100+ users – not extensively tested yet)
• Power users who rely heavily on advanced Mastodon features
• Mobile-first users who need perfect app compatibility

• Non-technical admins who prefer GUI-based administration

  Resource Requirements: The Reality Check

# Minimum viable setup:
VPS: 1GB RAM, 1 CPU core, 20GB storage
Cost: ~$5-10/month

# My production setup:
Server: Proxmox LXC container
Resources: 2GB RAM, 2 CPU cores, 50GB storage  
Actual usage: 426MB RAM average, 15% CPU peak
Cost: $0 (runs on existing homelab hardware)

# Scaling considerations:
- Single-user: 512MB RAM sufficient
- 5-10 users: 1GB RAM recommended
- 10-50 users: 2GB RAM should handle it
- Database grows ~1-2GB per month with active use

Why Even Consider Switching?

After months of running a self-hosted Mastodon instance in my homelab, I was getting increasingly frustrated. Not with the Fediverse concept – that's brilliant – but with Mastodon's resource appetite.

The Starting Point:

• Mastodon Docker stack: 4-5 GB RAM consumption
• Storage growth: ~100 GB with 7-day media retention
• Performance: Noticeable delays in timeline updates
• Maintenance: Regular cleanup scripts required to keep things manageable

When you're running 60+ Docker stacks in your homelab like I am, resource efficiency isn't just nice-to-have – it's essential. GoToSocial promised the same Fediverse functionality at a fraction of the resource cost.

Technical Stack Context:

# My homelab setup
Proxmox Cluster: 3 nodes
Total Containers: 60+ Docker stacks
Mastodon Dependencies:
  - PostgreSQL (shared instance)
  - Redis (shared instance) 
  - Elasticsearch (optional, but resource-hungry)
  - Sidekiq workers (multiple processes)
  - Web server + streaming API

The complexity was getting out of hand.

The Migration Process: Technical Deep-Dive

Testing Phase

Before committing fully, I ran GoToSocial parallel to Mastodon for four weeks. This gave me real-world data without burning bridges.

# compose.yml - GoToSocial setup
services:
  gotosocial:
    image: superseriousbusiness/gotosocial:latest
    container_name: gotosocial
    restart: unless-stopped
    environment:
      GTS_HOST: your-domain.com
      GTS_DB_TYPE: postgres
      GTS_DB_ADDRESS: postgres:5432
      GTS_DB_DATABASE: gotosocial
      GTS_DB_USER: gotosocial
      GTS_DB_PASSWORD: ${GTS_DB_PASSWORD}
      GTS_ACCOUNTS_REGISTRATION_OPEN: false
      GTS_ACCOUNTS_APPROVAL_REQUIRED: true
      GTS_MEDIA_REMOTE_CACHE_DAYS: 7
      GTS_STORAGE_LOCAL_BASE_PATH: /gotosocial/storage
    volumes:
      - ./data:/gotosocial/storage
    networks:
      - traefik_default
      - gotosocial_db
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.gotosocial.rule=Host(\`your-domain.com\`)"
      - "traefik.http.routers.gotosocial.tls.certresolver=letsencrypt"
    depends_on:
      - postgres

  postgres:
    image: postgres:15-alpine
    container_name: gotosocial_db
    restart: unless-stopped
    environment:
      POSTGRES_DB: gotosocial
      POSTGRES_USER: gotosocial
      POSTGRES_PASSWORD: ${GTS_DB_PASSWORD}
    volumes:
      - ./postgres:/var/lib/postgresql/data
    networks:
      - gotosocial_db

Key Configuration Decisions:

• Separate Database: Not sharing with Mastodon to avoid conflicts
• 7-Day Media Retention: Balancing storage vs. content availability
• Traefik Integration: Seamless SSL termination and routing
• Bind Mounts: Easy backup/restore without Docker volume complexity

Account Migration: The Technical Reality

The actual migration process was surprisingly smooth, but had some gotchas:

1. Mastodon Export

# Export process (takes 24-48 hours for large instances)
# Mastodon Admin → Settings → Import/Export → Request Archive
# Results in: archive-[timestamp].tar.gz

2. Post Import with slurp

# Install slurp
git clone https://github.com/superseriousbusiness/gotosocial-slurp
cd gotosocial-slurp
go build .

# Import 380 posts from Mastodon archive
./slurp import \
  --gts-endpoint https://your-domain.com \
  --gts-token YOUR_GTS_TOKEN \
  --mastodon-archive archive-20241215.tar.gz \
  --dry-run false

# Results: Perfect import with media, metadata, and timestamps preserved

3. Account Redirect Setup

# In Mastodon rails console
rails console
account = Account.find_by(username: 'your_username')
account.update(moved_to_account_id: nil) # Clear any previous moves
# Then use Mastodon UI: Settings → Account → Move to different account

Migration Casualties:

• Lost ~50 followers (12% dropout rate)
• Likely causes: inactive accounts, app compatibility issues, users who don't follow redirects
• Lesson: Quality over quantity – the remaining followers are actually engaged

Performance Benchmarks: Numbers Don't Lie

Memory Usage Deep-Dive

# Monitoring setup with docker stats
docker stats --format "table {{.Container}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}"

# Mastodon (before migration):
CONTAINER       CPU %    MEM USAGE / LIMIT     MEM %
mastodon_web    45.2%    2.1GiB / 8GiB        26.25%
mastodon_sidekiq 23.1%   1.8GiB / 8GiB        22.50%
mastodon_streaming 12.4% 512MiB / 8GiB        6.40%
redis           8.7%     256MiB / 8GiB        3.20%
postgres        15.3%    800MiB / 8GiB        10.00%
elasticsearch   35.8%    1.2GiB / 8GiB        15.00%
Total: ~6.7GB peak usage

# GoToSocial (after migration):
CONTAINER       CPU %    MEM USAGE / LIMIT     MEM %
gotosocial      12.3%    419MiB / 8GiB        5.24%
postgres        3.2%     128MiB / 8GiB        1.60%
fedifetcher     0.8%     3.4MiB / 8GiB        0.04%
gts-holmirdas   1.1%     3.7MiB / 8GiB        0.05%
Total: ~555MB peak usage

RAM Efficiency Gain: 92% reduction (6.7GB → 555MB)

Storage Analysis

# Mastodon storage breakdown (after 6 months):
du -sh /opt/mastodon/*
12G     system/  (cache, media_attachments)
45G     public/  (user uploads, cached media)
43G     postgres_data/  (database)
Total: ~100GB with aggressive 7-day cleanup

# GoToSocial storage (extrapolated to same timeframe):
du -sh /opt/gotosocial/*
8.2G    storage/  (all media, database)
26G     postgres_data/  (more efficient schema)
Total: ~35GB with 7-day remote media retention

Storage Efficiency Gain: 65% reduction

Why GoToSocial is so much leaner:

• Single binary: No separate web/worker/streaming processes
• Efficient database schema: Less metadata overhead per post
• Smart media handling: Better deduplication and compression
• No Elasticsearch: Full-text search handled by PostgreSQL

Federation Performance: Quality Over Quantity

One of my biggest concerns was federation reach. Would a single-user GoToSocial instance feel isolated?

The Data After 4 Days:

# Federation stats from GoToSocial admin API
curl -H "Authorization: Bearer $ADMIN_TOKEN" \
  https://your-domain.com/api/v1/admin/accounts/stats

{
  "known_instances": 2750,
  "federated_posts": 12847,
  "local_posts": 380,
  "active_users_week": 1
}

Federation happens FAST:

• 2,750+ instances discovered in 4 days
• No traditional relays needed
• Content discovery through intelligent RSS integration
• Federation quality actually improved (more relevant content, less noise)

Content Discovery: Building GTS-HolMirDas

Here's where things got interesting. Small Fediverse instances suffer from the “empty timeline problem” – without many local users or relay connections, your federated timeline stays pretty barren.

The Technical Challenge

# Traditional approach: Join relays
# Problems:
# - High resource usage
# - Lots of irrelevant content  
# - Reliability issues
# - Limited control over content quality

My Solution: Intelligent RSS-to-Fediverse Bridge

I built GTS-HolMirDas (German pun meaning “fetch this for me”), an open-source tool that:

Core Architecture:

# Simplified architecture overview
class HolMirDas:
    def __init__(self):
        self.rss_feeds = self.load_feed_config()  # 102 RSS feeds
        self.gts_client = GoToSocialClient()
        self.duplicate_tracker = DuplicateDetector()
        self.instance_tracker = InstanceTracker()
    
    def run_cycle(self):
        """Main processing loop - runs every hour"""
        for feed_url, config in self.rss_feeds.items():
            self.process_feed(feed_url, config)
        
        self.cleanup_old_entries()
        self.update_federation_stats()

Smart Features:

• Cross-platform attribution: Properly credits Mastodon, Misskey, Pleroma authors
• Duplicate detection: Prevents the same post from appearing multiple times
• Instance discovery: Automatically tracks new Fediverse instances
• Rate limiting: Respects both RSS and GoToSocial API limits

Performance Metrics

# Real-time stats from my instance:
📊 GTS-HolMirDas Run Statistics:
   ⏱️  Runtime: 4:39 minutes per cycle
   📄 Posts processed: 65 per hour  
   🌐 Current known instances: 2,697
   ➕ New instances discovered: +22 per run
   📡 RSS feeds monitored: 102
   ⚡ Processing rate: 13.9 posts/minute
   🔄 Runs every 60 minutes automatically

RSS Feed Sources

# feed_config.yml (excerpt)
feeds:
  # Major Mastodon instances
  - url: "https://mastodon.social/@Gargron.rss"
    platform: "mastodon"
    instance: "mastodon.social"
  
  # Specialized instances  
  - url: "https://fosstodon.org/users/example_user.rss"
    platform: "mastodon"
    instance: "fosstodon.org"
    
  # Other Fediverse platforms
  - url: "https://pixelfed.social/users/photographer.atom"
    platform: "pixelfed"
    instance: "pixelfed.social"

The Result: A vibrant federated timeline despite being a single-user instance, with content that's actually relevant to my interests.

Lessons Learned: The Good, The Bad, The Ugly

What Works Brilliantly ✅

Resource Efficiency is Game-Changing

• Single binary vs. multiple processes: Much simpler debugging
• Memory usage stays consistently under 500MB even under load
• CPU usage rarely spikes above 15% during federation heavy-lifting
• Storage growth is predictable and manageable

Federation Just Works™

• No manual instance discovery needed
• ActivityPub compatibility is excellent
• Cross-platform federation (Mastodon ↔ Misskey ↔ Pleroma) seamless
• Better federation performance than expected

Operational Simplicity

# Mastodon maintenance (weekly):
docker compose exec web bundle exec rake mastodon:media:remove_remote
docker compose exec web bundle exec rake mastodon:preview_cards:remove_old
docker compose exec web bundle exec rake mastodon:feeds:build
# + manual Elasticsearch index management
# + Sidekiq queue monitoring
# + Redis memory management

# GoToSocial maintenance (monthly):
# That's it. Seriously.

The Challenges ⚠️

Client Ecosystem

• Mobile Apps: Hit-or-miss compatibility
  • iOS Tusker: Works perfectly, actively maintained
  • iOS Ice Cubes: Notification issues, otherwise great
  • Android Tusky: Mostly works, some UI quirks
  • Android Fedilab: Best overall experience
• Web Clients: Need self-hosting for optimal experience

Missing Mastodon Features (That You Might Miss)

• Advanced search capabilities (no Elasticsearch)
• Trending hashtags/posts
• Some admin tools are more basic
• Limited API endpoints compared to Mastodon

Federation Edge Cases

# Occasional federation hiccups I encountered:
- Large instances sometimes lag on post delivery (not GTS fault)
- Some Mastodon instances reject GTS posts (rare, usually config issues)
- Media federation can be slow during high-traffic periods

Mobile Apps: Real-World Testing

iOS Testing Results:

Tusker: 9/10

• ✅ Full feature support
• ✅ Reliable notifications
• ✅ Good performance
• ❌ Paid app ($3.99)

Ice Cubes: 7/10

• ✅ Beautiful interface
• ✅ Active development
• ❌ Notification reliability issues
• ❌ Some API compatibility gaps

Self-Hosted Web Clients:

# My current setup
services:
  phanpy:
    image: cheeaun/phanpy:latest
    container_name: phanpy
    environment:
      DEFAULT_INSTANCE: your-domain.com
    labels:
      - "traefik.http.routers.phanpy.rule=Host(\`social.your-domain.com\`)"
  
  elk:
    image: elkzone/elk:latest
    container_name: elk
    environment:
      DEFAULT_SERVER: your-domain.com
    labels:
      - "traefik.http.routers.elk.rule=Host(\`elk.your-domain.com\`)"

Client Comparison:

• Phanpy: Better features, more Mastodon-like, slightly dated UI
• Elk: Gorgeous interface, modern UX, fewer power-user features
• Official GTS Web UI: Basic but functional, good for admin tasks

Cost Analysis

Comparison with Mastodon hosting costs:

Mastodon requirements:

• Minimum: 4GB RAM, 2 cores
• Monthly VPS cost: $20-40
• Additional services needed: Redis, Elasticsearch (optional but recommended)

GoToSocial requirements:

• Minimum: 1GB RAM, 1 core
• Monthly VPS cost: $5-10
• Additional services: Just PostgreSQL (can use SQLite for single-user)

Annual savings: $180-360 per year

Backup Strategy: Lessons from Migration

#!/bin/bash
# My automated backup script
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/opt/backups/gotosocial"

# Database backup
docker compose exec -T postgres pg_dump -U gotosocial gotosocial > \
  "$BACKUP_DIR/db_backup_$DATE.sql"

# Media and storage backup
tar -czf "$BACKUP_DIR/storage_backup_$DATE.tar.gz" \
  /opt/gotosocial/data/

# Configuration backup  
cp compose.yml "$BACKUP_DIR/compose_backup_$DATE.yml"

# Keep only last 7 days of backups
find "$BACKUP_DIR" -name "*.sql" -mtime +7 -delete
find "$BACKUP_DIR" -name "*.tar.gz" -mtime +7 -delete

echo "Backup completed: $DATE"

Recovery tested and verified – I've successfully restored from backup during my testing phase. The process is straightforward and well-documented.

The Tools That Make It Work

All the supporting tools I built are open source and production-ready:

GTS-HolMirDas

Repository:https://git.klein.ruhr/matthias/gts-holmirdas

Features:

• 102 RSS feed sources from diverse Fediverse instances
• Cross-platform attribution (Mastodon, Misskey, Pleroma, Pixelfed)
• Intelligent duplicate detection
• Automatic instance discovery
• Rate limiting and error handling
• Docker-ready deployment

Setup in 5 minutes:

git clone https://git.your-domain.com/username/gts-holmirdas.git
cd gts-holmirdas
cp config.example.yml config.yml
# Edit config.yml with your GTS instance details
docker compose up -d

FediFetcher Integration

Repository: blog.thms.uk/fedifetcher

While not my creation, FediFetcher perfectly complements GoToSocial for thread completion:

# compose.yml addition
services:
  fedifetcher:
    image: nanos/fedifetcher:latest
    container_name: fedifetcher
    environment:
      - HOME_INSTANCE=your-domain.com
      - ACCESS_TOKEN=${FEDIFETCHER_TOKEN}
      - REPLY_INTERVAL_HOURS=1
      - BACKFILL_HOURS=24
    restart: unless-stopped

What it does:

• Fetches missing replies to posts in your timeline
• Completes conversation threads automatically
• Backfills content from instances your server hasn't seen yet
• Minimal resource usage (3-4MB RAM)

Monitoring and Observability

# Prometheus metrics (optional but recommended)
services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.console.libraries=/etc/prometheus/console_libraries'

# prometheus.yml
scrape_configs:
  - job_name: 'gotosocial'
    static_configs:
      - targets: ['gotosocial:8080']
    metrics_path: '/metrics'

Key metrics to monitor:

• Memory usage trends
• Database growth rate
• Federation success rates
• API response times
• Storage utilization

Migration Gotchas and Pro Tips

Things I Wish I'd Known Before Starting

1. Test Federation Early

# Verify federation is working before migrating followers
curl -H "Accept: application/activity+json" \
  https://your-domain.com/users/your_username

# Should return ActivityPub JSON, not HTML

2. Mobile App Testing is Critical
Don't assume your favorite Mastodon app will work perfectly. Test extensively with your actual usage patterns before committing.

3. Content Discovery Takes Time
The federated timeline won't be instantly populated. Plan for a “quiet period” of 1-2 weeks while content discovery tools build up your federation network.

4. Backup Before Migration

# Create a complete Mastodon backup before starting
docker compose exec web rake mastodon:backup:create
# This creates a full export in /app/backup/

5. Domain Considerations
If you're changing domains during migration (like I did), be prepared for some federation hiccups. Some instances cache domain information aggressively.

Performance Tuning Tips

# PostgreSQL optimization for GoToSocial
# Add to postgres container environment:
POSTGRES_INITDB_ARGS: "--data-checksums"
# In postgresql.conf:
shared_buffers = 128MB          # For 1GB RAM systems
effective_cache_size = 512MB    # 3/4 of available RAM
work_mem = 4MB                  # Per query operation
maintenance_work_mem = 64MB     # For maintenance operations

# GoToSocial-specific optimizations:
# In your .env file:
GTS_CACHE_MEMORY_TARGET=100MB           # Adjust based on available RAM
GTS_MEDIA_REMOTE_CACHE_DAYS=7           # Balance storage vs. availability
GTS_ACCOUNTS_ALLOW_CUSTOM_CSS=false     # Disable if not needed
GTS_WEB_ASSET_BASE_DIR=/gotosocial/web  # Serve assets efficiently

Community Impact and Future Plans

What This Migration Means for the Fediverse

Resource Democracy: By proving that high-quality Fediverse instances can run on minimal resources, we're making decentralization more accessible to everyone.

Tool Ecosystem: The tools developed for this migration (especially GTS-HolMirDas) are helping other small instance operators solve the same content discovery challenges.

Documentation: This migration provides a real-world data point for others considering similar moves.

Future Development Plans

GTS-HolMirDas Roadmap:

• Web-based configuration interface
• Better RSS feed quality scoring
• Integration with more Fediverse platforms (PeerTube, Funkwhale)
• Machine learning-based content relevance filtering
• Multi-instance support for hosting providers

Community Feedback Integration: Based on initial user feedback, the most requested features are:

• Easier RSS feed discovery and management
• Better content filtering options
• Integration with existing relay networks
• Automated instance health monitoring

Bottom Line: The Numbers Don't Lie

Migration Summary:

• Timeline: 4 weeks of testing, 2 days for full migration
• Resource savings: 92% RAM reduction, 65% storage reduction
• Follower retention: 88% (better than expected)
• Federation growth: 2,750+ instances in first week
• Operational complexity: Significantly reduced
• Cost savings: $180-360 annually in hosting costs
• Satisfaction level: 9.5/10 (would migrate again)

The Real Kicker: GoToSocial doesn't just match Mastodon's functionality at lower resource usage – in many ways, it performs better. The federated timeline is more relevant, the interface is faster, and the operational overhead is practically non-existent.

You should definitely consider GoToSocial if:

• You're running a single-user or small instance
• Resource efficiency matters to you
• You value operational simplicity
• You're comfortable with slightly less mature tooling
• You want to contribute to Fediverse diversity

Stick with Mastodon if:

• You're running a large community (100+ users)
• You need enterprise-grade admin tools
• Your users depend on specific Mastodon features
• You have abundant server resources
• Stability trumps efficiency for your use case

My recommendation: Set up a test GoToSocial instance and run it parallel to your existing setup for a month. The resource cost is minimal, and you'll get real-world data for your specific use case.

The Fediverse is strongest when it's diverse – different platforms solving different problems for different communities. GoToSocial has earned its place in that ecosystem.

Resources and Links

Essential Tools

• GoToSocial:https://gotosocial.org
• GTS-HolMirDas:https://git.klein.ruhr/matthias/gts-holmirdas
• FediFetcher:https://blog.thms.uk/fedifetcher
• Slurp (Post Migration):https://github.com/VyrCossont/slurp

Mobile Apps That Work Well

• iOS Tusker: App Store (paid, highly recommended)
• iOS Ice Cubes: App Store (free, some quirks)
• Android Fedilab: F-Droid/Play Store (best Android option)
• Android Tusky: F-Droid/Play Store (decent alternative)

Web Clients (Self-Hosted)

• Phanpy:https://github.com/cheeaun/phanpy
• Elk:https://github.com/elk-zone/elk

Community

• GoToSocial Documentation:https://docs.gotosocial.org
• Matrix Support: #gotosocial:superseriousbusiness.org
• GitHub Issues:https://github.com/superseriousbusiness/gotosocial

Questions? Feedback? Find me on the Fediverse at @matthias@me.klein.ruhr – I'm always happy to discuss self-hosting, the Fediverse, and efficient technology solutions!

If this post helped you with your own migration, consider starring the GTS-HolMirDas repository or contributing to the GoToSocial project. The Fediverse grows stronger with every successful self-hosted instance.

That's why I rely on OpenPGP – not because I have anything to hide, but because I value the fundamental right to private communication. It's one of the most robust encryption standards available, protecting digital conversations for over three decades.

OpenPGP: More Than Just Encryption

OpenPGP operates on a beautifully simple concept. Imagine you have a special lockbox that only you can open. You can give copies of the lock to anyone, but the key stays with you. When someone wants to send you a secret message, they lock it with your lock and send it. Only your key can open it.

This is essentially how OpenPGP works, but with mathematical precision. You generate two mathematically linked keys: a public key you share freely, and a private key that stays securely with you. The mathematics is so solid that even powerful computers would need centuries to break properly implemented encryption.

Beyond hiding messages, OpenPGP also lets you sign them, creating a digital fingerprint that proves authenticity and prevents tampering. Think of it as an impossible-to-forge tamper-evident seal.

🎯 Try It Yourself

Want to see how OpenPGP encryption works in practice?

→ Interactive OpenPGP Demo

Experience the complete encryption workflow: write a message, encrypt it with a public key, and decrypt it with the private key.

Why I Choose OpenPGP Over Other Solutions

The digital landscape is full of encrypted messaging apps, so why OpenPGP? The answer is control and longevity. Most encrypted services are controlled by companies that could change policies, be acquired, or shut down. With OpenPGP, I own my keys and control my encryption. No company can revoke my ability to communicate securely.

OpenPGP has proven its resilience over decades of scrutiny by security experts. This isn't trendy new encryption with potential undiscovered flaws – it's battle-tested technology protecting everything from personal emails to classified communications.

When OpenPGP Makes a Real Difference

Recently, I collaborated on a sensitive project involving technical specifications. Using regular email would have meant this information could be accessed by anyone with administrative access to email servers. With OpenPGP, only my intended recipients could read the details.

I've also helped friends protect personal information during legal matters or medical communications. When sending documents containing social security numbers or financial details, that extra protection becomes crucial. For journalists and activists protecting sources, OpenPGP isn't just about privacy – it's about safety.

Getting Started: The Practical Side

Modern tools have made OpenPGP much more approachable. Windows users can use Gpg4win with its user-friendly Kleopatra interface. Mac users have GPG Suite, which integrates with the built-in Mail app. Linux users often find GnuPG already installed.

The key generation process is straightforward: provide your name and email, choose settings (defaults work fine), and create a strong passphrase. This passphrase protects your private key if someone gains computer access.

Mobile support has improved significantly. Android users have OpenKeychain, which integrates with various apps. iOS is more challenging due to platform restrictions, but ProtonMail provides encrypted email with built-in OpenPGP support.

Essential Key Management

Think of your private key as the master key to your digital identity. Create a revocation certificate immediately after generating keys – this tells the world to stop trusting your key if it's compromised. Store this certificate securely offline.

Back up your keys in multiple secure locations, including offline storage. Set keys to expire after reasonable periods, forcing active renewal as good security practice. Share your public key via key servers but always verify fingerprints through separate channels like phone calls to prevent man-in-the-middle attacks.

Building Good Security Habits & Taking Control

OpenPGP is part of a larger security puzzle. Use strong, unique passphrases and consider hardware security keys for additional protection. Keep software updated and be careful entering passphrases on public computers or unsecured networks.

Device security matters too: full-disk encryption, antivirus software, and firewalls protect where your keys are stored. Privacy isn't about hiding something – it's about controlling your personal information in a world of data breaches and expanding surveillance.

Taking the First Step

Start small: generate a key pair, share your public key with a trusted colleague, and try exchanging encrypted messages. The learning curve isn't steep, and the peace of mind is worth the effort.

Privacy is a practice, not a product. OpenPGP provides the tools, but developing good security habits is ongoing. Your communications are worth protecting – OpenPGP is ready to protect yours too.

Useful Resources

• OpenPGP Official Site: openpgp.org
• Email Security Guide: EFF's Surveillance Self-Defense
• Key Management Best Practices: Riseup's OpenPGP Guide
• Academic Research: The PGP Paradigm

💨 Common Issues with mailx

• Different implementations across distros (BSD vs. Heirloom vs. GNU)
• Inconsistent or broken attachment support via -a
• Poor handling of UTF-8 content
• No built-in HTML mail support

• Lack of clear error messages or logs

  ✅ A Better Way: Using mutt

mutt is primarily a full-featured email client, but it also works reliably in scripts. Here's why it's a great choice:

• Reliable attachment support using -a
• Handles UTF-8 and HTML content without hacks
• Consistent behavior across environments

• Easy to debug with verbose logging if needed

  🛠️ Example: Send HTML Mail with Markdown Attachment

mutt -e "set from=watchdog@example.com" \
     -s "📦 LXC Docker Update Report" \
     -a "/path/to/attachment.md" -- admin@example.com \
     < /path/to/email-body.html

⚙️ Setting up msmtp as SMTP Relay for mutt

To send mail, mutt needs a mail transport agent. msmtp is a lightweight and easy-to-use solution:

# ~/.msmtprc
defaults
auth           on
tls            on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile        ~/.msmtp.log

account        default
host           mail.example.com
port           465
from           watchdog@example.com
user           watchdog@example.com
passwordeval   "gpg --quiet --for-your-eyes-only --no-tty --decrypt ~/.msmtp-password.gpg"

Make sure the config file is secure:

chmod 600 ~/.msmtprc

And configure mutt to use msmtp:

# ~/.muttrc
set sendmail="/usr/bin/msmtp"
set use_from=yes
set realname="LXC Docker Watchdog"
set from="watchdog@example.com"

📋 Summary

If you care about sending reliable emails from scripts – especially with attachments or HTML formatting – then mutt is your friend. Once set up with msmtp, it just works.

No more weird encodings, no more broken attachments, no more surprises.

Just clean, structured, script-friendly email.

These year-end and New Year lists of standard apps used by bloggers feel like a modern take on that tradition, as they pop up across the web. While I wasn’t directly invited to join the conversation this time, I decided to jump in after seeing Oliver’s take on the topic, which caught my interest. – 📨 Mail Service: self-hosted Mailcow – 📮 Mail Client: Thunderbird (macOS), Apple Mail (iOS), SOGo (Web) – 📝 Notizen: Obsidian – ✅ To-Do: Obsidian – 🌅 Fotoarchiv: iCloud Photos / Immich (self-hosted) – 📆 Kalender: Apple Calendar – 📁 Cloud-Speicher: Nextcloud – 📖 RSS-Dienst: FreshRSS (self-hosted) – 🙍🏻‍♂️ Kontakte: Apple Contacts – 🌐 Browser: Safari / Brave – 💬 Chat: preferred Signal & Messages (also Threema & WhatsApp 😔) – 🛒 Einkaufslisten: Apple Reminders & Obsidian – 🔎 Suche: Whoogle (self-hosted) – 📚 Lesen: Kindle Paperwhite & Apple Books – 📰 Nachrichten: Reeder Classic – 🎵 Musik: Apple Music – 🎤 Podcasts: Apple Podcasts – 🌤️ Wetter: Apple Weather – 🔐 Passwortverwaltung: Bitwarden (self-hosted) – 🧮 Code-Editor: CotEditor

Inspired by Oliver, I’ve decided to make this list an annual tradition and plan to publish it regularly at the turn of the year. To ensure I don’t forget, I’ve already set a calendar reminder – because let’s be honest, without it, there’s almost no chance this would happen again. 🤪

The idea for this type of article originally came from Robb Knights, who continues to lead the “App Defaults” project. He curates and collects RSS feeds from people across the web, sharing which default apps and services they rely on.

If you enjoyed this article, why not join in? The concept practically begs for participation. 😉

Why Use an Internal Domain?

A domain accessible only within the internal network can be incredibly useful when you host multiple services within your home lab. Not only does it provide a clean organization, but it also offers additional security since the services are not directly accessible from outside. In this article, I’ll show you how to set up an internal domain using an additional Nginx Proxy Manager (NPM) and an AdGuard Home Server within your home lab to structure and secure your self-hosted services.

I wanted to replace my internal root CA with an accepted Let's Encrypt wildcard certificate, so I treated myself to an additional domain for internal use only. Like my external domain ‘klein.ruhr’, this is hosted by netcup and I use the Cloudflare.com name servers (only the pure DNS name servers, no additional services).

Step-by-Step Guide

1. Configuring the Second NPM

1. Install Nginx Proxy Manager. Here’s a simple example of a compose.yml file:

services:
  npm:
    image: jc21/nginx-proxy-manager
    ports:
      - 80:80
      - 443:443
      - 81:81 # Port 81 is for the NPM admin interface
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    restart: always

2. Restrict access to internal networks:

• Ensure the NPM is only accessible from internal IPs, e.g., using firewall rules or container network settings.

2. Obtaining SSL Certificates with Let’s Encrypt

1. In the NPM interface, navigate to SSL-Certificates, select “Add SSL Certificate” in the upper right corner.

2. Mark “Use a DNS Challenge” and fill in the DNS Challenge information provided by your DNS provider.

• In the case of Cloudflare, log in to your Cloudflare Dashboard.
• Go to My Profile → API Tokens and click Create Token.
• Use the Edit Zone DNS template and configure it as follows:
  • Zone Resources: Limit access to the specific domain (e.g., domain.example).
  • Permissions: Set Zone → DNS → Edit.
• Save the token and keep it in a secure location.

3. Verify that the certificate is issued successfully.

3. Setting up the correct routing with AdGuard Home

1. Install AdGuard Home if not done so far (e.g., via Docker Compose). Here’s a simple example of a compose.yml file:

services:
  adguardhome:
    image: adguard/adguardhome
    ports:
      - '6060:6060/tcp'
      - '5443:5443/udp'
      - '5443:5443/tcp'
      - '853:853/udp'
      - '853:853/tcp'
      - '3000:3000/tcp' # Port 81 is for the AdGuardHome admin interface
      - '443:443/udp'
      - '443:443/tcp'
      - '80:80/tcp'
      - '68:68/udp'
      - '67:67/udp'
      - '53:53/udp'
      - '53:53/tcp'
    volumes:
      - ./conf:/opt/adguardhome/conf
      - ./work:/opt/adguardhome/work
    restart: unless-stopped
    container_name: adguardhome

2. Open your AdGuard Home, navigate to “Filters”, select “DNS rewrites”:

3. add a simple DNS rewrite rule (adapt to your domain and IP address):

4. Connecting Subdomains to Services

1. Create an entry in NPM for each service:

• Subdomain: service1.domain.example.
• Target: Internal service, e.g., http://192.168.x.y:port.
• Test to ensure the routing works correctly.

5. TroubleshootingIf issues arise, the following steps can help:

1. DNS Errors:

• Ensure the DNS rewrite is correctly configured:
  • run dig service1.domain.example or nslookup service1.domain.example to verify the IP.
• If the rewrite doesn’t work, check your AdGuard Home configuration.

2. SSL Certificate Issues:

• Verify that the DNS Challenge completed successfully:
• In NPM: Go to Logs → SSL Certificates and check for errors.
• Common cause: Incorrect API token or DNS entries.

3. Access Problems:

• Ensure firewall rules and network settings are correct.
• Check if the container is running and ports are open:

docker ps
netstat -tuln | grep 81

4. Routing Issues:

• Test the internal service directly via its IP and port to confirm it’s reachable.
• Check the forwarding in the NPM logs:
• NPM Interface > Logs > Proxy Hosts.

Conclusion

By setting up an internal domain, you ensure a more secure and efficient organization of your self-hosted services. This approach not only simplifies internal access but also integrates trusted SSL certificates, making it easier to maintain a professional and secure environment.

At the center of the conflict is the hosting provider WP Engine, which Mullenweg accused of benefiting from the open-source nature of WordPress without contributing enough back to the project. This dispute escalated when Mullenweg demanded substantial financial compensation and threatened drastic measures. As a result, a significant portion of the workforce at Mullenweg’s company Automattic left the company.

This development, along with the increasing commercialization of WordPress, led me to switch to Ghost. Ghost offers a powerful, streamlined, and privacy-friendly alternative, focusing on what really matters: publishing content. Advantages of Ghost over WordPress:

• Performance: Ghost is built from the ground up with speed in mind. While WordPress can become sluggish due to many plugins and complex themes, Ghost remains fast even with larger content volumes.
• Content-focused: Ghost provides exactly what you need as a content creator, without unnecessary features. If your main focus is publishing articles and you don’t need extensive functionality, Ghost is the ideal choice.
• GDPR compliance: Ghost is inherently more privacy-friendly than WordPress, which often requires additional plugins and adjustments to meet GDPR requirements. Especially in a self-hosted setup, Ghost gives you full control over your data.
• Low maintenance: Without the burden of numerous plugins, which typically cause compatibility issues with WordPress, Ghost is easier to maintain. Updates usually run smoothly, and you face fewer technical conflicts.

1. Installing and Setting up Ghost

Installing Ghost via Docker-Compose gives you full control over your environment. While the process requires some technical knowledge, it rewards you with flexibility and easier management of your installation.

Requirements

• A server or VM with shell access
• Docker and Docker Compose installed
• Access to your domain’s DNS settings

Step-by-Step Guide

• Install Docker and Docker Compose: First, ensure that Docker and Docker Compose are installed on your server. Update your system and then run the installation:

sudo apt update && sudo apt upgrade -y
sudo apt install docker docker-compose -y

• Create the Docker-Compose file: Next, create a docker-compose.yml file to define the configuration for Ghost and the MySQL database. Add the following:

services:
  ghost:
    image: ghost:latest
    ports:
      - "2368:2368"
    volumes:
      - ./ghost_content:/var/lib/ghost/content
    environment:
      url: http://your-domain.com
  db:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: yourpassword
      MYSQL_DATABASE: ghost
      MYSQL_USER: ghost
      MYSQL_PASSWORD: yourpassword

• Start the containers: Launch the containers using Docker Compose to set up Ghost and the database:

docker compose up -d

• Set up domain and SSL: Point your domain to the server and enable SSL, for example, using Let's Encrypt to secure the connection.
• Access the Ghost Dashboard: After Ghost is successfully installed and running, you can access the admin dashboard at http://your-domain.com/ghost to complete the setup and begin configuring your site.

2. Differences in Using Ghost vs. WordPress

Using Ghost differs in several key aspects from WordPress. While WordPress can feel bloated due to its many features and plugins, Ghost adopts a minimalist approach, focusing on creating and publishing content.

User Interface

Ghost offers a clean, minimalist interface that allows you to focus on writing. In contrast, WordPress’s interface can feel overwhelming with its additional features. Ghost also provides a live preview of your articles, letting you see how your post will look immediately. WordPress typically requires more clicks to achieve the same result.

Themes and Design Customization

Ghost has a smaller selection of themes, but they are fast and lightweight. Customizations often require basic HTML and CSS knowledge, which appeals to more tech-savvy users. WordPress offers countless themes and page builders like Elementor, but this variety often comes at the cost of performance.

Plugins vs. Integrations

One of the main differences lies in the expandability of the two systems. WordPress has a massive plugin ecosystem that covers nearly every function, but this often leads to security and performance issues. Ghost, on the other hand, relies on integrations with services like Zapier, Stripe, or Mailchimp, keeping the core system lean and stable.

3. Content Management in Ghost

Ghost offers a focused and fast content management system optimized for publishing articles and blog posts. Unlike WordPress, which provides many customization options and features, Ghost simplifies the content creation process.

Creating Content

Ghost uses a Markdown-based editor, which allows you to write content in a clean, structured way. The live preview shows you how your post will look in real-time. In comparison, WordPress uses the block-based Gutenberg editor, which is more flexible but can slow down your workflow.

Categories and Tags

While WordPress supports complex taxonomies such as categories, tags, and custom taxonomies, Ghost keeps it simple by only offering tags. This reduces complexity but is still sufficient for most content creators to organize their content.

Media Embedding

In Ghost, media is embedded directly in the editor without a central media library like WordPress. This makes the workflow straightforward, though WordPress offers more flexibility for managing large media collections.

4. Plugins vs. Integrations

A key difference between WordPress and Ghost is how each system extends its functionality. WordPress’s extensive plugin ecosystem provides maximum flexibility, but this comes with risks: security vulnerabilities, performance issues, and plugin conflicts are common.

Ghost, by contrast, focuses on native integrations, keeping the core system lightweight and fast. Rather than relying on plugins, you can integrate Ghost with services like Zapier, Stripe, and Mailchimp for advanced functionality without compromising stability.

Common Ghost Integrations:

• Zapier: Automate workflows and connect Ghost to over 1,000 services.
• Stripe: Monetize your content with subscriptions and payments.
• Mailchimp: Integrate your newsletter and stay connected with your readers.
• Google Analytics: Track your page views without additional plugins.

5. SEO and Performance

For many site owners, search engine optimization (SEO) is crucial. Ghost provides many SEO features out of the box, whereas WordPress often relies on additional plugins like Yoast SEO.

WordPress: Flexibility through Plugins

WordPress users can install plugins like Yoast or RankMath for detailed control over meta tags, sitemaps, and more. These plugins offer a high degree of flexibility but can negatively impact performance and require regular maintenance.

Ghost: SEO out of the box

Ghost takes a minimalist approach, with many essential SEO features built-in. Automatically generated sitemaps, clean URLs, and meta tag management directly in the editor ensure a solid SEO foundation without the need for plugins. Additionally, Ghost supports native AMP (Accelerated Mobile Pages), improving load times on mobile devices and positively impacting search rankings.

Performance Advantages of Ghost

Because Ghost relies on clean code and minimal dependencies, it often loads much faster than WordPress, which can be slowed down by plugins and complex themes. Search engines like Google consider load speeds when ranking sites, giving Ghost an additional advantage in SEO optimization.

6. Conclusion

Switching from WordPress to Ghost depends heavily on your priorities. WordPress undoubtedly offers more flexibility with a vast array of plugins that cover almost every feature. However, this variety also brings challenges in terms of maintenance, performance, and privacy.

Ghost is ideal for those seeking a lean, fast, and privacy-friendly solution. It focuses on the essentials: creating and publishing content. With built-in SEO features, native integrations, and a simple, user-friendly interface, Ghost is especially suited for content creators who value speed and simplicity.

Ultimately, Ghost is an excellent alternative for those who prefer a minimalist and efficient CMS, while WordPress remains a solid choice for larger, more complex projects. Your decision should depend on whether you need a flexible platform with many extension options or a focused solution that offers better performance and less maintenance.

Requirements and Setup

Before you begin, make sure that Docker and Docker-Compose are installed on your server.

Docker-Compose Setup for Ghost

Here’s a simple docker-compose.yml file with the database and mail configurations already included:

services:
  ghost:
    image: ghost:latest
    container_name: ghost
    environment:
      url=https://your-domain.com
      database__client: mysql
      database__connection__host: ghost-db
      database__connection__user: ghost
      database__connection__password: "replace_with_secure_password"
      database__connection__database: ghost
      mail__from: "your.domain "
      mail__transport: "SMTP"
      mail__options__host: "mail.your.domain"
      mail__options__port: "465"
      mail__options__secureConnection: "true"
      mail__options__auth__user: "auth_user@your.domain"
      mail__options__auth__pass: "your_smtp_password"
    volumes:
      - ./ghost_data:/var/lib/ghost/content
    ports:
      - "2368:2368"
    restart: always
  db:
    image: mysql:latest
    container_name: ghost_db
    environment:
      MYSQL_ROOT_PASSWORD: replace_with_secure_password
      MYSQL_DATABASE: ghost
    volumes:
      - ./ghost_db:/var/lib/mysql
    restart: always

This is your starting point, but there are additional steps required for full GDPR compliance, particularly around data storage and user tracking.

GDPR Compliance: Key Requirements for Operating Ghost CMS

To ensure your Ghost CMS setup complies with the GDPR, make sure you follow these key guidelines:

• Data Storage: Any personal data (e.g., comments, newsletter sign-ups, contact forms) must be collected and processed only with explicit user consent.
• SSL Encryption: A secure, encrypted connection (SSL) is crucial to protect your users' data from unauthorized access.
• Disable jsdelivr CDN: Instead of relying on the jsdelivr CDN, host all necessary files locally to maintain control over data transfers.
• Tracking & Analytics: Any third-party tracking should be fully transparent and require user consent. Consider using privacy-friendly alternatives to Google Analytics, or ensure correct implementation (such as anonymizing IP addresses).
• Cookie Banner: If your site uses cookies, a clear notification that requires active user consent is mandatory.

SSL Encryption

I run all my services behind a proxy (Zoraxy), which handles SSL certificates via a wildcard certificate. Make sure to adjust this based on your own setup.

Disabling jsdelivr CDN

Identify the affected files

In a typical Ghost installation using jsdelivr, the following files are loaded externally:

• sodo-search.min.js: JavaScript for the search function (depending on your theme)
• sodo-search.main.css: CSS for the search function
• portal.min.js: JavaScript for member and subscription functionality (Ghost Portal)

Download files locally

The first step is to download these files from jsdelivr and host them locally on your server. You can do this by visiting the respective jsdelivr URLs in your browser and downloading the files:

• sodo-search.min.js
• sodo-search.main.css
• portal.min.js

Save these files in a directory within Ghost, such as /content/files/js for the JavaScript files and /content/files/css for the CSS files.

Modify docker-compose.yml

Now, add the following three lines to the environment section of your docker-compose.yml:

      sodoSearch__url: "/content/files/js/sodo-search.min.js"
      sodoSearch__styles: "/content/files/css/sodo-search.main.css"
      portal__url: "/content/files/js/portal.min.js"

Privacy Policy and Cookie Banner

• Privacy Policy: Ensure that your privacy policy covers all relevant points, including user data storage, tracking, and disclosure to third parties.
• Cookie Banner: Use an open-source tool like CookieConsent to get user consent for cookies.

GDPR-Friendly Analytics Tools

While Google Analytics is widely used, it can be problematic from a data protection perspective. Luckily, there are alternatives like Umami, which is more privacy-friendly since it can be self-hosted and configured to anonymize users' IP addresses.

Conclusion

Ghost CMS is a great platform for self-hosting, but making it GDPR-compliant requires a few extra steps. With the right configuration, SSL encryption, a clear cookie banner, and privacy-friendly analytics tools, you’re well on your way to running a fully GDPR-compliant Ghost site.

Tip: If you installed Ghost manually, you can find a German website here that describes the process for this type of installation.

At work, I’m required to use Windows 11 – sometimes necessity dictates our tools. However, in my personal life, I gravitate toward macOS and always keep at least one Linux system running. My go-to distribution is usually #Debian-based, and right now, it’s Linux Mint.

Since macOS is my primary operating system for personal use, this article will focus heavily on the software I use on macOS. Don’t worry if you’re not a Mac user – I rely on open-source software wherever possible, so many of these tools are available across multiple platforms.

Here’s a rundown of the apps and software that keep my digital life organized and efficient:

On My MacBook:

Web Browsers:

• Mozilla Firefox: My preferred browser on all operating systems for its flexibility and privacy features.
• Safari: A reliable alternative when I need a change or for specific tasks – it’s always good to have a backup.

Email Clients:

• Thunderbird: My go-to email client, thanks to its versatility and robust features

VPN:

• WireGuard: I self-host my own instance, making this lightweight and fast VPN my security partner.

Cloud Solution:

• Nextcloud: More than just cloud storage, it’s an all-in-one tool that I self-host for privacy and control.

Office Software:

• LibreOffice: A powerful and free open-source office suite that meets all my document needs.

Password Manager:

• Bitwarden: I self-host my own Vaultwarden instance to manage passwords securely across all devices.

Editor:

• cotEditor: A lightweight plain-text editor that’s perfect for quick edits on macOS.

File Transfer Client:

• Cyberduck: A free, open-source file transfer client that supports a wide range of protocols, making file transfers a breeze.
• Filezilla: FileZilla Client is a fast and reliable cross-platform FTP, FTPS and SFTP client with lots of useful features and an intuitive graphical user interface.

Image Editing:

• GIMP: My open-source tool of choice for image editing, available on almost any operating system.
• Pixelmator Pro: For when I need a more Mac-native alternative to Photoshop.

Video Transcoding:

• HandBrake: The definitive free and open-source tool for all my video transcoding needs.

Terminal:

• Ghostty: A fast, feature-rich, and cross-platform terminal emulator that uses platform-native UI and GPU acceleration.
• iTerm2: A powerful terminal emulator for macOS that enhances productivity with features like split panes and advanced search.

Tools & Helpers:– ICE: A menu bar management tool that keeps my workspace organized.

• IINA: A modern and versatile media player tailored for macOS.
• RustDesk: A self-hosted, full-featured remote control tool that’s my go-to for remote access.

On My Server:

Operating Systems:

• Debian 12.6 “bookworm”: A stable and reliable foundation for my server environment.
• Ubuntu 24.04 LTS: A long-term support version that powers some of my critical services.

Services:

• For more details on my self-hosted apps, be sure to check out my separate blog post dedicated to that topic.

Why These Tools?

As you can see, my software choices reflect my philosophy of leveraging open-source tools and self-hosting wherever possible. I believe in the power of open-source not just for its flexibility, but also for the control and security it offers. By hosting services on my own infrastructure, I minimize reliance on third-party platforms and keep my data under my own control.

Your Thoughts?

What tools and software do you swear by in your own workflow? I’d love to hear your recommendations or thoughts in the comments below. Stay tuned for more insights on