Technology became meaningful to me when I stopped seeing a server as a machine that simply runs commands and started seeing it as a system that must be designed, secured, automated, and maintained. That change in perspective has shaped my journey as an MCA student at MACE Kothamangalam and as an aspiring cloud and DevOps engineer.
My name is Mathew K Cheriyan. I enjoy learning how Linux systems work, how cloud infrastructure is assembled, and how automation can turn a fragile manual process into something repeatable and dependable. This article is the story of that journey and the projects that helped me move from following commands to understanding engineering decisions.
Starting with Linux fundamentals
Linux gave me the foundation for everything that followed. Working with users, groups, permissions, services, packages, logs, processes, networking, and SSH taught me that reliable systems are built from many small, deliberate choices.
I learned that completing a task once is not the same as operating it well. A service must survive reboots. File ownership must match the process that reads the file. Network access should be limited to what is required. Logs must provide enough information to diagnose a failure. These details may seem small, but together they separate a temporary demonstration from a maintainable system.
Building a real WordPress platform on AWS
One of my most valuable projects was deploying this WordPress site on an Amazon Linux EC2 instance. Instead of using a prebuilt hosting image, I assembled the platform from its individual components:
- Nginx as the web server and reverse-facing HTTP layer
- PHP 8.2 with PHP-FPM for application execution
- MariaDB for persistent WordPress data
- phpMyAdmin for controlled database administration
- Chrooted SFTP for restricted website file management
- Let’s Encrypt TLS with automatic certificate renewal
The website files live under a dedicated user’s home directory, while the SFTP chroot follows OpenSSH ownership requirements. HTTP traffic is redirected to HTTPS, WordPress stores canonical secure URLs, and certificate renewal is managed automatically.
The most important part was not simply getting the page online. It was converting the entire process into an idempotent Ansible playbook. I tested the playbook repeatedly until an unchanged server produced changed=0 and failed=0. That result demonstrated that the automation described the desired state instead of blindly repeating commands.
A good automation workflow does more than save time. It captures knowledge, reduces variation, and makes recovery possible.
Creating AutoPlay: automation that builds automation
My next project pushed the idea further. I built AutoPlay, a Python and Flask platform that generates Ansible playbooks from a web interface. A user chooses infrastructure tasks, enters target details, reviews the generated YAML and inventory, evaluates security warnings, and can execute the playbook while following its logs.
AutoPlay now provides a growing catalog of modules for web servers, packages, services, containers, databases, users, directories, managed files, Git repositories, cron jobs, operating-system updates, host configuration, firewall rules, and advanced commands.
The application is containerized with Docker and delivered through a Jenkins pipeline. It runs Blue and Green application environments behind Nginx. Jenkins deploys a new release to the inactive environment, performs a smoke test, and changes traffic only after the test passes. If the new version is unhealthy, the currently active environment continues serving users.
What failures taught me
These projects did not work perfectly on the first attempt, and that was useful. I encountered YAML formatting errors, incorrect inventory targeting, SSH-key injection problems, file-permission mismatches, stale DNS records, container image drift, and Jenkins executor issues caused by low disk space.
Each problem reinforced a practical troubleshooting method:
- Observe the exact failure instead of guessing.
- Identify which layer owns the behavior: browser, DNS, network, web server, application, database, container, or CI/CD system.
- Reproduce the issue with the smallest reliable test.
- Fix the source configuration, not only the live symptom.
- Run the same verification again and check for regressions.
This approach has made me more comfortable with unfamiliar failures. I may not immediately know every answer, but I know how to gather evidence and work toward one.
The engineering principles I now value
- Automation should be repeatable: rerunning it should converge on the same desired state.
- Security is part of the design: secrets, permissions, exposed ports, and access boundaries cannot be postponed.
- Verification must be observable: health checks, logs, status codes, and tests should prove that a deployment works.
- Source control is operational memory: Git records why and how a system changed.
- Failure should be contained: dry runs, smoke tests, Blue-Green releases, and rollback paths reduce the impact of mistakes.
Where I am heading next
I am continuing to develop my skills in cloud infrastructure, Linux administration, CI/CD, containers, monitoring, security, and production-grade automation. I want to strengthen AutoPlay with authentication, role-based access control, isolated execution workers, better secrets management, approval workflows, PostgreSQL, and deeper AWS integration.
My goal is to become an engineer who can support systems calmly, understand failures across layers, and improve repetitive processes through thoughtful automation. I am still learning, but these projects have given me something more valuable than a list of commands: they have given me a way to think about reliable technology.
Thank you for reading. This blog itself is part of the journey: hosted on AWS, configured through Ansible, secured with HTTPS, and maintained as a working example of the skills I am building.