DevOps & deployment

The deploy pipeline I know best is the one behind this site and teqprotech.com: one Laravel codebase, shipped to a shared cPanel host.

• CI first. GitHub Actions runs the full test suite against SQLite and against MariaDB, the production engine. The deploy workflow is triggered manually and only continues when CI passes.
• Build once, ship an artifact. Composer dependencies without dev packages, compiled front-end assets and a snapshot of the content data are packed into one release and uploaded over SSH with a dedicated deploy key.
• Back up before switching. Each deploy dumps the database (and checks the dump) before anything changes. A production deploy also archives both web roots.
• Atomic switch. Each release lives in its own directory and the live app is a symlink, so switching versions is a single step.
• Health checks decide. The deploy polls a /health endpoint on both domains until each reports the new version. If that doesn't happen, it switches back to the previous release and restores the web roots from the backup.

The pipeline has been through a real incident. A green deploy still caused about seventeen minutes of downtime, from a health check that ran too early, a restore that broke directory ownership and an inode quota. The fixes now live in the deploy scripts: a longer health-check window, restores that copy contents into the existing directories, a small release history, and a pre-flight inode check before any upload.

The Gadget Index uses the same approach on a smaller scale: a GitHub Actions deploy to cPanel, with backups and cron jobs.

Evidence level: present, from this platform's pipeline and The Gadget Index.