For me, DevOps is not a separate role but a collection of practices that make software delivery more reliable and enjoyable. In this category, I share practical observations about automation, CI/CD, deployments, infrastructure, and the tools I use while building personal and commercial projects.
SSH can stop accepting new connections even while the server is reachable, the website works, and sshd is active. One less obvious cause is an automatic SSH tunnel that reconnects too aggressively and hits an UFW LIMIT rule.
When several Dockerized projects share one machine, a PHP upgrade should remain a local change to one environment. Isolated runtimes, separate workspace containers, clear service naming, and Composer compatibility checks help prevent one project upgrade from silently breaking another.
Completed deployment commands do not prove that the application works. After the switch, verify HTTP responses, critical services, and background processes. If verification fails, roll back and verify the rollback itself.
If the build, dependencies, configuration, or basic checks can fail before production state changes, there is no reason to make the site unavailable first. Maintenance mode should begin only after preflight passes and only for steps that truly require a short downtime window.
A script that runs only once can still create duplicates, assign the wrong category, publish internal identifiers, or break bilingual content structure. If it changes production data, it deserves the same defensive thinking as regular application code.
During a traffic-spike investigation, 155 upstream errors initially looked like an availability problem in the main application. The error log showed something else: requests were reaching a separate virtual host because of HTTPS default-server behavior. That changed both the diagnosis and the protection.
After another traffic spike, I did not immediately block a country, User-Agent, or IP. I first correlated Laravel Analytics with Nginx logs, separated several independent traffic sources, verified Fail2ban behavior, and only then added Nginx rate limiting in dry-run mode.
A backup file on a server proves very little by itself. You need to know when it was created, whether the job runs regularly, whether the size looks plausible, whether recent runs succeeded, and most importantly, whether the data can actually be restored.
If a critical vulnerability is in PHP itself, updating Composer dependencies will not fix it. You need to inventory every environment, prepare backups, update the installed PHP packages, and then verify the site, PHP-FPM, queues, and Docker containers.
On October 21, 2026, the PHP Security Team disclosed CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities that can allow unauthenticated remote code execution. The issue is in the PHP runtime itself, not in application Composer dependencies.
For a larger release, I do not merge related tasks into development one by one. They first come together in a dedicated release branch, are stabilized as a group, and only then move forward as one verified unit.
After enabling scanner protection, I left ICanUp running overnight and reviewed the real logs in the morning. The protection worked, Fail2ban banned real addresses, and the review also exposed a DEV gap for nested sensitive paths.