2025-08-17 23:21:01
2025-08-17 23:20:45
2025-08-04 02:17:17
15665182
The complexity was getting out of hand.
Key Configuration Decisions:
2. Post Import with slurp
3. Account Redirect Setup
Migration Casualties:
Federation happens FAST:
My Solution: Intelligent RSS-to-Fediverse Bridge
Smart Features:
RSS Feed Sources
The Result: A vibrant federated timeline despite being a single-user instance, with content that's actually relevant to my interests.
Client Comparison:
Recovery tested and verified – I've successfully restored from backup during my testing phase. The process is straightforward and well-documented.
What it does:
Key metrics to monitor:
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.
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.
GoToSocial - ready for Prime Time?
Short answer: Hell yes.
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 useWhy 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 APIThe 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_dbKey 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.gz2. 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 preserved3. 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 accountMigration 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% reductionWhy 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 qualityMy 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 automaticallyRSS 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 periodsMobile 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 -dFediFetcher 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-stoppedWhat 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 HTML2. 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 efficientlyCommunity 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)
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.
🏡 Linktree | Follow me also on: 
🏡 Linktree | Follow me also on: