From FileZilla to Siovos: why I built my own deployment tool

My first deployment was on GitHub Pages. A repo, an automatic DNS at my-repo.github.io, and it was live. Felt like magic. But soon enough, I wanted my own domain name, my own server. Without knowing it, that was the beginning of something.

FileZilla and the first tutorials

I rented my first server. I didn't even know what a VPS was at the time, or how to get my files onto it. I found a step-by-step tutorial on a popular French learning platform - and it used FileZilla. An FTP client with a graphical interface: you drag your files on the left, they show up on the server on the right.

It worked. It was even satisfying. I did it again on several servers, with several projects - most of which never really took off, but in hindsight the process mattered more than the result. Each time, I understood a little more about what was happening under the hood.

WordPress, the one-click promise and reality

Then I discovered WordPress. At the time, people around me needed websites, and WordPress was the promise of a site in one click. And it was true - on hosting platforms, you'd click "Install WordPress", and two minutes later you had a live website. That's how I discovered simplified deployment: by setting up WordPress sites for others.

But I was a developer. I figured I'd have better luck with my online business ideas if I actually coded in WordPress, and I could also do it for clients. So I downloaded the WordPress ZIP locally, started developing in it, and then... the problem came: how do I deploy my code to a server?

That's when I discovered DigitalOcean tutorials, which I followed religiously, step by step. And those tutorials threw me into a world I didn't know yet. I had to navigate the server via SSH, use scp to copy files, configure Apache, create databases, edit files with Vim for the first time. Things that are "simple" for a sysadmin, but were a whole new world for me.

The script that was useless (but changed everything)

After repeating the same commands on every deployment - SSH connection, file copy, Apache restart, cache flush - the reflex came naturally: put everything in a script. Based on the DigitalOcean tutorials, I automated the deployment steps. My script was terrible, really. But at the time, once I had a stable version, I thought I could do great things with it. I didn't realize this habit would eventually become a product.

The problem was that this script wasn't that useful. Better tools already existed - more reliable, with interfaces, and plenty of other advantages. So I shelved the idea of making it into something industrial, and continued on my path as a developer.

The encounters that make you grow

Then I met a developer who had a sysadmin background. A very inspiring person, strong values, straight shooter. I learned a lot from him. Without naming him fully, Remi C. probably had more influence on my technical rigor than he realizes.

Remi wrote incredibly clean code. He cared about details and could tell what was well-built from what wasn't worth the attention. Thanks to his sysadmin background, his shell scripts were carefully structured - color variables in the header, clean step-by-step output in the terminal. That's when I understood that a command-line tool could also have a real UX.

I wanted to pick up my deployment script again. Not with grand ambition, just to redo it better, inspired by what Remi was doing. Learning by redoing.

Docker, the pipeline, and the turning point

Years went by. I picked up Docker, which once again changed the way I developed. At work, I discovered what a professional architecture looked like: GitLab CI for the pipeline, containerized environments, a controlled public-facing zone, and most importantly an internal zone - services accessible only by the team, invisible from the internet.

It was this internal side that led me to Siovos.

I had deployed open source tools for my personal projects, but unlike work, everything was exposed on the web. Strapi, Grafana, admin tools - publicly accessible with a simple login/password. I didn't like that. Anyone can scan and see what you're running. And a door, even a closed one, gives information to anyone looking.

Beyond that, if just one of the tools that had no reason to be publicly exposed had a vulnerability, it multiplied my chances of having a problem. Running tools internally doesn't eliminate risk entirely, but it's a major step up.

The VPN, the shared server, and starting over

That's where my second journey began. How do I add a VPN to my server?

Problem: my server was shared hosting. I didn't know it yet, but it wouldn't let me install and configure the tools I wanted. Only a very limited set was available - enough to put websites online, but not enough to build an enterprise architecture like the one I worked with every day.

So I got a new VPS on Hostinger, and started from scratch. This time, I needed to set up OpenVPN - a solid VPN, but one that turned out to be very complex for me to configure. Network accessibility, port opening and closing - this time, there was no tutorial to follow blindly. I had to really understand what I was doing.

From craft to Siovos

From experience, I understood the value of having a script to iterate. I'd reset the server to a clean Debian, and start again. Installation by installation, sometimes going backwards because a specific order had to be respected, but at least I had a script. The problem was that it had become impossible to maintain.

I figured someone must have industrialized this work before me. I discovered Ansible, which let me think in a more structured way - in modules, in reusable building blocks, with the ability to partially redeploy and do it idempotently. The way I worked changed, and the result was finally professional.

And then the idea came naturally: why not make accessible what had taken me months of iterations to stabilize? Behind every deployment that worked on the first try, there were server resets, fixes, adjustments - over and over again. Build an interface, allow other teams not to redo this journey. That's how Siovos started - not on a business plan, but on a shared frustration.

Today, Siovos Desktop deploys in 15 minutes what used to take me days:

• Kubernetes (K3s) - container orchestration, production-ready
• WireGuard VPN - infrastructure invisible from the internet
• Private DNS - automatic internal resolution
• SSL Certificates - automatic TLS via an internal PKI
• Reverse proxy - Traefik configured with rate limiting and security headers
• CI/CD - GitHub Actions connected to the cluster
• Monitoring - Grafana and Prometheus preconfigured

Everything configured, everything secured, everything accessible via VPN.

It's the tool I wish I had when I was dragging files into FileZilla.

If you're a developer or managing a technical team, and your infrastructure still relies on homemade scripts or manual deployments, this story probably resonates. Siovos Desktop was built exactly for that.

Download Siovos Desktop for free ->