{"slug": "i-built-devcommand-and-ended-up-changing-the-way-i-deploy-websites", "title": "I Built DevCommand and Ended Up Changing the Way I Deploy Websites", "summary": "A developer built DevCommand, a command reference tool, and in the process overhauled their deployment workflow to use GitHub Actions for automated deployments to Hostinger, replacing direct file edits. The developer detailed the challenges of setting up SSH, secrets, and rsync, ultimately achieving a green checkmark and confirming files on the server.", "body_md": "I originally set out to solve a much smaller problem.\n\nAs I've spent more time developing websites and applications, I've accumulated a growing list of commands that I use regularly enough to recognize but not always regularly enough to remember. Git, Linux, SSH, npm, Composer, Docker, database management—there is always some command where I remember what I need to do but not the exact syntax to do it. I could search for it every time, dig through old projects, or ask AI, but eventually I started wondering why I hadn't built my own reference.\n\nThat idea became **DevCommand**, which I'm building around a simple concept: **Your developer command companion.**\n\nThe project started as a practical tool for myself, but somewhere between building it and getting it online, it became part of a much larger change in how I'm approaching development.\n\nFor quite a while, Hostinger's File Manager was a normal part of my development process. If I needed to change something on one of my sites, I could log in, find the PHP, CSS, or JavaScript file, edit it, save it, refresh the site, and move on. For the kinds of websites I was building at the time, it worked well enough.\n\nMy projects aren't as simple anymore.\n\nI'm working with React applications, PHP sites, APIs, databases, automation, and projects with increasingly more moving parts. At the same time, I've been using VS Code and Git more heavily in my local development. The disconnect started becoming obvious: I was developing more seriously on my computer, but I was still treating deployment like I had when my projects were much smaller.\n\nEditing a production file directly is fast right up until something goes wrong. There is no commit to roll back to if you haven't created one, and it becomes easy for the copy on your computer, the copy in GitHub, and the copy actually running on the server to drift apart. I didn't want three versions of a project with me trying to remember which one was current.\n\nSo while working on DevCommand, I decided to change that.\n\nI wanted the process to be simple: build locally, track everything with Git, push the finished work to GitHub, and have the production server receive that version automatically.\n\nThe concept was straightforward. Getting it working was not.\n\nGitHub Actions seemed like the obvious bridge between GitHub and Hostinger. My goal was to make a push to the production branch mean something. Instead of pushing code to GitHub and then logging into Hostinger to repeat the deployment manually, that push would trigger the deployment itself.\n\nThis meant setting up SSH access between GitHub and my Hostinger account, creating deployment keys, storing the necessary information in GitHub Secrets, configuring the correct server paths, and using `rsync`\n\nto synchronize the production files.\n\nThis was also where I spent a good amount of time staring at red GitHub Actions runs.\n\nAt one point, the workflow file itself was being flagged with errors claiming required properties like `on`\n\nand `jobs`\n\nwere missing. After getting past that, the Action could run, but the files still weren't reaching the directory where they were supposed to go. Fixing one problem often just exposed the next one.\n\nThat process was frustrating, but it was also useful because I couldn't just click around until something magically worked. Each failure narrowed the problem. Was GitHub reading the workflow? Could the Action authenticate over SSH? Was it reaching the correct server? Was `rsync`\n\npointing at the correct local directory? Was the destination path right?\n\nEventually, the pieces started falling into place. The deployment key authenticated successfully. The repository secrets were correct. The workflow appeared in GitHub Actions and executed properly. `rsync`\n\nreached Hostinger.\n\nThen I pushed another change and watched the workflow finish with a green checkmark.\n\nMore importantly, I checked the server and the files were actually there.\n\nThat was the moment the whole thing clicked.\n\nOnce I had the deployment process working for my other sites, DevCommand presented another challenge. Unlike some of my PHP projects, the files in the repository aren't the files that should simply be copied directly to the web server. DevCommand has to be built first.\n\nThat meant modifying the deployment process so GitHub could take care of the build as well. The workflow checks out the repository, prepares Node.js, installs the dependencies, runs the production build, and then sends the generated `dist`\n\nfiles to Hostinger.\n\nIn practical terms, I can now work on DevCommand locally, test what I'm building, commit the changes, and push them to GitHub. From there, the production build and deployment happen without me manually transferring anything.\n\nThat may be routine for developers who have been working with CI/CD pipelines for years, but actually building the process for my own projects gave me a much better understanding of what is happening between source code and production.\n\nBefore this, I tended to think of deployment mostly as moving updated files onto a server. DevCommand forced me to think about the distinction between the source of an application and the artifact that actually gets deployed. GitHub isn't simply storing a backup of my code anymore; it's now an active part of how that code becomes the production application.\n\nThe biggest result of this project isn't that I no longer have to open Hostinger's File Manager as often. Saving a few clicks isn't particularly interesting. What matters is that my development process finally has a clear source of truth.\n\nThe project on my computer is where I work. Git records what changes. GitHub holds the repository and its history. The deployment workflow determines what reaches production. If something goes wrong later, I have a much clearer trail showing what changed and when.\n\nIt also changes the way I think about commits. A commit isn't just a checkpoint I create because Git expects me to. When a push can ultimately result in a production deployment, being deliberate about what I'm committing becomes much more important.\n\nThere is another benefit that I didn't fully appreciate until I saw the workflow running successfully: I can reuse what I learned.\n\nDevCommand isn't going to be the only project I maintain. I already have several sites, applications, and client projects, and there will be more. I don't want to reinvent deployment every time I build something. Establishing this process gives me a foundation that can be adapted depending on whether a project is a traditional PHP site, a React application that needs to be built, or something more complex later.\n\nThat's probably my favorite part of this entire project.\n\nI sat down to build a tool because I was tired of looking up commands.\n\nInstead, the project pushed me into SSH authentication, deployment keys, GitHub Secrets, YAML configuration, `rsync`\n\n, build artifacts, server paths, and automated deployments. Some of those were things I already understood conceptually, but there is a different level of understanding that comes from having to make all of them work together.\n\nThere were plenty of failed runs along the way, and I don't think hiding those makes the finished project any more impressive. If anything, those failures are the useful part. The green checkmark only meant something because I understood most of what had to happen for it to finally appear.\n\nDevCommand is currently running at **devcommand.johnliter.de**, with **devcommand.app** planned as its eventual home. I have more I want to add to it, and I want it to become a genuinely useful command companion rather than just another static cheat sheet.\n\nBut even in its current state, the project has already done more for me than I originally intended.\n\nI built DevCommand because I wanted a better way to reference the tools I use while developing.\n\nIn the process, I built a better way to ship the things I create.", "url": "https://wpnews.pro/news/i-built-devcommand-and-ended-up-changing-the-way-i-deploy-websites", "canonical_source": "https://dev.to/realjohnliter/i-built-devcommand-and-ended-up-changing-the-way-i-deploy-websites-3m6j", "published_at": "2026-09-04 02:15:38+00:00", "updated_at": "2026-09-04 02:53:26.787980+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["DevCommand", "Hostinger", "GitHub Actions", "Git", "VS Code", "rsync", "SSH"], "alternates": {"html": "https://wpnews.pro/news/i-built-devcommand-and-ended-up-changing-the-way-i-deploy-websites", "markdown": "https://wpnews.pro/news/i-built-devcommand-and-ended-up-changing-the-way-i-deploy-websites.md", "text": "https://wpnews.pro/news/i-built-devcommand-and-ended-up-changing-the-way-i-deploy-websites.txt", "jsonld": "https://wpnews.pro/news/i-built-devcommand-and-ended-up-changing-the-way-i-deploy-websites.jsonld"}}