I'm an independent web developer with about eight years of experience, mainly building Svelte, Symfony, Directus, and PostgreSQL projects. I'm comfortable with Docker and run a home server with roughly 50 containers, but I wouldn't consider myself a DevOps specialist.
I've used Heroku and Netlify in the past, then moved my projects to a self-hosted Coolify instance when pricing and platform restrictions became inconvenient. It works very well, but I'm curious whether I could recreate its main features by combining several focused tools. The goal is partly to understand what happens behind the scenes, and partly to avoid depending on one all-in-one platform.
The features I'd like to cover are deployment to multiple VPS endpoints, Docker-based applications, Git-triggered CI/CD, project and environment organization, reverse proxying with automatic HTTPS, application updates, and scheduled PostgreSQL backups to S3-compatible storage.
My initial stack would use Arcane for managing and monitoring Docker hosts, Backrest for backups, SWAG as the reverse proxy, and Ansible to provision fresh servers. I'd also like to use CrowdSec, possibly alongside fail2ban, for abuse prevention and security rules. Builds would produce Docker images whenever a release is made, with the target host then pulling the new image.
Does this architecture leave out any important pieces? Would you personally build and maintain a stack like this for small client projects, or would the convenience of an all-in-one platform outweigh the learning experience and flexibility?
2 Answers
The main pieces you may still need are reliable image building, secrets management, health checks, rollback procedures, centralized logs, monitoring and alerting, and a tested restore process. Backups are only half the job—regularly verify that a database can actually be restored and that the application can start afterward.
Be careful with automatic updates and the Docker image tag latest. Pin versions for client-facing production services and update them deliberately. A small deployment script or CI pipeline can build a tagged image, run migrations in a controlled way, perform a health check, and roll back if the new container fails.
CrowdSec’s log-based protections generally react after a request has reached the proxy. If you need protection before traffic reaches Symfony, consider adding a WAF using ModSecurity-compatible rules. Bot-detection features can still be immature, and challenge-based systems may interfere with APIs or legitimate clients, so test them carefully and exempt trusted automation where appropriate.
Yes, this is a perfectly reasonable project if your main goal is learning. An all-in-one platform is mostly Docker, a reverse proxy, deployment hooks, backup jobs, and the glue that connects them. Rebuilding it yourself will teach you where the operational complexity really lives, but you’ll also become responsible for maintaining that glue whenever something breaks.
I’d put a time limit on the experiment. Try it for a few months, document the setup, and decide in advance what level of friction is unacceptable. If deployment triggers or recovery workflows remain painful, going back to Coolify isn’t a failure—you’ll still have learned how the system works and will be better equipped to troubleshoot it.
For security, I’d avoid running fail2ban and CrowdSec against the same logs unless you have a specific reason. They can end up tracking and enforcing overlapping decisions, which makes troubleshooting harder. Pick one as the primary banning system, and make sure your home IP, automation host, and CI runner are allowlisted so you don’t accidentally block yourself.
That deadline is a good idea. My current reverse-proxy setup runs smoothly, but I’m never completely sure whether that’s because it’s robust or because I haven’t encountered the serious failure mode yet. I’ve kept both security tools because they seem to catch different things in my testing, although I may be creating unnecessary overlap.
That makes sense. I already use CrowdSec and have experimented with its application-security features, but I’m not convinced I configured the WAF portion correctly yet. I’ll also make image tagging, restore testing, and rollback behavior explicit parts of the design instead of treating deployment as only pulling a new container.