Migrating Our Dockerized Infrastructure to Alpine Linux on DigitalOcean: Inspired by Lewis Campbell

July 21, 2025 (4mo ago)

Jump to FAQs

Inspired by Lewis Campbell's insightful post on the real costs of dependencies and the value of simplicity, we recently migrated our Docker-based application infrastructure to an Alpine Linux droplet on DigitalOcean. This migration was not just a technical upgrade, but also a step toward a more maintainable, efficient, and resilient system architecture. Here is a detailed walkthrough of our process, the rationale behind our choices, and the lessons we learned along the way.

🔗 Related Infrastructure Guides:


Why Alpine Linux and DigitalOcean?

Our previous environment had grown increasingly complex, weighed down by unnecessary dependencies and resource overhead. Campbell's argument for minimizing dependencies resonated with us: every additional layer can introduce risk, complexity, and maintenance burden. Alpine Linux, with its minimal footprint and security-focused design, offered an ideal foundation for our Docker workloads. DigitalOcean provided reliable, affordable infrastructure that matched our needs for scalability and simplicity.


Why Alpine Linux and DigitalOcean?

Our previous environment had grown increasingly complex, weighed down by unnecessary dependencies and resource overhead. Campbell’s argument for minimizing dependencies resonated with us: every additional layer can introduce risk, complexity, and maintenance burden. Alpine Linux, with its minimal footprint and security-focused design, offered an ideal foundation for our Docker workloads. DigitalOcean provided reliable, affordable infrastructure that matched our needs for scalability and simplicity.

For details on how we created custom Alpine Linux images for DigitalOcean, check out our comprehensive guide on creating and deploying custom Alpine Linux images on DigitalOcean.


Planning the Migration

The migration began with a thorough audit of our current stack and dependencies. We identified all required services, configurations, and data volumes. Our plan included:


Backing Up and Preparing for Transfer

To ensure a safe transition, we stopped all running containers to avoid data inconsistency:

docker compose down

We then archived our project directory, which included docker-compose.yml, environment files, and persistent volumes:

tar czvf project-backup.tar.gz .

This backup was securely transferred to the new Alpine droplet using scp.


Deploying on Alpine Linux

After extracting our backup on the new server, we installed Docker and Docker Compose:

apk update
apk add docker docker-cli-compose
rc-update add docker default
service docker start

With Docker running, we restored our services:

docker compose up -d

Managing Application Dependencies

For PHP-based services, we needed to regenerate dependencies. We spun up a temporary PHP container with the project directory mounted and ran composer install to rebuild the vendor directory, ensuring all dependencies were correctly installed for the new environment.


Networking and Security Configuration

Tailscale was configured for secure access, with special attention to Alpine’s use of OpenRC instead of systemd. We wrote an idempotent setup script to guarantee Tailscale would start on every boot. Firewall rules were reviewed on both the OS and DigitalOcean’s Cloud Firewalls, ensuring ports 80, 81, and 443 were open for HTTP/HTTPS traffic.


Testing and Launch

We conducted thorough testing of each service, leveraging Cloudflare’s Development Mode to bypass cache and verify changes in real time. Once everything passed validation, we updated DNS records and took the new stack live.


Key Takeaways


Conclusion

Migrating to Alpine Linux on DigitalOcean has dramatically improved our infrastructure’s efficiency, security, and maintainability. This project underscored the wisdom of questioning every dependency and striving for simplicity wherever possible—a lesson well-illustrated by Lewis Campbell’s original blog post.

If you’re considering a similar migration or want to discuss infrastructure best practices, feel free to reach out. Happy deploying!

Discuss this post:

Frequently Asked Questions

Why did you choose Alpine Linux over other distributions for your Docker infrastructure?

We chose Alpine Linux because of its minimal footprint and security-focused design, which aligns with Lewis Campbell's philosophy of minimizing dependencies. Alpine reduces complexity, resource overhead, and potential security vulnerabilities while providing an ideal foundation for Docker workloads.

What was the total downtime during the migration process?

The migration was designed to minimize downtime by using Cloudflare's Development Mode and careful planning. The actual downtime was limited to DNS propagation time and the brief period needed to update DNS records after thorough testing was completed on the new environment.

How do you handle Docker and Docker Compose installation on Alpine Linux?

On Alpine Linux, you install Docker using the apk package manager with 'apk add docker docker-cli-compose', then enable it to start on boot with 'rc-update add docker default' and start the service with 'service docker start'. This differs from systemd-based distributions.

What challenges did you face with PHP dependencies during the migration?

We needed to regenerate PHP dependencies for the new environment. We solved this by spinning up a temporary PHP container with the project directory mounted and running 'composer install' to rebuild the vendor directory, ensuring all dependencies were correctly installed for Alpine Linux.

How did you ensure data consistency during the migration?

We stopped all running containers using 'docker compose down' before creating backups to avoid data inconsistency. We then archived the entire project directory including docker-compose.yml, environment files, and persistent volumes using tar, and securely transferred it to the new server.

What's different about service management on Alpine Linux compared to other distributions?

Alpine Linux uses OpenRC instead of systemd for service management. This means you use commands like 'rc-update add' to enable services at boot and 'service start/stop' to control services, rather than systemctl commands used in systemd-based distributions.

How did you handle networking and security during the migration?

We configured Tailscale for secure remote access, writing idempotent setup scripts to ensure it starts on every boot. We also reviewed firewall rules at both the OS level and DigitalOcean's Cloud Firewalls, ensuring ports 80, 81, and 443 were properly configured for HTTP/HTTPS traffic.

What are the main benefits you've experienced since migrating to Alpine Linux?

The migration has dramatically improved our infrastructure's efficiency, security, and maintainability. We've seen reduced resource usage, faster boot times, fewer security vulnerabilities due to the minimal attack surface, and easier maintenance thanks to the simplified dependency chain.

Would you recommend this migration approach for production environments?

Yes, but with careful planning. The key is thorough testing, proper backup strategies, and understanding the differences in service management. The benefits of reduced complexity and improved security make it worthwhile for production environments, especially when running containerized applications.