Production engineering

The work that keeps systems working.

Recovery, security, and migration work on real production systems. Three experiences in making changes while preserving the business behind the software.
Production Infrastructure Recovery & StabilizationProduction Security Hardening & Request ObservabilityProduction nopCommerce-to-Laravel Data Migration

Production Infrastructure Recovery & Stabilization

Recovered a production server hosting multiple active applications and services, with backups and validation around each change.

LinuxLaravelNext.jsMySQLMongoDBRedisGiteaNginxPM2systemdSSLDNSEmail services

The situation

Several live applications and supporting services shared a production environment. Recovery needed to preserve their availability and data integrity while rebuilding the dependencies that keep each application operational.

What I did

  • Restored Laravel and Next.js applications, database services, Redis, and Gitea.
  • Recovered Nginx reverse proxies and PM2/systemd processes; configured SSL certificates and DNS records.
  • Worked on business email infrastructure and production backups.
  • Validated critical services after each change and prepared recovery and rollback strategies.
Engineering workflow Conceptual flow
  1. Backup
  2. Scoped change
  3. Validate
  4. Service health check
  5. Rollback plan

Engineering decisions

Validate the affected service and its dependencies after each scoped change. Keep a usable backup and rollback path around critical recovery steps rather than treating a process restart as proof of recovery.

Outcomes

  • Improved service stability and isolation.
  • Improved recoverability and readiness for subsequent deployments.

No uptime percentage or zero-downtime outcome is claimed.

Production Security Hardening & Request Observability

Investigated reconnaissance traffic, corrected client-IP attribution across trusted proxies, and separated missing-page signals from attack-probe noise.

LaravelNext.jsNginxReverse proxiesHTTP headersSecurity logging

The situation

Backend logs contained unusually frequent requests for .env, .git, WordPress endpoints, PHP probes, XML-RPC, and sensitive configuration paths. The investigation identified scanning activity and incorrect source-IP attribution; it did not establish a successful breach.

What I did

  • Analyzed database logs and suspicious URL patterns, then traced the Next.js SSR-to-Laravel request path.
  • Corrected trusted proxy handling and forwarded original request metadata only through known trusted proxies.
  • Avoided unconditional trust in client-controlled forwarded headers.
  • Improved missing-page handling and nested-route redirect lookup.
  • Filtered static assets and probe noise from SEO-related 404 records.
  • Added safer Nginx rules to reject sensitive-path requests before application processing.
Trusted request path Conceptual flow
  1. Client request
  2. Nginx / known trusted proxy
  3. Next.js SSR
  4. Laravel API
  5. Attributed security & 404 logs

Engineering decisions

The proxy boundary determines which forwarding metadata is trustworthy. Keep original client attribution through the known SSR/API path, and keep malicious probes separate from genuine missing-page records that inform redirects and SEO.

Outcomes

  • More accurate client-IP tracking and cleaner 404 logs.
  • Less database noise and more useful technical SEO workflows.
  • Defense in depth through application attribution and edge request filtering.

Forwarded headers are trusted only from configured proxies. Scanning is not evidence of a successful breach, and hardening does not imply immunity to attacks.

Production nopCommerce-to-Laravel Data Migration

Incrementally reconciled historical commerce records with an active Laravel database that was already receiving new production data.

LaravelPHPMySQLIncremental migrationData integrityProduction auditing

The situation

An initial migration had already occurred and the Laravel store had accumulated new production-specific records. Historical nopCommerce data needed to be imported and corrected without replacing or destroying the live records.

What I did

  • Developed and executed incremental imports for customers, addresses, products, categories, brands, orders, and order items.
  • Preserved production-specific records and reconciled legacy mappings against existing data.
  • Restored product images and verified storage paths.
  • Corrected customer display names and removed legacy customer labels.
  • Prevented historical orders from appearing new or unread.
  • Created backups around critical changes and audited mappings, totals, images, and historical orders.
Engineering workflow Conceptual flow
  1. Legacy nopCommerce
  2. Incremental import & mappings
  3. Existing production data
  4. Reconciliation
  5. Integrity audits

Engineering decisions

The central problem was business continuity: reconcile imported history with a database already accepting new records. Keep mappings, backups, and post-import audits explicit, including user-facing details such as names, images, and unread-order state.

Outcomes

  • 846 imported customer records reviewed; 843 assigned meaningful display names using available names, phone numbers, or email addresses.
  • 0 remaining “legacy customer” labels.
  • 579 historical orders and 1,101 order items preserved.
  • 0 unread historical orders; product image paths verified.
  • Existing production-specific data preserved.

These are reported migration audit results supplied by the owner. This nopCommerce migration is independent of the DHB63 WooCommerce rebuild.

See the separate DHB63 WooCommerce rebuild →

Let’s build something that lasts

A complex system.
A practical engineer.

Open to international remote roles and relocation.

Email me All contact details