DevOps & Infrastructure
I deploy Laravel and Node applications on Linux with Docker, reverse proxies, backups and enough monitoring to know when something is wrong before a customer does.
Docker means the environment that was tested is the environment that ships — the same containers, the same dependency versions — instead of a deploy that works on one machine and mysteriously fails on another. A reverse proxy terminates TLS and routes traffic to the right container, and CI/CD runs the same build and test steps on every push so a broken deploy gets caught before it reaches production, not after.
Backups are only real if they have been restored at least once. I set up scheduled backups for PostgreSQL, MySQL or SQLite depending on the stack, and verify the restore actually works rather than trusting that a cron job silently succeeded for the past year.
Monitoring is deliberately boring: uptime checks, error tracking, and log aggregation sized to the actual team, not a dashboard nobody looks at. The goal is knowing about a problem from an alert, not from a customer's support ticket.
Business problems
- A deploy that only works because it lives in one developer's head and one laptop's configuration.
- Backups that have never been restored, so nobody actually knows if they work until the day they are needed.
- No monitoring, so the team finds out about an outage from a customer instead of from an alert.
- Secrets and API keys committed to the repository or passed around over chat, instead of managed through environment variables or a secrets manager.
- A single VPS running the database, the app and the reverse proxy with no separation, so one bad deploy can take the whole stack down at once.
- No staging environment that mirrors production closely enough to catch a configuration difference before it reaches customers.
- Manual, undocumented server setup, so replacing a failed VPS means reconstructing configuration from memory instead of running a script.
- Logs scattered across containers with no central place to search them, so debugging an issue means SSH-ing into three different places and grepping by hand.
Development process
- Containerize the app with Docker so the tested environment is the one that ships, with a reverse proxy handling TLS and routing.
- Set up CI/CD so every push runs the same build and test steps, catching a broken deploy before it reaches production.
- Schedule backups for the actual database in use — PostgreSQL, MySQL or SQLite — and verify the restore, not just the backup job's exit code.
- Manage secrets through environment variables or a secrets manager, never committed to the repository, and rotate them when someone with access leaves.
- Separate concerns even on a single server — database, app, reverse proxy in their own containers — so a bad deploy of one does not take down the others.
- Keep staging close enough to production — same containers, same-ish data shape — that a config difference shows up there, not in front of customers.
- Script server provisioning (or use infrastructure as code) so replacing a failed VPS is running a script, not reconstructing configuration from memory under pressure.
- Centralize logs from every container into one searchable place, so debugging an issue is a search query, not an SSH session into three different machines.
What you get
- A deploy that works the same way on the next machine as it did on the first, because the environment is defined in code, not memory.
- Backups that have actually been proven to restore, not just scheduled and hoped for.
- Problems surfaced by an alert before a customer notices, because monitoring is sized to the team, not ignored as a dashboard nobody opens.
- Secrets that are not sitting in a git history for anyone with repo access to find.
- A bad deploy that takes down one container instead of the whole stack, because concerns were separated from the start.
- Configuration differences caught in staging, before they reach a customer, instead of debugged live in production.
- A failed server replaced by running a script in minutes, instead of a stressful afternoon reconstructing configuration from memory.
- An issue debugged from one searchable log view instead of SSH sessions into three different containers hoping to find the right line.
- A deployment history that shows exactly what changed and when, so a regression can be traced to the commit that caused it instead of guessed at.
Selected projects
FAQ
Do you work with AWS?
Yes, when the product needs it. Many products are better served by a well-run VPS plus Docker until traffic or compliance says otherwise.