Why I Switched from Woodpecker to Drone for Flutter CI/CD

#

As a mobile developer managing multiple Flutter apps, I invested heavily in building a self-hosted CI/CD pipeline to automate deployments to Google Play Store, Apple App Store, and Amazon Appstore. The goal was simple: automate my nightly builds so I could sleep better while my apps get deployed automatically. What started as a promising setup with Woodpecker CI eventually became a source of constant frustration and sleepless nights, leading me to migrate to Drone CI. This is the technical story of that migration and the countless hours I lost troubleshooting issues that were supposed to save me time.

The Initial Promise of Woodpecker CI

#

When I first set up my CI/CD infrastructure, Woodpecker CI seemed like the perfect choice. As a community fork of Drone CI, it promised:

• Open-source transparency with active community development
• Container-native architecture that works well with Docker
• Simple YAML configuration similar to docker-compose
• Multi-platform support including Bitbucket integration
• Lightweight resource usage suitable for my VPS setup

The initial setup was straightforward, and my Flutter apps were building successfully. I configured automated pipelines for:

# .woodpecker.yml example
steps:
  build-android:
    image: cirrusci/flutter:stable
    commands:
      - flutter pub get
      - flutter build apk --release
      - flutter build appbundle --release

  deploy-play-store:
    image: ghcr.io/fastlane/tools:latest
    commands:
      - fastlane deploy_to_play_store
    when:
      branch: main

The Reality: Critical Issues with Woodpecker

#

Webhook Reliability Problems with Bitbucket

#

The first major issue I encountered was missed webhook calls from Bitbucket. My builds would fail to trigger randomly, leaving me wondering if my deployments were actually running. After extensive debugging, I discovered this was a known issue documented in GitHub issue #5642: “Bitbucket webhook fails to trigger build sometimes.”

The symptoms were consistent:

• Push events would sometimes not trigger any build
• Pull request webhooks were frequently missed
• No error messages or logs indicating webhook reception failures
• Manual intervention required to trigger builds

This was particularly problematic for my Flutter deployment pipeline, where I relied on automated nightly builds to deploy to multiple app stores. Missing a webhook meant missed deployments, directly impacting my release schedule.

Memory Issues and Performance Degradation

#

As my Flutter project complexity grew, I began experiencing memory-related panic errors. The Woodpecker server would occasionally crash with out-of-memory errors, even though my VPS had 8GB RAM allocated. Investigation revealed several underlying issues:

1. Memory Leak Issues (GitHub issue #4228): Woodpecker CI exhibited memory leak problems, especially when running on container-based environments
2. Database Performance Bottlenecks: Since version 2.7, the agents table experienced massive load, causing performance degradation
3. Resource Spikes: Flutter builds, which are already memory-intensive, would cause cascading failures across the system

The memory issues were particularly frustrating because they manifested randomly. A build that worked fine one day would fail the next due to memory constraints, requiring manual restarts of the Woodpecker services.

Impact on Flutter App Deployment Pipeline

#

My CI/CD setup was designed to handle the complete Flutter deployment workflow:

1. Automated Flutter builds for both Android (AAB/APK) and iOS (IPA)
2. Code signing and certificate management for App Store deployments
3. Multi-platform distribution to Google Play, Apple App Store, and Amazon Appstore
4. Nightly builds with automated testing and deployment

However, with Woodpecker’s unreliability, I found myself:

• Losing countless hours sitting at my desk waiting for builds that never triggered
• Missing sleep while manually checking if deployments happened throughout the night
• Manually triggering builds when webhooks were missed, often at 2 AM
• Restarting services when memory issues occurred, sometimes multiple times per night
• Manually deploying to multiple stores - a process that takes hours when done for multiple apps

The irony was brutal: Woodpecker was supposed to save my sleep by handling deployments that happen at night. Instead, it destroyed my sleep. Deploying multiple Flutter apps to Google Play Store, Apple App Store, and Amazon Appstore manually can take hours - especially when you have to coordinate releases across different time zones and handle various store-specific requirements.

With Woodpecker, I had to sit and wait, constantly checking if anything went wrong. The automation I built included Google Chat notifications to clients when deployments completed successfully. But with Woodpecker’s unreliability, those notifications became meaningless because I couldn’t trust the underlying deployment process.

This defeated the entire purpose of having an automated CI/CD pipeline. Instead of “set it and forget it,” I had “set it and babysit it” - all night long.

The Migration to Drone CI

#

After months of frustration with Woodpecker, I decided to evaluate Drone CI as an alternative. The decision was influenced by several technical factors:

Drone’s Superior Architecture

#

Drone CI, despite being the original project that Woodpecker forked from, offered several advantages:

1. Mature Codebase: Longer development history with more battle-tested stability
2. Better Container Isolation: Improved resource management and security boundaries
3. Superior Webhook Handling: More reliable webhook processing with better timeout management
4. Production-Grade Reliability: Designed for enterprise environments with higher uptime requirements

Bitbucket Integration Excellence

#

Drone’s Bitbucket Cloud integration proved to be significantly more reliable:

• Dedicated Provider Support: Official Bitbucket Cloud provider with comprehensive documentation
• Robust Webhook Processing: Better error handling and retry mechanisms
• Consistent Event Triggers: Reliable build triggering for all repository events
• Enhanced Logging: Detailed webhook logs for debugging integration issues

Resource Management Improvements

#

Drone’s container-native architecture provided better resource utilization:

• Efficient Memory Usage: No memory leaks or resource spikes
• Predictable Performance: Consistent build times regardless of concurrent workloads
• Better Scalability: Ability to handle multiple Flutter builds without system degradation

The Migration Process

#

Pipeline Configuration Conversion

#

Converting from Woodpecker to Drone was straightforward since Drone’s YAML format is a superset of Woodpecker’s. Here’s a comparison:

Woodpecker Configuration:

steps:
  build-flutter:
    image: cirrusci/flutter:stable
    commands:
      - flutter pub get
      - flutter test
      - flutter build appbundle --release
    when:
      branch: main

Drone Configuration:

kind: pipeline
type: docker
name: flutter-deployment

steps:
  - name: build-flutter
    image: cirrusci/flutter:stable
    commands:
      - flutter pub get
      - flutter test
      - flutter build appbundle --release
    when:
      branch:
        - main

  - name: deploy-play-store
    image: ghcr.io/fastlane/tools:latest
    commands:
      - fastlane deploy_to_play_store
    depends_on:
      - build-flutter
    when:
      branch:
        - main

Setup and Configuration

#

The Drone setup process involved:

1. Installing Drone Server: Docker-based installation with SQLite backend (simple and lightweight)
2. Configuring Bitbucket OAuth: Setting up Bitbucket Cloud integration with proper webhook configuration
3. Migrating Build Secrets: Transferring sensitive data like API keys and certificates
4. Updating DNS and SSL: Pointing my CI domain to the new Drone instance
5. Testing Pipeline Validation: Running sample builds to ensure everything worked correctly

Results and Benefits

#

Immediate Improvements

#

The switch to Drone provided immediate benefits that directly addressed my pain points:

1. 100% Webhook Reliability: No more missed build triggers from Bitbucket - every single push now triggers a build
2. Stable Resource Usage: Consistent memory utilization without leaks or spikes - no more 2 AM service restarts
3. Better Build Performance: Faster build times due to improved resource management
4. Finally Getting Sleep: Reliable automated deployments that work consistently without my intervention
5. Trust in Notifications: Google Chat notifications to clients now mean something because the underlying process is reliable

Long-term Benefits

#

Over several months of using Drone for Flutter CI/CD:

• Zero Sleepless Nights: No more waking up to check if deployments happened
• Consistent Deployments: Every push to main branch successfully deploys to app stores
• Time Saved: Regained countless hours that were spent manually troubleshooting and deploying
• Better Monitoring: Enhanced logging and monitoring capabilities
• Scalability: Ability to add more Flutter projects without performance degradation
• Client Confidence: Reliable delivery timeline and notifications they can trust

Technical Recommendations for Flutter CI/CD

#

Based on my experience, here are my recommendations for setting up reliable Flutter CI/CD:

Infrastructure Planning

#

1. Allocate Adequate Resources: Flutter builds require significant memory (4GB+ recommended)
2. Use SSD Storage: Faster I/O operations improve build times
3. Network Reliability: Ensure stable internet connectivity for dependency downloads
4. Backup Strategy: Regular backups of CI/CD configuration and build artifacts

Pipeline Best Practices

#

1. Multi-stage Builds: Separate build, test, and deployment stages
2. Artifact Management: Proper storage and versioning of build artifacts
3. Security Considerations: Secure handling of API keys and certificates
4. Dependency Caching: Cache Flutter and Gradle dependencies to speed up builds

Platform Choice Criteria

#

When choosing a CI/CD platform for Flutter mobile development:

1. Webhook Reliability: Critical for automated deployments
2. Resource Management: Efficient memory and CPU utilization
3. Mobile App Support: Native support for Flutter, Android, and iOS build processes
4. Integration Capabilities: Strong integration with app stores and deployment tools

Conclusion

#

The migration from Woodpecker to Drone CI transformed my Flutter deployment pipeline from a source of constant stress to a reliable, automated system. While Woodpecker CI showed promise as an open-source solution, the documented issues with Bitbucket integration and memory management made it unsuitable for production mobile app deployments.

Drone CI provides the stability and reliability needed for automated Flutter app deployments to multiple app stores. The webhook reliability issues that plagued Woodpecker are completely resolved, and the memory management problems are eliminated. Most importantly, I can now sleep better at night knowing that my CI/CD pipeline will work consistently without manual intervention.

For any developer building a serious Flutter CI/CD pipeline, especially one targeting multiple app stores, I strongly recommend considering Drone CI over Woodpecker. The reliability and peace of mind are worth the migration effort.

If you’re setting up a Flutter CI/CD pipeline, the full production stack — Drone, Fastlane, Xcode Cloud, tag-based test builds — is in the complete mobile CI/CD guide. And if you’ve hit similar CI reliability walls, get in touch — happy to share what the migration actually took.